From nobody Sun Nov 8 17:38:27 2015 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5531B585F; Sun, 8 Nov 2015 17:38:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151109013824.28092.56872.idtracker@ietfa.amsl.com> Date: Sun, 08 Nov 2015 17:38:24 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-18.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 01:38:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-18.txt Pages : 30 Date : 2015-11-08 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 8 17:41:52 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE41A6F0B for ; Sun, 8 Nov 2015 17:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 r1SuH9lmkPvl for ; Sun, 8 Nov 2015 17:41:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A941A1BF1 for ; Sun, 8 Nov 2015 17:41:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAB69282; Mon, 09 Nov 2015 01:41:35 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 9 Nov 2015 01:41:34 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Mon, 9 Nov 2015 09:41:32 +0800 From: "Songhaibin (A)" To: Alissa Cooper Thread-Topic: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 Thread-Index: AQHQ1umosqhZ/UWGA0i8P+k8SWdo8p4P1gUAgAGVAoCAAygiwIAYAXYAgCzfIQCAOf21AA== Date: Mon, 9 Nov 2015 01:41:32 +0000 Message-ID: References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F653A9E39nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010201.563FF9D0.0053, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.75, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 49454a7dd6667c7db696732ecdcea0da Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 01:41:51 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F653A9E39nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alissa, The revision of this draft is now available. Please check if it solves your= comments. Best Regards! -Haibin From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Saturday, October 03, 2015 8:06 PM To: Songhaibin (A) Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 Wanted to check if a rev of this document is forthcoming? Thanks, Alissa On Sep 4, 2015, at 3:51 PM, Alissa Cooper > wrote: Thanks for the reply. Comments are inline. On Aug 20, 2015, at 8:22 PM, Songhaibin (A) > wrote: Hi Alissa, Thank you for the comments. Please find my explanations in line with [haibi= n]. Thanks. I did have one further thought for Section 8. It strikes me that th= e combination of diagnostic elements that this spec makes available could e= asily be used to fingerprint a peer in an overlay where peers may otherwise= be attempting to remain anonymous. Although defenses against such fingerpr= inting are probably hard to come by (short of disallowing access to the dia= gnostics via the config file), the threat is worth noting at least. [haibin]Actually we imply your concern with the sentence "It should also be= noted that attackers can use diagnostics to analyze overlay information to= attack certain key peers." But we could elaborate more in this section. Yes, further elaboration would be appreciated. From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Wednesday, August 19, 2015 12:04 AM To: David Bryan Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 On Aug 17, 2015, at 8:54 AM, David Bryan > wrote: Thanks for the comments. I'll circle back with the team and will revise. Thanks. I did have one further thought for Section 8. It strikes me that th= e combination of diagnostic elements that this spec makes available could e= asily be used to fingerprint a peer in an overlay where peers may otherwise= be attempting to remain anonymous. Although defenses against such fingerpr= inting are probably hard to come by (short of disallowing access to the dia= gnostics via the config file), the threat is worth noting at least. I have to check, but I actually think the first few versions of this (when = it was individual) *may* be pre-5378, but will double check. Ah ok. [haibin] It is true that the first version of the individual draft is pre-5= 378. Ok, my mistake then. Alissa On Fri, Aug 14, 2015 at 6:33 PM, Alissa Cooper > wrote: I have reviewed this document in preparation for IETF last call. Before pro= ceeding to last call, I have some comments and questions that I'd like to d= iscuss. I've also included a list of nits that should be resolved together = with any last call comments. =3D=3D Substantive comments and questions =3D=3D =3D General I think this document should be listed as updating RFC 6940 in the document= header. The document contains a disclaimer for pre-RFC5378 work, which I assume is = in error. If using xml2rfc to generate the text, using the most up-to-date = version of xml2rfc to create the next version should fix this. =3D Section 4.3: "There have been proposals that RouteQuery and a series of Fetch requests can be used to replace the PathTrack mechanism, but in the presence of churn such an operation would not, strictly speaking, provide identical results, as the path may change between RouteQuery and Fetch operations. (although obviously the path could change between steps of PathTrack as well)." This text is confusing. It doesn't explain why PathTrack is being defined r= ather than peers using RouteQuery plus Fetch. Furthermore, the document doe= s not explain how peers are supposed to interpret the results of the PathTr= ack method in the event that the route does change in between steps. This s= eems like a substantial omission. [haibin] This is a good question. As the route change is a problem (with li= ttle probability), we would like to retrieve diagnostics info in an efficie= nt way, so one simple message is preferred. And you are right, it does not = change the truth that route can change in between steps. We need re-wordin= g the section. The implication of route change is that, the result of the d= iagnostics cannot be trusted with one hundred percent, which should be note= d to the users that perform the diagnostics. Ok, new text would be appreciated. In general, this document provides very little information about how peers = are expected to interpret and use the diagnostic information. I understand = that peers can do whatever they want with it, but in several places the fac= t that this is not explained makes the reasoning behind the protocol design= decisions opaque. I would suggest providing a little more context, at the = very least by moving the examples into the body of the draft somewhere. [haibin] We can add some more explanations with diagnostics info interpreta= tion. Ok, good. =3D Section 4.4: I'm a little confused about the values given for the error codes. Do you wa= nt IANA to chose these specific values? Or are they just there as placehold= ers? The customary way of doing placeholders would be as follows: Code Value Error Code Name [TBD1] Underlay Destination Unreachable [TBD2] Underlay Time exceeded [TBD3] Message Expired [TBD4] Upstream Misrouting [TBD5] Loop detected [TBD6] TTL hops exceeded These placeholders would then get used throughout the document. [haibin] they are place holders. Ok, please clarify it in the document in that case. This section also says: "In addition, this document introduces several types of error information i= n the error_info field in the case of Code 0x65. ... Here are some examples= for the error info. ... The error_info field values of the Code 0x66 to 0x= 70 are to be application specific and defined by the particular overlay." I'm not sure what is meant by all of this text. As defined in RFC 6940, err= or_info is an optional implementation-specific byte string. If you are inte= nding to require implementations to include specific text in the error_info= for the first error code, then you need to explain under what conditions t= he specific text needs to be included for each string. And the text about t= he other codes seems redundant with how error_info is already defined in RF= C 6940. [haibin] if a peer receives a diagnostic request found that it cannot reach= its next hop due to underlay problem, it needs to explain with error_info = what happened. I do not know what you mean by redundant with RFC 6940. They= are different errors. Maybe it's just a language thing, but the first sentence saying "this docum= ent introduces ..." makes it sound like the list of strings is more than ju= st a list of examples. If these are just examples that implementations can = choose to use or not, I would suggest the following re-phrasing: OLD In addition, this document introduces several types of error information in the error_info field in the case of Code 0x65. These are represented as an opaque UTF-8 text string. Here are some examples for the error info. NEW Here are some examples of errors that might be expressed using the error_in= fo field in the case of Code [TBD1]: =3D Section 5.2: "ext_length : the length of the returned DiagnosticInfo information in bytes. If the value is greater than or equal to 1, then some extended diagnostic information is requested." This is defining the diagnostic response - why would the extension be reque= sting something? And if it is possible to use an extension in that way, the= expected behavior from the initiator when it receives such an extension ne= eds to be described, or at least it needs to be noted that a diagnostic res= ponse could provoke a request back to the initiator. [haibin] it is possible to reword it as "....then some extended diagnostic = information is responded." How about "is being sent in the response"? Also, in the struct the diagnostic info is called "diagnostic_info_contents= " but in the text it is called "diagnostic_information." These should be th= e same I think. [haibin] Yes. It will be corrected. Ok =3D Section 5.3: I'm concerned about the way STATUS_INFO is defined. First, why are there 16= different levels of congestion status? What are they supposed to signify? = If there is no standardized way of measuring congestion defined, how is a n= ode supposed to interpret STATUS_INFO received from different peers? That i= s, couldn't one peer's level 7 actually mean it is less congested than anot= her peer's level 3, and won't that make the information somewhat meaningles= s to the initiator? Maybe this would be clearer if you could explain what y= ou expect an initiator to do with the information about 16 different levels= of congestion. [haibin] Your concern makes sense. Actually it is intended to leave it for = overlay implementers or a future standard to define the congestion level al= gorithms . This draft just defines the format and reserves the bits for the= ir use. As the section says " This document does not provide a specific met= hod for congestion, leaving this decision to each node. One possible optio= n for a node would be to take its CPU/memory/bandwidth usage percentage in = the past 600 seconds and normalize the highest value to the range [0x00, 0x= 0F]. A future draft may define an objective measure or specific algorithm = for this." I think we should change the node decision to overlay decision. = And an overlay implementer may choose to not use all that 16 values. Ok, further clarification would help. SOFTWARE_VERSION doesn't really seem like diagnostic information. While all= of the other fields may be constantly changing and therefore it would make= sense to inquire about them in a diagnostic fashion, SOFTWARE_VERSION seem= s more like data that nodes could register or exchange when they join the o= verlay. Why is it included as a diagnostic? [haibin] Diagnostics usually take place when there are failures or abnormal= behaviors. Software version incompatibility might be a cause. Ok, fair enough. Still seems like an odd choice to me. Also, doesn't the SOFTWARE_VERSION type need a length or a specified delimi= ter that indicates the end of the string? Otherwise, how is the recipient s= upposed to know when to stop parsing it? [haibin] Will add it. Ok The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem problematic. sent =3D alpha x sent_present + (1 - alpha) x sent rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd As written these equations are not right because sent/rcvd appear on both s= ides. It would be clearer to use last_sent and last_rcvd or some such on th= e right-hand side of these equations. But this begs some bigger questions: - Does this place a requirement on all nodes implementing this specificatio= n to have to calculate these values every 5 seconds? - How are the values calculated the first time? - How was the value of 5 seconds chosen? [Haibin] This is incorporated from the early RELOAD document. Maybe some au= thor of the RELOAD protocol can give a better explanation. Finally, I have trouble understanding why only some of the types are subjec= t to access control as described in Section 7. It seems to me that in some = situations all of the fields defined here could be considered sensitive by = certain nodes or on certain networks. What is the justification for only ma= king some of them subject to access control? [haibin] Actually it says different level of access control can be made. Fo= r example, diagnostic information A can be accessed by node 1 and 2, but di= agnostic information B can only be accessed by node 2. We can add some expl= anations as it seems not clear to readers. Ok, will await the revision. =3D Section 6.1: "The destination field MUST be set to the desired destination, which MAY be= either a NodeId or ResourceID but SHOULD NOT be the broadcast NodeID." What is the expected behavior if a Ping or a PathTrack does get sent to the= broadcast NodeID? Or should these requirements really be MUST NOTs? [haibin] I guess they should be MUST NOTs. Ok =3D Section 6.4: "However, for a single hop measurement, the traditional measurement methods MUST be used instead of the overlay layer diagnostics methods." What is meant by the traditional measurement methods? [haibin] It mainly means IP layer ping. Would be good to specify. Thanks, Alissa =3D Section 9: Please only use either RFC-XXXX or RFC-AAAA but not both as placeholders. [haibin] RFC-AAAA is RFC 6940. RFC-XXXX is the placeholder. They will be co= rrected. Please also use [TBDX] for values you expect to be allocated by IANA. [haibin] ok. =3D=3D Nits =3D=3D =3D General The document seems to repeatedly explain that it is doing things "as specif= ied in RFC6940." I don't think this necessary in many cases. It's worth doi= ng a pass through and removing the places where it's obvious that this spec= is building on RFC 6940. [haibin] ok. =3D Section 4.1: OLD The extensions strictly follow RELOAD specification on the messages routing, transport, NAT traversal etc. NEW The extensions strictly follow how RELOAD specifies message routing, transp= ort, NAT traversal, and other RELOAD protocol features. =3D Section 4.2.1: s/as specified in Table 4 and specified in the RELOAD/as specified in Table= 4/ s/new requests of the the/new requests of the/ =3D Section 4.3: OLD We define a simple PathTrack method for retrieving diagnostic information iteratively. The mechanism defined in this document follows the RELOAD specification, the new request and response message use the message format specified in RELOAD messages. Please refer to the RELOAD [RFC6940] for details of the protocol. The operation of this request is shown below in Figure 2. NEW We define a simple PathTrack method for retrieving diagnostic information iteratively. The operation of this request is shown below in= Figure 2. =3D Section 4.3.1.2: s/after that/after receiving a PathTrackAns where the next_hop node ID equa= ls the responding node ID/ =3D Section 4.3.2.1: s/PathTrack Response/PathTrack response/ =3D Section 4.4: s/code. and we define/code. We define/ =3D Section 5: s/Path_track methods/PathTrack methods/ =3D Section 5.1: s/Note that is NOT/Note that it is not/ =3D Section 5.2: s/Note that is NOT/Note that it is not/ s/consists one or more/consists of one or more/ =3D Section 6.1: s/`MAY/MAY/ =3D Section 6.2: s/return the response the initiator node/return the response to the initiat= or node/ s/The peer SHOULD/The intermediate peer SHOULD/ [haibin] Thanks again. BR, -Haibin Song _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_E33E01DFD5BEA24B9F3F18671078951F653A9E39nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alissa,=

 = ;

The revisi= on of this draft is now available. Please check if it solves your comments.=

 = ;

Best Regards!

-Haibin

 = ;

From: Alissa Cooper [mailto:alissa@cooperw.in]
Sent: Saturday, October 03, 2015 8:06 PM
To: Songhaibin (A)
Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-1= 7

 

Wanted to check if a rev of thi= s document is forthcoming?

 

Thanks,

Alissa

 

On Sep 4, 2015, at 3:51 PM, Ali= ssa Cooper <alissa@cooperw.in&g= t; wrote:

 

Thanks for the reply. Comments = are inline.

 

On Aug 20, 2015, at 8:22 PM, So= nghaibin (A) <haibin.song@huaw= ei.com> wrote:

 

Hi Alissa,

Thank you for the comments. Please find my explanations in line with [haibi= n].


Thanks. I did have one further = thought for Section 8. It strikes me that the combination of diagnostic ele= ments that this spec makes available could easily be used to fingerprint a = peer in an overlay where peers may otherwise be attempting to remain anonymous. Although defenses against such fingerpr= inting are probably hard to come by (short of disallowing access to the dia= gnostics via the config file), the threat is worth noting at least.

=
[haibin]Actually we imply your concern with the sentence "It should al= so be noted that attackers can use diagnostics to analyze overlay informati= on to attack certain key peers." But we could elaborate more in this s= ection.

 

Yes, further elaboration would = be appreciated.




From: Alissa Cooper [mailto:alissa@coo= perw.in]
Sent: Wednesday, August 19, 2015 12:04 AM
To: David Bryan
Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17

On Aug 17, 2015, at 8:54 AM, David Bryan <dbryan@ethernot.org> wrote:


Thanks for the comments. I'll circle back with the team and will revise.
Thanks. I did have one further thought for Section 8. It strikes me that th= e combination of diagnostic elements that this spec makes available could e= asily be used to fingerprint a peer in an overlay where peers may otherwise= be attempting to remain anonymous. Although defenses against such fingerprinting are probably hard to come by= (short of disallowing access to the diagnostics via the config file), the = threat is worth noting at least.



I have to check, but I actually think the first few versions of this (when = it was individual) *may* be pre-5378, but will double check.

Ah ok.

[haibin] It is true that the first version of the individual draft is pre-5= 378.

 

Ok, my mistake then.=




Alissa



On Fri, Aug 14, 2015 at 6:33 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I have reviewed this document in preparation for IETF last call. Before pro= ceeding to last call, I have some comments and questions that I'd like to d= iscuss. I've also included a list of nits that should be resolved together = with any last call comments.


=3D=3D Substantive comments and questions =3D=3D

=3D General 

I think this document should be listed as updating RFC 6940 in the document= header.

The document contains a disclaimer for pre-RFC5378 work, which I assum= e is in error. If using xml2rfc to generate the text, using the most up-to-= date version of xml2rfc to create the next version should fix this.

=3D Section 4.3:

"There have been proposals that RouteQuery and a series of Fetch
  requests can be used to replace the PathTrack mechanism, but in= the
  presence of churn such an operation would not, strictly speakin= g,
  provide identical results, as the path may change between Route= Query
  and Fetch operations. (although obviously the path could change=
  between steps of PathTrack as well)."

This text is confusing. It doesn't explain why PathTrack is being defined r= ather than peers using RouteQuery plus Fetch. Furthermore, the document doe= s not explain how peers are supposed to interpret the results of the PathTr= ack method in the event that the route does change in between steps. This seems like a substantial omission= .

[haibin] This is a good question. As the route change is a problem (with li= ttle probability), we would like to retrieve diagnostics info in an efficie= nt way, so one simple message is preferred. And you are right, it does not = change the truth that route can change  in between steps. We need re-wording the section. The implica= tion of route change is that, the result of the diagnostics cannot be trust= ed with one hundred percent, which should be noted to the users that perfor= m the diagnostics.

 

Ok, new text would be appreciat= ed.




In general, this document provides very little information about how peers = are expected to interpret and use the diagnostic information. I understand = that peers can do whatever they want with it, but in several places the fac= t that this is not explained makes the reasoning behind the protocol design decisions opaque. I would suggest= providing a little more context, at the very least by moving the examples = into the body of the draft somewhere. 

[haibin] We can add some more explanations with diagnostics info interpreta= tion.

 

Ok, good.




=3D Section 4.4:

I'm a little confused about the values given for the error codes. Do you wa= nt IANA to chose these specific values? Or are they just there as placehold= ers? The customary way of doing placeholders would be as follows:

Code Value         Error Code Name<= br>      [TBD1]       &n= bsp;       Underlay Destination Unreacha= ble
     [TBD2]       &n= bsp;       Underlay Time exceeded
     [TBD3]       &n= bsp;       Message Expired
     [TBD4]       &n= bsp;       Upstream Misrouting
     [TBD5]       &n= bsp;       Loop detected
     [TBD6]       &n= bsp;       TTL hops exceeded

These placeholders would then get used throughout the document.

[haibin] they are place holders.

 

Ok, please clarify it in the do= cument in that case.




This section also says:

"In addition, this document introduces several types of error informat= ion in the error_info field in the case of Code 0x65. ... Here are some exa= mples for the error info. ... The error_info field values of the Code 0x66 = to 0x70 are to be application specific and defined by the particular overlay."


I'm not sure what is meant by all of this text. As defined in RFC 6940, err= or_info is an optional implementation-specific byte string. If you are inte= nding to require implementations to include specific text in the error_info= for the first error code, then you need to explain under what conditions the specific text needs to be in= cluded for each string. And the text about the other codes seems redundant = with how error_info is already defined in RFC 6940.


[haibin] if a peer receives a diagnostic request found that it cannot reach= its next hop due to underlay problem, it needs to explain with error_info = what happened. I do not know what you mean by redundant with RFC 6940. They= are different errors.

 

Maybe it’s just a languag= e thing, but the first sentence saying “this document introduces R= 30;” makes it sound like the list of strings is more than just a list= of examples. If these are just examples that implementations can choose to use or not, I would suggest the following re-phrasing:<= /o:p>

 

OLD

In a=
ddition, this document introduces several types of error<=
/pre>

   i=
nformation in the error_info field in the case of Code 0x65.  These


   a=
re represented as an opaque UTF-8 text string.  Here are some


   e=
xamples for the error info.




 

 

NEW

Here=
 are some examples of errors that might be expressed using the error_info f=
ield in the case of Code [TBD1]:

 



=
=3D Section 5.2:


"ext_length : the length of the returned DiagnosticInfo information      in bytes.  If the value is greater than = or equal to 1, then some
     extended diagnostic information is requested.= "

This is defining the diagnostic response - why would the extension be reque= sting something? And if it is possible to use an extension in that way, the= expected behavior from the initiator when it receives such an extension ne= eds to be described, or at least it needs to be noted that a diagnostic response could provoke a request ba= ck to the initiator.

[haibin] it is possible to reword it as "....then some extended diagno= stic information is responded.”

 

How about “is being sent = in the response”?



Also, in the struct the diagnostic info is called "diagnostic_info_con= tents" but in the text it is called "diagnostic_information.= " These should be the same I think.

[haibin] Yes. It will be corrected.

 

Ok




=3D Section 5.3:

I'm concerned about the way STATUS_INFO is defined. First, why are there 16= different levels of congestion status? What are they supposed to signify? = If there is no standardized way of measuring congestion defined, how is a n= ode supposed to interpret STATUS_INFO received from different peers? That is, couldn't one peer's level 7 actual= ly mean it is less congested than another peer's level 3, and won't that ma= ke the information somewhat meaningless to the initiator? Maybe this would = be clearer if you could explain what you expect an initiator to do with the information about 16 different= levels of congestion.

[haibin] Your concern makes sense. Actually it is intended to leave it for = overlay implementers or a future standard to define the congestion level al= gorithms . This draft just defines the format and reserves the bits for the= ir use. As the section says " This document does not provide a specific method for congestion, leaving this d= ecision to each node.  One possible option for a node would be to take= its CPU/memory/bandwidth usage percentage in the past 600 seconds and norm= alize the highest value to the range [0x00, 0x0F].  A future draft may define an objective measure or spec= ific algorithm for this." I think we should change the node decision t= o overlay decision. And an overlay implementer may choose to not use all th= at 16 values.

 

Ok, further clarification would= help.




SOFTWARE_VERSION doesn't really seem like diagnostic information. While all= of the other fields may be constantly changing and therefore it would make= sense to inquire about them in a diagnostic fashion, SOFTWARE_VERSION seem= s more like data that nodes could register or exchange when they join the overlay. Why is it included as a d= iagnostic?

[haibin] Diagnostics usually take place when there are failures or abnormal= behaviors. Software version incompatibility might be a cause.

 

Ok, fair enough. Still seems li= ke an odd choice to me.




Also, doesn't the SOFTWARE_VERSION type need a length or a specified delimi= ter that indicates the end of the string? Otherwise, how is the recipient s= upposed to know when to stop parsing it?

[haibin] Will add it.

 

Ok




The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem probl= ematic.

sent =3D alpha x sent_present + (1 - alpha) x sent
rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd

As written these equations are not right because sent/rcvd appear on both s= ides. It would be clearer to use last_sent and last_rcvd or some such on th= e right-hand side of these equations. But this begs some bigger questions:<= br>
- Does this place a requirement on all nodes implementing this specificatio= n to have to calculate these values every 5 seconds?
- How are the values calculated the first time?
- How was the value of 5 seconds chosen?

[Haibin] This is incorporated from the early RELOAD document. Maybe some au= thor of the RELOAD protocol can give a better explanation.

Finally, I have trouble understanding why only some of the types are subjec= t to access control as described in Section 7. It seems to me that in some = situations all of the fields defined here could be considered sensitive by = certain nodes or on certain networks. What is the justification for only making some of them subject to access c= ontrol?

[haibin] Actually it says different level of access control can be made. Fo= r example, diagnostic information A can be accessed by node 1 and 2, but di= agnostic information B can only be accessed by node 2. We can add some expl= anations as it seems not clear to readers.

 

Ok, will await the revision.





=3D Section 6.1:

"The destination field MUST be set to the desired destination, wh= ich MAY be either a NodeId or ResourceID but SHOULD NOT be the broadca= st NodeID."

What is the expected behavior if a Ping or a PathTrack does get sent to the= broadcast NodeID? Or should these requirements really be MUST NOTs?

[haibin] I guess they should be MUST NOTs.

 

Ok




=3D Section 6.4:

"However, for a single hop
  measurement, the traditional measurement methods MUST be used i= nstead
  of the overlay layer diagnostics methods."

What is meant by the traditional measurement methods?

[haibin] It mainly means IP layer ping.

 

Would be good to specify.<= /o:p>

 

Thanks,

Alissa



=
=3D Section 9:

Please only use either RFC-XXXX or RFC-AAAA but not both as placeholders.
[haibin] RFC-AAAA is RFC 6940. RFC-XXXX is the placeholder. They will be co= rrected.

Please also use [TBDX] for values you expect to be allocated by IANA.

[haibin] ok.

=3D=3D Nits =3D=3D


=3D General


The document seems to repeatedly explain that it is doing things "as s= pecified in RFC6940." I don't think this necessary in many cases. It's= worth doing a pass through and removing the places where it's obvious that= this spec is building on RFC 6940.

[haibin] ok.

=3D Section 4.1:


OLD
The extensions strictly follow RELOAD
  specification on the messages routing, transport, NAT traversal= etc.

NEW
The extensions strictly follow how RELOAD specifies message routing, transp= ort, NAT traversal, and other RELOAD protocol features.

=3D Section 4.2.1:


s/as specified in Table 4 and specified in the RELOAD/as specified in = Table 4/

s/new requests of the the/new requests of the/

=3D Section 4.3:

OLD
We define a simple PathTrack method for retrieving diagnostic
  information iteratively.  The mechanism defined in this do= cument
  follows the RELOAD specification, the new request and response<= br>   message use the message format specified in RELOAD messages. &n= bsp;Please
  refer to the RELOAD [RFC6940] for details of the protocol.

  The operation of this request is shown below in Figure 2.


NEW
We define a simple PathTrack method for retrieving diagnostic
  information iteratively.  The operation of this request is= shown below in Figure 2.

=3D Section 4.3.1.2:

s/after that/after receiving a PathTrackAns where the next_hop node ID= equals the responding node ID/

=3D Section 4.3.2.1:

s/PathTrack Response/PathTrack response/

=3D Section 4.4:

s/code. and we define/code. We define/

=3D Section 5:

s/Path_track methods/PathTrack methods/

=3D Section 5.1:

s/Note that is NOT/Note that it is not/

=3D Section 5.2:

s/Note that is NOT/Note that it is not/

s/consists one or more/consists of one or more/

=3D Section 6.1:

s/`MAY/MAY/

=3D Section 6.2:

s/return the response the initiator node/return the response to the initiat= or node/

s/The peer SHOULD/The intermediate peer SHOULD/

[haibin] Thanks again.

BR,
-Haibin Song


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

 

_______________________________= ________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

 

--_000_E33E01DFD5BEA24B9F3F18671078951F653A9E39nkgeml501mbschi_-- From nobody Mon Nov 9 08:32:32 2015 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DEE1B7F0D; Mon, 9 Nov 2015 08:32:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151109163231.25484.74331.idtracker@ietfa.amsl.com> Date: Mon, 09 Nov 2015 08:32:31 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-share-07.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 16:32:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : A Usage for Shared Resources in RELOAD (ShaRe) Authors : Alexander Knauf Thomas C. Schmidt Gabriel Hege Matthias Waehlisch Filename : draft-ietf-p2psip-share-07.txt Pages : 19 Date : 2015-11-09 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-share-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-share-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 11 15:09:44 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9FB1B3C15 for ; Wed, 11 Nov 2015 15:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4RnrWr3TxEOs for ; Wed, 11 Nov 2015 15:09:33 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D681B3C12 for ; Wed, 11 Nov 2015 15:09:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7B8B020BF2 for ; Wed, 11 Nov 2015 18:09:32 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 11 Nov 2015 18:09:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=/TOSk 5MtHGLag2TrXpiISohcJVI=; b=gSHJvdYIA1oJVXCKoZFV4eobL5bRQDGQWkJNF eIR2Fc2JO4pwUkbDKlG9SPGZv8B6HgAOcyir+OiJjzs3OWkrYZXhmU3jPdu5Ym/8 sSSCrZJlk4BKhBFv8QFFbAZ5UE8FBESMJ1/3Xii+RgwxtsE1gd7S7jl8AZHnEKme RUjo74= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=/TOSk5MtHGLag2TrXpiISohcJVI=; b=aNK8I V5buLfFfHoT+SkZoHGwq6y0ZyyHaWWdD0ofIxEGibDAbFNUVvDjuuJ87aU7dxJxO vzPhNDBoOMhoJQYBzSI4O02bp8k6q8DD3Ej73g3wwcYmmwP4PpoeRnXycbqxORaQ jz6Ueex6RrKvMGcx8pYKnQnAp/MiaOGnZC9Az4= X-Sasl-enc: 41tp8aNdIYKEfq0Vm4pvn+zy6qtHHxM06sL1BTMvv8MF 1447283371 Received: from dhcp-171-68-20-148.cisco.com (dhcp-171-68-20-148.cisco.com [171.68.20.148]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C8546800B4; Wed, 11 Nov 2015 18:09:31 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8BAFB117-0CC2-49B3-BFC3-83C770B3B0CE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 11 Nov 2015 15:09:30 -0800 Message-Id: <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> To: "Songhaibin (A)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 23:09:43 -0000 --Apple-Mail=_8BAFB117-0CC2-49B3-BFC3-83C770B3B0CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Haibin. This looks good but there are still a few unresolved = issues from our earlier mail exchange: > The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem = problematic. >=20 > sent =3D alpha x sent_present + (1 - alpha) x sent > rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd >=20 > As written these equations are not right because sent/rcvd appear on = both sides. It would be clearer to use last_sent and last_rcvd or some = such on the right-hand side of these equations. But this begs some = bigger questions: >=20 > - Does this place a requirement on all nodes implementing this = specification to have to calculate these values every 5 seconds? > - How are the values calculated the first time? > - How was the value of 5 seconds chosen? >=20 > [Haibin] This is incorporated from the early RELOAD document. Maybe = some author of the RELOAD protocol can give a better explanation. This still has not been explained. >=20 > Finally, I have trouble understanding why only some of the types are = subject to access control as described in Section 7. It seems to me that = in some situations all of the fields defined here could be considered = sensitive by certain nodes or on certain networks. What is the = justification for only making some of them subject to access control? >=20 > [haibin] Actually it says different level of access control can be = made. For example, diagnostic information A can be accessed by node 1 = and 2, but diagnostic information B can only be accessed by node 2. We = can add some explanations as it seems not clear to readers. Although I see the new text, the problem still remains that in Section = 5.3 only some of the fields have this disclaimer: Access to this kind of diagnostic information MUST NOT be allowed unless compliant to the rules defined in Section 7 = . I think the disclaimer should apply to all of the fields, not only a = selection of them. As such, I would recommend just putting the = disclaimer once at the top of section 5.3 and explaining that it applies = to all of the fields. Thanks, Alissa > On Nov 8, 2015, at 5:41 PM, Songhaibin (A) = wrote: >=20 > Hi Alissa, > =20 > The revision of this draft is now available. Please check if it solves = your comments. > =20 > Best Regards! > -Haibin > =20 > From: Alissa Cooper [mailto:alissa@cooperw.in = ]=20 > Sent: Saturday, October 03, 2015 8:06 PM > To: Songhaibin (A) > Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org = > Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 > =20 > Wanted to check if a rev of this document is forthcoming? > =20 > Thanks, > Alissa > =20 > On Sep 4, 2015, at 3:51 PM, Alissa Cooper > wrote: > =20 > Thanks for the reply. Comments are inline. > =20 > On Aug 20, 2015, at 8:22 PM, Songhaibin (A) > wrote: > =20 > Hi Alissa, >=20 > Thank you for the comments. Please find my explanations in line with = [haibin]. >=20 >=20 > Thanks. I did have one further thought for Section 8. It strikes me = that the combination of diagnostic elements that this spec makes = available could easily be used to fingerprint a peer in an overlay where = peers may otherwise be attempting to remain anonymous. Although defenses = against such fingerprinting are probably hard to come by (short of = disallowing access to the diagnostics via the config file), the threat = is worth noting at least. >=20 > [haibin]Actually we imply your concern with the sentence "It should = also be noted that attackers can use diagnostics to analyze overlay = information to attack certain key peers." But we could elaborate more in = this section. >=20 > =20 > Yes, further elaboration would be appreciated. >=20 >=20 >=20 > From: Alissa Cooper [mailto:alissa@cooperw.in = ]=20 > Sent: Wednesday, August 19, 2015 12:04 AM > To: David Bryan > Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org = > Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 >=20 > On Aug 17, 2015, at 8:54 AM, David Bryan > wrote: >=20 >=20 > Thanks for the comments. I'll circle back with the team and will = revise. >=20 > Thanks. I did have one further thought for Section 8. It strikes me = that the combination of diagnostic elements that this spec makes = available could easily be used to fingerprint a peer in an overlay where = peers may otherwise be attempting to remain anonymous. Although defenses = against such fingerprinting are probably hard to come by (short of = disallowing access to the diagnostics via the config file), the threat = is worth noting at least. >=20 >=20 >=20 > I have to check, but I actually think the first few versions of this = (when it was individual) *may* be pre-5378, but will double check. >=20 > Ah ok. >=20 > [haibin] It is true that the first version of the individual draft is = pre-5378. > =20 > Ok, my mistake then. >=20 >=20 >=20 > Alissa >=20 >=20 >=20 > On Fri, Aug 14, 2015 at 6:33 PM, Alissa Cooper > wrote: > I have reviewed this document in preparation for IETF last call. = Before proceeding to last call, I have some comments and questions that = I'd like to discuss. I've also included a list of nits that should be = resolved together with any last call comments. >=20 >=20 > =3D=3D Substantive comments and questions =3D=3D >=20 > =3D General=20 >=20 > I think this document should be listed as updating RFC 6940 in the = document header. >=20 > The document contains a disclaimer for pre-RFC5378 work, which I = assume is in error. If using xml2rfc to generate the text, using the = most up-to-date version of xml2rfc to create the next version should fix = this. >=20 > =3D Section 4.3: >=20 > "There have been proposals that RouteQuery and a series of Fetch > requests can be used to replace the PathTrack mechanism, but in the > presence of churn such an operation would not, strictly speaking, > provide identical results, as the path may change between RouteQuery > and Fetch operations. (although obviously the path could change > between steps of PathTrack as well)." >=20 > This text is confusing. It doesn't explain why PathTrack is being = defined rather than peers using RouteQuery plus Fetch. Furthermore, the = document does not explain how peers are supposed to interpret the = results of the PathTrack method in the event that the route does change = in between steps. This seems like a substantial omission. >=20 > [haibin] This is a good question. As the route change is a problem = (with little probability), we would like to retrieve diagnostics info in = an efficient way, so one simple message is preferred. And you are right, = it does not change the truth that route can change in between steps. We = need re-wording the section. The implication of route change is that, = the result of the diagnostics cannot be trusted with one hundred = percent, which should be noted to the users that perform the = diagnostics. > =20 > Ok, new text would be appreciated. >=20 >=20 >=20 > In general, this document provides very little information about how = peers are expected to interpret and use the diagnostic information. I = understand that peers can do whatever they want with it, but in several = places the fact that this is not explained makes the reasoning behind = the protocol design decisions opaque. I would suggest providing a little = more context, at the very least by moving the examples into the body of = the draft somewhere.=20 >=20 > [haibin] We can add some more explanations with diagnostics info = interpretation.=20 > =20 > Ok, good. >=20 >=20 >=20 > =3D Section 4.4: >=20 > I'm a little confused about the values given for the error codes. Do = you want IANA to chose these specific values? Or are they just there as = placeholders? The customary way of doing placeholders would be as = follows: >=20 > Code Value Error Code Name > [TBD1] Underlay Destination Unreachable > [TBD2] Underlay Time exceeded > [TBD3] Message Expired > [TBD4] Upstream Misrouting > [TBD5] Loop detected > [TBD6] TTL hops exceeded >=20 > These placeholders would then get used throughout the document. >=20 > [haibin] they are place holders.=20 > =20 > Ok, please clarify it in the document in that case. >=20 >=20 >=20 > This section also says: >=20 > "In addition, this document introduces several types of error = information in the error_info field in the case of Code 0x65. ... Here = are some examples for the error info. ... The error_info field values of = the Code 0x66 to 0x70 are to be application specific and defined by the = particular overlay." >=20 >=20 > I'm not sure what is meant by all of this text. As defined in RFC = 6940, error_info is an optional implementation-specific byte string. If = you are intending to require implementations to include specific text in = the error_info for the first error code, then you need to explain under = what conditions the specific text needs to be included for each string. = And the text about the other codes seems redundant with how error_info = is already defined in RFC 6940. >=20 >=20 > [haibin] if a peer receives a diagnostic request found that it cannot = reach its next hop due to underlay problem, it needs to explain with = error_info what happened. I do not know what you mean by redundant with = RFC 6940. They are different errors. > =20 > Maybe it=E2=80=99s just a language thing, but the first sentence = saying =E2=80=9Cthis document introduces =E2=80=A6=E2=80=9D makes it = sound like the list of strings is more than just a list of examples. If = these are just examples that implementations can choose to use or not, I = would suggest the following re-phrasing: > =20 > OLD > In addition, this document introduces several types of error > information in the error_info field in the case of Code 0x65. = These > are represented as an opaque UTF-8 text string. Here are some > examples for the error info. > =20 > =20 > NEW > Here are some examples of errors that might be expressed using the = error_info field in the case of Code [TBD1]: > =20 >=20 >=20 >=20 > =3D Section 5.2: >=20 >=20 > "ext_length : the length of the returned DiagnosticInfo information > in bytes. If the value is greater than or equal to 1, then some > extended diagnostic information is requested." >=20 > This is defining the diagnostic response - why would the extension be = requesting something? And if it is possible to use an extension in that = way, the expected behavior from the initiator when it receives such an = extension needs to be described, or at least it needs to be noted that a = diagnostic response could provoke a request back to the initiator. >=20 > [haibin] it is possible to reword it as "....then some extended = diagnostic information is responded.=E2=80=9D >=20 > =20 > How about =E2=80=9Cis being sent in the response=E2=80=9D? >=20 >=20 >=20 > Also, in the struct the diagnostic info is called = "diagnostic_info_contents" but in the text it is called = "diagnostic_information." These should be the same I think. >=20 > [haibin] Yes. It will be corrected. > =20 > Ok >=20 >=20 >=20 > =3D Section 5.3: >=20 > I'm concerned about the way STATUS_INFO is defined. First, why are = there 16 different levels of congestion status? What are they supposed = to signify? If there is no standardized way of measuring congestion = defined, how is a node supposed to interpret STATUS_INFO received from = different peers? That is, couldn't one peer's level 7 actually mean it = is less congested than another peer's level 3, and won't that make the = information somewhat meaningless to the initiator? Maybe this would be = clearer if you could explain what you expect an initiator to do with the = information about 16 different levels of congestion. >=20 > [haibin] Your concern makes sense. Actually it is intended to leave it = for overlay implementers or a future standard to define the congestion = level algorithms . This draft just defines the format and reserves the = bits for their use. As the section says " This document does not provide = a specific method for congestion, leaving this decision to each node. = One possible option for a node would be to take its CPU/memory/bandwidth = usage percentage in the past 600 seconds and normalize the highest value = to the range [0x00, 0x0F]. A future draft may define an objective = measure or specific algorithm for this." I think we should change the = node decision to overlay decision. And an overlay implementer may choose = to not use all that 16 values. > =20 > Ok, further clarification would help. >=20 >=20 >=20 > SOFTWARE_VERSION doesn't really seem like diagnostic information. = While all of the other fields may be constantly changing and therefore = it would make sense to inquire about them in a diagnostic fashion, = SOFTWARE_VERSION seems more like data that nodes could register or = exchange when they join the overlay. Why is it included as a diagnostic? >=20 > [haibin] Diagnostics usually take place when there are failures or = abnormal behaviors. Software version incompatibility might be a cause. > =20 > Ok, fair enough. Still seems like an odd choice to me. >=20 >=20 >=20 > Also, doesn't the SOFTWARE_VERSION type need a length or a specified = delimiter that indicates the end of the string? Otherwise, how is the = recipient supposed to know when to stop parsing it? >=20 > [haibin] Will add it. > =20 > Ok >=20 >=20 >=20 > The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem = problematic. >=20 > sent =3D alpha x sent_present + (1 - alpha) x sent > rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd >=20 > As written these equations are not right because sent/rcvd appear on = both sides. It would be clearer to use last_sent and last_rcvd or some = such on the right-hand side of these equations. But this begs some = bigger questions: >=20 > - Does this place a requirement on all nodes implementing this = specification to have to calculate these values every 5 seconds? > - How are the values calculated the first time? > - How was the value of 5 seconds chosen? >=20 > [Haibin] This is incorporated from the early RELOAD document. Maybe = some author of the RELOAD protocol can give a better explanation. >=20 > Finally, I have trouble understanding why only some of the types are = subject to access control as described in Section 7. It seems to me that = in some situations all of the fields defined here could be considered = sensitive by certain nodes or on certain networks. What is the = justification for only making some of them subject to access control? >=20 > [haibin] Actually it says different level of access control can be = made. For example, diagnostic information A can be accessed by node 1 = and 2, but diagnostic information B can only be accessed by node 2. We = can add some explanations as it seems not clear to readers. > =20 > Ok, will await the revision. >=20 >=20 >=20 >=20 > =3D Section 6.1: >=20 > "The destination field MUST be set to the desired destination, which = MAY be either a NodeId or ResourceID but SHOULD NOT be the broadcast = NodeID." >=20 > What is the expected behavior if a Ping or a PathTrack does get sent = to the broadcast NodeID? Or should these requirements really be MUST = NOTs? >=20 > [haibin] I guess they should be MUST NOTs.=20 > =20 > Ok >=20 >=20 >=20 > =3D Section 6.4: >=20 > "However, for a single hop > measurement, the traditional measurement methods MUST be used = instead > of the overlay layer diagnostics methods." >=20 > What is meant by the traditional measurement methods? >=20 > [haibin] It mainly means IP layer ping. > =20 > Would be good to specify. > =20 > Thanks, > Alissa >=20 >=20 >=20 > =3D Section 9: >=20 > Please only use either RFC-XXXX or RFC-AAAA but not both as = placeholders. >=20 > [haibin] RFC-AAAA is RFC 6940. RFC-XXXX is the placeholder. They will = be corrected. >=20 > Please also use [TBDX] for values you expect to be allocated by IANA. >=20 > [haibin] ok. >=20 > =3D=3D Nits =3D=3D >=20 >=20 > =3D General >=20 >=20 > The document seems to repeatedly explain that it is doing things "as = specified in RFC6940." I don't think this necessary in many cases. It's = worth doing a pass through and removing the places where it's obvious = that this spec is building on RFC 6940. >=20 > [haibin] ok. >=20 > =3D Section 4.1: >=20 >=20 > OLD > The extensions strictly follow RELOAD > specification on the messages routing, transport, NAT traversal etc. >=20 > NEW > The extensions strictly follow how RELOAD specifies message routing, = transport, NAT traversal, and other RELOAD protocol features. >=20 > =3D Section 4.2.1: >=20 >=20 > s/as specified in Table 4 and specified in the RELOAD/as specified in = Table 4/ >=20 > s/new requests of the the/new requests of the/ >=20 > =3D Section 4.3: >=20 > OLD > We define a simple PathTrack method for retrieving diagnostic > information iteratively. The mechanism defined in this document > follows the RELOAD specification, the new request and response > message use the message format specified in RELOAD messages. Please > refer to the RELOAD [RFC6940] for details of the protocol. >=20 > The operation of this request is shown below in Figure 2. >=20 >=20 > NEW > We define a simple PathTrack method for retrieving diagnostic > information iteratively. The operation of this request is shown = below in Figure 2. >=20 > =3D Section 4.3.1.2: >=20 > s/after that/after receiving a PathTrackAns where the next_hop node ID = equals the responding node ID/ >=20 > =3D Section 4.3.2.1: >=20 > s/PathTrack Response/PathTrack response/ >=20 > =3D Section 4.4: >=20 > s/code. and we define/code. We define/ >=20 > =3D Section 5: >=20 > s/Path_track methods/PathTrack methods/ >=20 > =3D Section 5.1: >=20 > s/Note that is NOT/Note that it is not/ >=20 > =3D Section 5.2: >=20 > s/Note that is NOT/Note that it is not/ >=20 > s/consists one or more/consists of one or more/ >=20 > =3D Section 6.1: >=20 > s/`MAY/MAY/ >=20 > =3D Section 6.2: >=20 > s/return the response the initiator node/return the response to the = initiator node/ >=20 > s/The peer SHOULD/The intermediate peer SHOULD/ >=20 > [haibin] Thanks again. >=20 > BR, > -Haibin Song >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip = >=20 > =20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip = --Apple-Mail=_8BAFB117-0CC2-49B3-BFC3-83C770B3B0CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks Haibin. This looks good but there are = still a few unresolved issues from our earlier mail exchange:

The definitions of EWMA_BYTES_SENT = and EWMA_BYTES_RCVD seem problematic.

sent =3D alpha x sent_present + (1 - alpha) x sent
rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd

As written these equations are not right = because sent/rcvd appear on both sides. It would be clearer to use = last_sent and last_rcvd or some such on the right-hand side of these = equations. But this begs some bigger questions:

- Does this place a requirement on all nodes implementing = this specification to have to calculate these values every 5 seconds?
- How are the values calculated the first time?
-= How was the value of 5 seconds chosen?

[Haibin] This is incorporated from the early RELOAD document. = Maybe some author of the RELOAD protocol can give a better = explanation.

This still has not been = explained.


Finally, I have trouble understanding why only = some of the types are subject to access control as described in Section = 7. It seems to me that in some situations all of the fields defined here = could be considered sensitive by certain nodes or on certain networks. = What is the justification for only making some of them subject to access = control?

[haibin] Actually it says = different level of access control can be made. For example, diagnostic = information A can be accessed by node 1 and 2, but diagnostic = information B can only be accessed by node 2. We can add some = explanations as it seems not clear to readers.

Although I see the new text, the = problem still remains that in Section 5.3 only some of the fields have = this disclaimer:

Access to this kind of diagnostic information MUST
      NOT be allowed unless compliant to the rules defined in Section 7.

I think the disclaimer should = apply to all of the fields, not only a selection of them. As such, I = would recommend just putting the disclaimer once at the top of section = 5.3 and explaining that it applies to all of the fields.

Thanks,
Alissa

On Nov 8, 2015, at 5:41 PM, Songhaibin (A) = <haibin.song@huawei.com> wrote:

Hi Alissa,
 
The revision of this draft is now available. Please check if = it solves your comments.
 
Best Regards!
-Haibin
 
From: Alissa Cooper [mailto:alissa@cooperw.in] 
Sent: Saturday, October 03, 2015 = 8:06 PM
To: Songhaibin (A)
Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: [P2PSIP] AD evaluation: = draft-ietf-p2psip-diagnostics-17
 
Wanted to check if a rev of this document is forthcoming?
 
Thanks,
Alissa
 
On Sep 4, 2015, at 3:51 PM, Alissa Cooper = <alissa@cooperw.in> = wrote:
 
Thanks for the reply. = Comments are inline.
 
On Aug 20, 2015, at 8:22 PM, Songhaibin (A) <haibin.song@huawei.com> = wrote:
 
Hi Alissa,

Thank you for the = comments. Please find my explanations in line with [haibin].


Thanks. I did have one further thought for = Section 8. It strikes me that the combination of diagnostic elements = that this spec makes available could easily be used to fingerprint a = peer in an overlay where peers may otherwise be attempting to remain = anonymous. Although defenses against such fingerprinting are probably = hard to come by (short of disallowing access to the diagnostics via the = config file), the threat is worth noting at least.


[haibin]Actually = we imply your concern with the sentence "It should also be noted that = attackers can use diagnostics to analyze overlay information to attack = certain key peers." But we could elaborate more in this section.

 
Yes, further = elaboration would be appreciated.



From: Alissa Cooper [mailto:alissa@cooperw.in] 
Sent: = Wednesday, August 19, 2015 12:04 AM
To: David Bryan
Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: [P2PSIP] AD evaluation: = draft-ietf-p2psip-diagnostics-17

On Aug 17, = 2015, at 8:54 AM, David Bryan <dbryan@ethernot.org> wrote:


Thanks for the comments. I'll circle back with = the team and will revise.

Thanks. I did = have one further thought for Section 8. It strikes me that the = combination of diagnostic elements that this spec makes available could = easily be used to fingerprint a peer in an overlay where peers may = otherwise be attempting to remain anonymous. Although defenses against = such fingerprinting are probably hard to come by (short of disallowing = access to the diagnostics via the config file), the threat is worth = noting at least.



I have to check, but I actually think the first few versions = of this (when it was individual) *may* be pre-5378, but will double = check.

Ah ok.

[haibin] It is true that the first version of the individual = draft is pre-5378.
 
Ok, my mistake = then.



Alissa



On Fri, Aug 14, 2015 at 6:33 PM, Alissa Cooper <alissa@cooperw.in> = wrote:
I have reviewed this document in preparation for = IETF last call. Before proceeding to last call, I have some comments and = questions that I'd like to discuss. I've also included a list of nits = that should be resolved together with any last call comments.


=3D=3D Substantive comments and = questions =3D=3D

=3D General 

I think this document should be listed as = updating RFC 6940 in the document header.

The= document contains a disclaimer for pre-RFC5378 work, which I = assume is in error. If using xml2rfc to generate the text, using the = most up-to-date version of xml2rfc to create the next version should fix = this.

=3D Section 4.3:

"There have been proposals that RouteQuery and a series of = Fetch
  requests can be used to replace the = PathTrack mechanism, but in the
  presence of = churn such an operation would not, strictly speaking,
  provide identical results, as the path may change = between RouteQuery
  and Fetch operations. = (although obviously the path could change
  between steps of PathTrack as well)."

This text is confusing. It doesn't explain why = PathTrack is being defined rather than peers using RouteQuery plus = Fetch. Furthermore, the document does not explain how peers are supposed = to interpret the results of the PathTrack method in the event that the = route does change in between steps. This seems like a substantial = omission.

[haibin] This is a good question. = As the route change is a problem (with little probability), we would = like to retrieve diagnostics info in an efficient way, so one simple = message is preferred. And you are right, it does not change the truth = that route can change  in between steps. We need re-wording the = section. The implication of route change is that, the result of the = diagnostics cannot be trusted with one hundred percent, which should be = noted to the users that perform the diagnostics.
 
Ok, new text would be = appreciated.



In general, this document provides very little information = about how peers are expected to interpret and use the diagnostic = information. I understand that peers can do whatever they want with it, = but in several places the fact that this is not explained makes the = reasoning behind the protocol design decisions opaque. I would suggest = providing a little more context, at the very least by moving the = examples into the body of the draft somewhere. 

[haibin] We can add some more explanations with diagnostics = info interpretation. 
 
Ok, good.



=3D Section 4.4:

I'm a little = confused about the values given for the error codes. Do you want IANA to = chose these specific values? Or are they just there as placeholders? The = customary way of doing placeholders would be as follows:
Code Value =         Error Code Name
     [TBD1] =             &n= bsp; Underlay Destination Unreachable
     [TBD2] =             &n= bsp; Underlay Time exceeded
     [TBD3] =             &n= bsp; Message Expired
     [TBD4] =             &n= bsp; Upstream Misrouting
     [TBD5] =             &n= bsp; Loop detected
     [TBD6]= =             &n= bsp; TTL hops exceeded

These = placeholders would then get used throughout the document.

[haibin] they are place holders. 
 
Ok, please clarify it = in the document in that case.



This section also says:

"In addition, this document introduces several types of error = information in the error_info field in the case of Code 0x65. ... Here = are some examples for the error info. ... The error_info field values of = the Code 0x66 to 0x70 are to be application specific and defined by the = particular overlay."


I'm not = sure what is meant by all of this text. As defined in RFC 6940, = error_info is an optional implementation-specific byte string. If you = are intending to require implementations to include specific text in the = error_info for the first error code, then you need to explain under what = conditions the specific text needs to be included for each string. And = the text about the other codes seems redundant with how error_info is = already defined in RFC 6940.


[haibin] if a peer receives a diagnostic request found that = it cannot reach its next hop due to underlay problem, it needs to = explain with error_info what happened. I do not know what you mean by = redundant with RFC 6940. They are different errors.
 
Maybe it=E2=80=99s = just a language thing, but the first sentence saying =E2=80=9Cthis = document introduces =E2=80=A6=E2=80=9D makes it sound like the list of = strings is more than just a list of examples. If these are just examples = that implementations can choose to use or not, I would suggest the = following re-phrasing:
 
OLD
In addition, this document introduces several types of =
error
   information in the error_info field in the case =
of Code 0x65.  These
   are represented as an opaque UTF-8 text =
string.  Here are some
   examples for the error info.
 
 
NEW
Here are some examples of errors that might be expressed =
using the error_info field in the case of Code [TBD1]:
 



=3D Section 5.2:


"ext_length : the length of the = returned DiagnosticInfo information
     in bytes.  If the value is = greater than or equal to 1, then some
     extended diagnostic information = is requested."

This is defining the = diagnostic response - why would the extension be requesting something? = And if it is possible to use an extension in that way, the expected = behavior from the initiator when it receives such an extension needs to = be described, or at least it needs to be noted that a diagnostic = response could provoke a request back to the initiator.

[haibin] it is possible to reword it as "....then some = extended diagnostic information is responded.=E2=80=9D

 
How about =E2=80=9Cis being = sent in the response=E2=80=9D?



Also, in the struct the diagnostic info is called = "diagnostic_info_contents" but in the text it is = called "diagnostic_information." These should be the same I = think.

[haibin] Yes. It will be = corrected.
 
Ok



=3D Section 5.3:

I'm concerned = about the way STATUS_INFO is defined. First, why are there 16 different = levels of congestion status? What are they supposed to signify? If there = is no standardized way of measuring congestion defined, how is a node = supposed to interpret STATUS_INFO received from different peers? That = is, couldn't one peer's level 7 actually mean it is less congested than = another peer's level 3, and won't that make the information somewhat = meaningless to the initiator? Maybe this would be clearer if you could = explain what you expect an initiator to do with the information about 16 = different levels of congestion.

[haibin] = Your concern makes sense. Actually it is intended to leave it for = overlay implementers or a future standard to define the congestion level = algorithms . This draft just defines the format and reserves the bits = for their use. As the section says " This document does not provide a = specific method for congestion, leaving this decision to each node. =  One possible option for a node would be to take its = CPU/memory/bandwidth usage percentage in the past 600 seconds and = normalize the highest value to the range [0x00, 0x0F].  A future = draft may define an objective measure or specific algorithm for this." I = think we should change the node decision to overlay decision. And an = overlay implementer may choose to not use all that 16 values.
 
Ok, further = clarification would help.



SOFTWARE_VERSION doesn't really seem like = diagnostic information. While all of the other fields may be constantly = changing and therefore it would make sense to inquire about them in a = diagnostic fashion, SOFTWARE_VERSION seems more like data that nodes = could register or exchange when they join the overlay. Why is it = included as a diagnostic?

[haibin] = Diagnostics usually take place when there are failures or abnormal = behaviors. Software version incompatibility might be a cause.
 
Ok, fair enough. = Still seems like an odd choice to me.



Also, doesn't the SOFTWARE_VERSION type need a length or a = specified delimiter that indicates the end of the string? Otherwise, how = is the recipient supposed to know when to stop parsing it?

[haibin] Will add it.
 
Ok



The definitions of EWMA_BYTES_SENT = and EWMA_BYTES_RCVD seem problematic.

sent =3D alpha x sent_present + (1 - alpha) x sent
rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd

As written these equations are not right = because sent/rcvd appear on both sides. It would be clearer to use = last_sent and last_rcvd or some such on the right-hand side of these = equations. But this begs some bigger questions:

- Does this place a requirement on all nodes implementing = this specification to have to calculate these values every 5 seconds?
- How are the values calculated the first time?
-= How was the value of 5 seconds chosen?

[Haibin] This is incorporated from the early RELOAD document. = Maybe some author of the RELOAD protocol can give a better = explanation.

Finally, I have trouble = understanding why only some of the types are subject to access control = as described in Section 7. It seems to me that in some situations all of = the fields defined here could be considered sensitive by certain nodes = or on certain networks. What is the justification for only making some = of them subject to access control?

[haibin] = Actually it says different level of access control can be made. For = example, diagnostic information A can be accessed by node 1 and 2, but = diagnostic information B can only be accessed by node 2. We can add some = explanations as it seems not clear to readers.
 
Ok, will await the = revision.




=3D Section 6.1:

"The destination field MUST be set to the desired = destination, which MAY be either a NodeId or ResourceID but SHOULD = NOT be the broadcast NodeID."

What is = the expected behavior if a Ping or a PathTrack does get sent to the = broadcast NodeID? Or should these requirements really be MUST NOTs?

[haibin] I guess they should be MUST = NOTs. 
 
Ok



=3D Section 6.4:

"However, for a = single hop
  measurement, the traditional = measurement methods MUST be used instead
  of = the overlay layer diagnostics methods."

What = is meant by the traditional measurement methods?

[haibin] It mainly means IP layer ping.
 
Would be good to = specify.
 
Thanks,
Alissa



=3D Section 9:

Please only use either RFC-XXXX or RFC-AAAA but not both as = placeholders.

[haibin] RFC-AAAA is RFC = 6940. RFC-XXXX is the placeholder. They will be corrected.

Please also use [TBDX] for values you expect = to be allocated by IANA.

[haibin] ok.

=3D=3D Nits =3D=3D


=3D General


The document seems to repeatedly explain that it is doing = things "as specified in RFC6940." I don't think this necessary in many = cases. It's worth doing a pass through and removing the places where = it's obvious that this spec is building on RFC 6940.

[haibin] ok.

=3D Section 4.1:


OLD
The = extensions strictly follow RELOAD
  specification = on the messages routing, transport, NAT traversal etc.

NEW
The extensions strictly follow how RELOAD = specifies message routing, transport, NAT traversal, and other RELOAD = protocol features.

=3D Section 4.2.1:


s/as specified in Table 4 = and specified in the RELOAD/as specified in Table 4/

s/new requests of the the/new requests of = the/

=3D Section 4.3:

OLD
We define a simple PathTrack method for = retrieving diagnostic
  information iteratively. =  The mechanism defined in this document
  follows the RELOAD specification, the new request = and response
  message use the message format = specified in RELOAD messages.  Please
  refer= to the RELOAD [RFC6940] for details of the protocol.

  The operation of this request is shown below in = Figure 2.


NEW
We= define a simple PathTrack method for retrieving diagnostic
  information iteratively.  The operation of = this request is shown below in Figure 2.

=3D = Section 4.3.1.2:

s/after that/after = receiving a PathTrackAns where the next_hop node ID equals the = responding node ID/

=3D Section 4.3.2.1:

s/PathTrack Response/PathTrack response/

=3D Section 4.4:

s/code. and we define/code. We define/

=3D Section 5:

s/Path_track = methods/PathTrack methods/

=3D Section = 5.1:

s/Note that is NOT/Note that it is = not/

=3D Section 5.2:

s/Note that is NOT/Note that it is not/

s/consists one or more/consists of one or more/

=3D Section 6.1:

s/`MAY/MAY/

=3D Section 6.2:

s/return the response the initiator = node/return the response to the initiator node/

s/The peer SHOULD/The intermediate peer SHOULD/

[haibin] Thanks again.

BR,
-Haibin Song

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

 
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

= --Apple-Mail=_8BAFB117-0CC2-49B3-BFC3-83C770B3B0CE-- From nobody Mon Nov 16 22:45:05 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38ED1B2AEE for ; Mon, 16 Nov 2015 22:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 2WLdwKU25Zog for ; Mon, 16 Nov 2015 22:44:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29C51B2AE7 for ; Mon, 16 Nov 2015 22:44:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEF21792; Tue, 17 Nov 2015 06:44:51 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 Nov 2015 06:44:49 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Tue, 17 Nov 2015 14:44:43 +0800 From: "Songhaibin (A)" To: Alissa Cooper Thread-Topic: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 Thread-Index: AQHQ1umosqhZ/UWGA0i8P+k8SWdo8p4P1gUAgAGVAoCAAygiwIAYAXYAgCzfIQCAOf21AIAEBqUAgAjfnlA= Date: Tue, 17 Nov 2015 06:44:42 +0000 Message-ID: References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> In-Reply-To: <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F653C3123nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.564ACCE4.0090, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c03296527b7c6c575a7777d119ab3ce Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 06:45:04 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F653C3123nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpc3NhLA0KDQpJIGNhbiBhY2NlcHQgdGhlIHNlY29uZCBzdWdnZXN0aW9uLg0KDQpCdXQg Zm9yIHRoZSBmaXJzdCBjb21tZW50LCBJ4oCZbSBub3Qgc3VyZS4gSU1PLCBpdCBkb2VzIG5vdCBk aXN0aW5ndWlzaCB0aGUgYnl0ZXMgc2VudC9yY3ZkIHRvL2Zyb20gdXBzdHJlYW0gb3IgZG93bnN0 cmVhbSBwZWVyLCBidXQgb25seSBjYWxjdWxhdGUgdGhhdCBpbiB0b3RhbC4NCg0KQmVzdCBSZWdh cmRzIQ0KLUhhaWJpbg0KDQpGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNvb3Bl cncuaW5dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTIsIDIwMTUgNzoxMCBBTQ0KVG86IFNv bmdoYWliaW4gKEEpDQpDYzogcDJwc2lwOyBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0 b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQMlBTSVBdIEFEIGV2YWx1YXRpb246IGRyYWZ0 LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzLTE3DQoNClRoYW5rcyBIYWliaW4uIFRoaXMgbG9va3Mg Z29vZCBidXQgdGhlcmUgYXJlIHN0aWxsIGEgZmV3IHVucmVzb2x2ZWQgaXNzdWVzIGZyb20gb3Vy IGVhcmxpZXIgbWFpbCBleGNoYW5nZToNCg0KVGhlIGRlZmluaXRpb25zIG9mIEVXTUFfQllURVNf U0VOVCBhbmQgRVdNQV9CWVRFU19SQ1ZEIHNlZW0gcHJvYmxlbWF0aWMuDQoNCnNlbnQgPSBhbHBo YSB4IHNlbnRfcHJlc2VudCArICgxIC0gYWxwaGEpIHggc2VudA0KcmN2ZCA9IGFscGhhIHggcmN2 ZF9wcmVzZW50ICsgKDEgLSBhbHBoYSkgeCByY3ZkDQoNCkFzIHdyaXR0ZW4gdGhlc2UgZXF1YXRp b25zIGFyZSBub3QgcmlnaHQgYmVjYXVzZSBzZW50L3JjdmQgYXBwZWFyIG9uIGJvdGggc2lkZXMu IEl0IHdvdWxkIGJlIGNsZWFyZXIgdG8gdXNlIGxhc3Rfc2VudCBhbmQgbGFzdF9yY3ZkIG9yIHNv bWUgc3VjaCBvbiB0aGUgcmlnaHQtaGFuZCBzaWRlIG9mIHRoZXNlIGVxdWF0aW9ucy4gQnV0IHRo aXMgYmVncyBzb21lIGJpZ2dlciBxdWVzdGlvbnM6DQoNCi0gRG9lcyB0aGlzIHBsYWNlIGEgcmVx dWlyZW1lbnQgb24gYWxsIG5vZGVzIGltcGxlbWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24gdG8g aGF2ZSB0byBjYWxjdWxhdGUgdGhlc2UgdmFsdWVzIGV2ZXJ5IDUgc2Vjb25kcz8NCi0gSG93IGFy ZSB0aGUgdmFsdWVzIGNhbGN1bGF0ZWQgdGhlIGZpcnN0IHRpbWU/DQotIEhvdyB3YXMgdGhlIHZh bHVlIG9mIDUgc2Vjb25kcyBjaG9zZW4/DQoNCltIYWliaW5dIFRoaXMgaXMgaW5jb3Jwb3JhdGVk IGZyb20gdGhlIGVhcmx5IFJFTE9BRCBkb2N1bWVudC4gTWF5YmUgc29tZSBhdXRob3Igb2YgdGhl IFJFTE9BRCBwcm90b2NvbCBjYW4gZ2l2ZSBhIGJldHRlciBleHBsYW5hdGlvbi4NCg0KVGhpcyBz dGlsbCBoYXMgbm90IGJlZW4gZXhwbGFpbmVkLg0KDQoNCg0KRmluYWxseSwgSSBoYXZlIHRyb3Vi bGUgdW5kZXJzdGFuZGluZyB3aHkgb25seSBzb21lIG9mIHRoZSB0eXBlcyBhcmUgc3ViamVjdCB0 byBhY2Nlc3MgY29udHJvbCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA3LiBJdCBzZWVtcyB0byBt ZSB0aGF0IGluIHNvbWUgc2l0dWF0aW9ucyBhbGwgb2YgdGhlIGZpZWxkcyBkZWZpbmVkIGhlcmUg Y291bGQgYmUgY29uc2lkZXJlZCBzZW5zaXRpdmUgYnkgY2VydGFpbiBub2RlcyBvciBvbiBjZXJ0 YWluIG5ldHdvcmtzLiBXaGF0IGlzIHRoZSBqdXN0aWZpY2F0aW9uIGZvciBvbmx5IG1ha2luZyBz b21lIG9mIHRoZW0gc3ViamVjdCB0byBhY2Nlc3MgY29udHJvbD8NCg0KW2hhaWJpbl0gQWN0dWFs bHkgaXQgc2F5cyBkaWZmZXJlbnQgbGV2ZWwgb2YgYWNjZXNzIGNvbnRyb2wgY2FuIGJlIG1hZGUu IEZvciBleGFtcGxlLCBkaWFnbm9zdGljIGluZm9ybWF0aW9uIEEgY2FuIGJlIGFjY2Vzc2VkIGJ5 IG5vZGUgMSBhbmQgMiwgYnV0IGRpYWdub3N0aWMgaW5mb3JtYXRpb24gQiBjYW4gb25seSBiZSBh Y2Nlc3NlZCBieSBub2RlIDIuIFdlIGNhbiBhZGQgc29tZSBleHBsYW5hdGlvbnMgYXMgaXQgc2Vl bXMgbm90IGNsZWFyIHRvIHJlYWRlcnMuDQoNCkFsdGhvdWdoIEkgc2VlIHRoZSBuZXcgdGV4dCwg dGhlIHByb2JsZW0gc3RpbGwgcmVtYWlucyB0aGF0IGluIFNlY3Rpb24gNS4zIG9ubHkgc29tZSBv ZiB0aGUgZmllbGRzIGhhdmUgdGhpcyBkaXNjbGFpbWVyOg0KDQoNCkFjY2VzcyB0byB0aGlzIGtp bmQgb2YgZGlhZ25vc3RpYyBpbmZvcm1hdGlvbiBNVVNUDQoNCiAgICAgIE5PVCBiZSBhbGxvd2Vk IHVubGVzcyBjb21wbGlhbnQgdG8gdGhlIHJ1bGVzIGRlZmluZWQgaW4gU2VjdGlvbiA3PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xOCNz ZWN0aW9uLTc+Lg0KDQpJIHRoaW5rIHRoZSBkaXNjbGFpbWVyIHNob3VsZCBhcHBseSB0byBhbGwg b2YgdGhlIGZpZWxkcywgbm90IG9ubHkgYSBzZWxlY3Rpb24gb2YgdGhlbS4gQXMgc3VjaCwgSSB3 b3VsZCByZWNvbW1lbmQganVzdCBwdXR0aW5nIHRoZSBkaXNjbGFpbWVyIG9uY2UgYXQgdGhlIHRv cCBvZiBzZWN0aW9uIDUuMyBhbmQgZXhwbGFpbmluZyB0aGF0IGl0IGFwcGxpZXMgdG8gYWxsIG9m IHRoZSBmaWVsZHMuDQoNClRoYW5rcywNCkFsaXNzYQ0KDQpPbiBOb3YgOCwgMjAxNSwgYXQgNTo0 MSBQTSwgU29uZ2hhaWJpbiAoQSkgPGhhaWJpbi5zb25nQGh1YXdlaS5jb208bWFpbHRvOmhhaWJp bi5zb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQWxpc3NhLA0KDQpUaGUgcmV2aXNpb24g b2YgdGhpcyBkcmFmdCBpcyBub3cgYXZhaWxhYmxlLiBQbGVhc2UgY2hlY2sgaWYgaXQgc29sdmVz IHlvdXIgY29tbWVudHMuDQoNCkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCg0KRnJvbTogQWxpc3Nh IENvb3BlciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KU2VudDogU2F0dXJkYXksIE9jdG9i ZXIgMDMsIDIwMTUgODowNiBQTQ0KVG86IFNvbmdoYWliaW4gKEEpDQpDYzogcDJwc2lwOyBkcmFm dC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1wMnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1AyUFNJ UF0gQUQgZXZhbHVhdGlvbjogZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTcNCg0KV2Fu dGVkIHRvIGNoZWNrIGlmIGEgcmV2IG9mIHRoaXMgZG9jdW1lbnQgaXMgZm9ydGhjb21pbmc/DQoN ClRoYW5rcywNCkFsaXNzYQ0KDQpPbiBTZXAgNCwgMjAxNSwgYXQgMzo1MSBQTSwgQWxpc3NhIENv b3BlciA8YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4gd3JvdGU6 DQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LiBDb21tZW50cyBhcmUgaW5saW5lLg0KDQpPbiBBdWcg MjAsIDIwMTUsIGF0IDg6MjIgUE0sIFNvbmdoYWliaW4gKEEpIDxoYWliaW4uc29uZ0BodWF3ZWku Y29tPG1haWx0bzpoYWliaW4uc29uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkhpIEFsaXNzYSwN Cg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIFBsZWFzZSBmaW5kIG15IGV4cGxhbmF0aW9u cyBpbiBsaW5lIHdpdGggW2hhaWJpbl0uDQoNCg0KDQpUaGFua3MuIEkgZGlkIGhhdmUgb25lIGZ1 cnRoZXIgdGhvdWdodCBmb3IgU2VjdGlvbiA4LiBJdCBzdHJpa2VzIG1lIHRoYXQgdGhlIGNvbWJp bmF0aW9uIG9mIGRpYWdub3N0aWMgZWxlbWVudHMgdGhhdCB0aGlzIHNwZWMgbWFrZXMgYXZhaWxh YmxlIGNvdWxkIGVhc2lseSBiZSB1c2VkIHRvIGZpbmdlcnByaW50IGEgcGVlciBpbiBhbiBvdmVy bGF5IHdoZXJlIHBlZXJzIG1heSBvdGhlcndpc2UgYmUgYXR0ZW1wdGluZyB0byByZW1haW4gYW5v bnltb3VzLiBBbHRob3VnaCBkZWZlbnNlcyBhZ2FpbnN0IHN1Y2ggZmluZ2VycHJpbnRpbmcgYXJl IHByb2JhYmx5IGhhcmQgdG8gY29tZSBieSAoc2hvcnQgb2YgZGlzYWxsb3dpbmcgYWNjZXNzIHRv IHRoZSBkaWFnbm9zdGljcyB2aWEgdGhlIGNvbmZpZyBmaWxlKSwgdGhlIHRocmVhdCBpcyB3b3J0 aCBub3RpbmcgYXQgbGVhc3QuDQoNCltoYWliaW5dQWN0dWFsbHkgd2UgaW1wbHkgeW91ciBjb25j ZXJuIHdpdGggdGhlIHNlbnRlbmNlICJJdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0IGF0dGFj a2VycyBjYW4gdXNlIGRpYWdub3N0aWNzIHRvIGFuYWx5emUgb3ZlcmxheSBpbmZvcm1hdGlvbiB0 byBhdHRhY2sgY2VydGFpbiBrZXkgcGVlcnMuIiBCdXQgd2UgY291bGQgZWxhYm9yYXRlIG1vcmUg aW4gdGhpcyBzZWN0aW9uLg0KDQpZZXMsIGZ1cnRoZXIgZWxhYm9yYXRpb24gd291bGQgYmUgYXBw cmVjaWF0ZWQuDQoNCg0KDQoNCkZyb206IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29v cGVydy5pbl0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5LCAyMDE1IDEyOjA0IEFNDQpUbzog RGF2aWQgQnJ5YW4NCkNjOiBwMnBzaXA7IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0b29scy5p ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBBRCBldmFsdWF0aW9uOiBkcmFmdC1pZXRm LXAycHNpcC1kaWFnbm9zdGljcy0xNw0KDQpPbiBBdWcgMTcsIDIwMTUsIGF0IDg6NTQgQU0sIERh dmlkIEJyeWFuIDxkYnJ5YW5AZXRoZXJub3Qub3JnPG1haWx0bzpkYnJ5YW5AZXRoZXJub3Qub3Jn Pj4gd3JvdGU6DQoNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEknbGwgY2lyY2xlIGJhY2sg d2l0aCB0aGUgdGVhbSBhbmQgd2lsbCByZXZpc2UuDQoNClRoYW5rcy4gSSBkaWQgaGF2ZSBvbmUg ZnVydGhlciB0aG91Z2h0IGZvciBTZWN0aW9uIDguIEl0IHN0cmlrZXMgbWUgdGhhdCB0aGUgY29t YmluYXRpb24gb2YgZGlhZ25vc3RpYyBlbGVtZW50cyB0aGF0IHRoaXMgc3BlYyBtYWtlcyBhdmFp bGFibGUgY291bGQgZWFzaWx5IGJlIHVzZWQgdG8gZmluZ2VycHJpbnQgYSBwZWVyIGluIGFuIG92 ZXJsYXkgd2hlcmUgcGVlcnMgbWF5IG90aGVyd2lzZSBiZSBhdHRlbXB0aW5nIHRvIHJlbWFpbiBh bm9ueW1vdXMuIEFsdGhvdWdoIGRlZmVuc2VzIGFnYWluc3Qgc3VjaCBmaW5nZXJwcmludGluZyBh cmUgcHJvYmFibHkgaGFyZCB0byBjb21lIGJ5IChzaG9ydCBvZiBkaXNhbGxvd2luZyBhY2Nlc3Mg dG8gdGhlIGRpYWdub3N0aWNzIHZpYSB0aGUgY29uZmlnIGZpbGUpLCB0aGUgdGhyZWF0IGlzIHdv cnRoIG5vdGluZyBhdCBsZWFzdC4NCg0KDQoNCkkgaGF2ZSB0byBjaGVjaywgYnV0IEkgYWN0dWFs bHkgdGhpbmsgdGhlIGZpcnN0IGZldyB2ZXJzaW9ucyBvZiB0aGlzICh3aGVuIGl0IHdhcyBpbmRp dmlkdWFsKSAqbWF5KiBiZSBwcmUtNTM3OCwgYnV0IHdpbGwgZG91YmxlIGNoZWNrLg0KDQpBaCBv ay4NCg0KW2hhaWJpbl0gSXQgaXMgdHJ1ZSB0aGF0IHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBp bmRpdmlkdWFsIGRyYWZ0IGlzIHByZS01Mzc4Lg0KDQpPaywgbXkgbWlzdGFrZSB0aGVuLg0KDQoN Cg0KDQpBbGlzc2ENCg0KDQoNCk9uIEZyaSwgQXVnIDE0LCAyMDE1IGF0IDY6MzMgUE0sIEFsaXNz YSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5pbj4+IHdy b3RlOg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgaW4gcHJlcGFyYXRpb24gZm9yIElF VEYgbGFzdCBjYWxsLiBCZWZvcmUgcHJvY2VlZGluZyB0byBsYXN0IGNhbGwsIEkgaGF2ZSBzb21l IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgdGhhdCBJJ2QgbGlrZSB0byBkaXNjdXNzLiBJJ3ZlIGFs c28gaW5jbHVkZWQgYSBsaXN0IG9mIG5pdHMgdGhhdCBzaG91bGQgYmUgcmVzb2x2ZWQgdG9nZXRo ZXIgd2l0aCBhbnkgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoNCj09IFN1YnN0YW50aXZlIGNvbW1l bnRzIGFuZCBxdWVzdGlvbnMgPT0NCg0KPSBHZW5lcmFsDQoNCkkgdGhpbmsgdGhpcyBkb2N1bWVu dCBzaG91bGQgYmUgbGlzdGVkIGFzIHVwZGF0aW5nIFJGQyA2OTQwIGluIHRoZSBkb2N1bWVudCBo ZWFkZXIuDQoNClRoZSBkb2N1bWVudCBjb250YWlucyBhIGRpc2NsYWltZXIgZm9yIHByZS1SRkM1 Mzc4IHdvcmssIHdoaWNoIEkgYXNzdW1lIGlzIGluIGVycm9yLiBJZiB1c2luZyB4bWwycmZjIHRv IGdlbmVyYXRlIHRoZSB0ZXh0LCB1c2luZyB0aGUgbW9zdCB1cC10by1kYXRlIHZlcnNpb24gb2Yg eG1sMnJmYyB0byBjcmVhdGUgdGhlIG5leHQgdmVyc2lvbiBzaG91bGQgZml4IHRoaXMuDQoNCj0g U2VjdGlvbiA0LjM6DQoNCiJUaGVyZSBoYXZlIGJlZW4gcHJvcG9zYWxzIHRoYXQgUm91dGVRdWVy eSBhbmQgYSBzZXJpZXMgb2YgRmV0Y2gNCiAgcmVxdWVzdHMgY2FuIGJlIHVzZWQgdG8gcmVwbGFj ZSB0aGUgUGF0aFRyYWNrIG1lY2hhbmlzbSwgYnV0IGluIHRoZQ0KICBwcmVzZW5jZSBvZiBjaHVy biBzdWNoIGFuIG9wZXJhdGlvbiB3b3VsZCBub3QsIHN0cmljdGx5IHNwZWFraW5nLA0KICBwcm92 aWRlIGlkZW50aWNhbCByZXN1bHRzLCBhcyB0aGUgcGF0aCBtYXkgY2hhbmdlIGJldHdlZW4gUm91 dGVRdWVyeQ0KICBhbmQgRmV0Y2ggb3BlcmF0aW9ucy4gKGFsdGhvdWdoIG9idmlvdXNseSB0aGUg cGF0aCBjb3VsZCBjaGFuZ2UNCiAgYmV0d2VlbiBzdGVwcyBvZiBQYXRoVHJhY2sgYXMgd2VsbCku Ig0KDQpUaGlzIHRleHQgaXMgY29uZnVzaW5nLiBJdCBkb2Vzbid0IGV4cGxhaW4gd2h5IFBhdGhU cmFjayBpcyBiZWluZyBkZWZpbmVkIHJhdGhlciB0aGFuIHBlZXJzIHVzaW5nIFJvdXRlUXVlcnkg cGx1cyBGZXRjaC4gRnVydGhlcm1vcmUsIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBleHBsYWluIGhv dyBwZWVycyBhcmUgc3VwcG9zZWQgdG8gaW50ZXJwcmV0IHRoZSByZXN1bHRzIG9mIHRoZSBQYXRo VHJhY2sgbWV0aG9kIGluIHRoZSBldmVudCB0aGF0IHRoZSByb3V0ZSBkb2VzIGNoYW5nZSBpbiBi ZXR3ZWVuIHN0ZXBzLiBUaGlzIHNlZW1zIGxpa2UgYSBzdWJzdGFudGlhbCBvbWlzc2lvbi4NCg0K W2hhaWJpbl0gVGhpcyBpcyBhIGdvb2QgcXVlc3Rpb24uIEFzIHRoZSByb3V0ZSBjaGFuZ2UgaXMg YSBwcm9ibGVtICh3aXRoIGxpdHRsZSBwcm9iYWJpbGl0eSksIHdlIHdvdWxkIGxpa2UgdG8gcmV0 cmlldmUgZGlhZ25vc3RpY3MgaW5mbyBpbiBhbiBlZmZpY2llbnQgd2F5LCBzbyBvbmUgc2ltcGxl IG1lc3NhZ2UgaXMgcHJlZmVycmVkLiBBbmQgeW91IGFyZSByaWdodCwgaXQgZG9lcyBub3QgY2hh bmdlIHRoZSB0cnV0aCB0aGF0IHJvdXRlIGNhbiBjaGFuZ2UgIGluIGJldHdlZW4gc3RlcHMuIFdl IG5lZWQgcmUtd29yZGluZyB0aGUgc2VjdGlvbi4gVGhlIGltcGxpY2F0aW9uIG9mIHJvdXRlIGNo YW5nZSBpcyB0aGF0LCB0aGUgcmVzdWx0IG9mIHRoZSBkaWFnbm9zdGljcyBjYW5ub3QgYmUgdHJ1 c3RlZCB3aXRoIG9uZSBodW5kcmVkIHBlcmNlbnQsIHdoaWNoIHNob3VsZCBiZSBub3RlZCB0byB0 aGUgdXNlcnMgdGhhdCBwZXJmb3JtIHRoZSBkaWFnbm9zdGljcy4NCg0KT2ssIG5ldyB0ZXh0IHdv dWxkIGJlIGFwcHJlY2lhdGVkLg0KDQoNCg0KDQpJbiBnZW5lcmFsLCB0aGlzIGRvY3VtZW50IHBy b3ZpZGVzIHZlcnkgbGl0dGxlIGluZm9ybWF0aW9uIGFib3V0IGhvdyBwZWVycyBhcmUgZXhwZWN0 ZWQgdG8gaW50ZXJwcmV0IGFuZCB1c2UgdGhlIGRpYWdub3N0aWMgaW5mb3JtYXRpb24uIEkgdW5k ZXJzdGFuZCB0aGF0IHBlZXJzIGNhbiBkbyB3aGF0ZXZlciB0aGV5IHdhbnQgd2l0aCBpdCwgYnV0 IGluIHNldmVyYWwgcGxhY2VzIHRoZSBmYWN0IHRoYXQgdGhpcyBpcyBub3QgZXhwbGFpbmVkIG1h a2VzIHRoZSByZWFzb25pbmcgYmVoaW5kIHRoZSBwcm90b2NvbCBkZXNpZ24gZGVjaXNpb25zIG9w YXF1ZS4gSSB3b3VsZCBzdWdnZXN0IHByb3ZpZGluZyBhIGxpdHRsZSBtb3JlIGNvbnRleHQsIGF0 IHRoZSB2ZXJ5IGxlYXN0IGJ5IG1vdmluZyB0aGUgZXhhbXBsZXMgaW50byB0aGUgYm9keSBvZiB0 aGUgZHJhZnQgc29tZXdoZXJlLg0KDQpbaGFpYmluXSBXZSBjYW4gYWRkIHNvbWUgbW9yZSBleHBs YW5hdGlvbnMgd2l0aCBkaWFnbm9zdGljcyBpbmZvIGludGVycHJldGF0aW9uLg0KDQpPaywgZ29v ZC4NCg0KDQoNCg0KPSBTZWN0aW9uIDQuNDoNCg0KSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0 IHRoZSB2YWx1ZXMgZ2l2ZW4gZm9yIHRoZSBlcnJvciBjb2Rlcy4gRG8geW91IHdhbnQgSUFOQSB0 byBjaG9zZSB0aGVzZSBzcGVjaWZpYyB2YWx1ZXM/IE9yIGFyZSB0aGV5IGp1c3QgdGhlcmUgYXMg cGxhY2Vob2xkZXJzPyBUaGUgY3VzdG9tYXJ5IHdheSBvZiBkb2luZyBwbGFjZWhvbGRlcnMgd291 bGQgYmUgYXMgZm9sbG93czoNCg0KQ29kZSBWYWx1ZSAgICAgICAgIEVycm9yIENvZGUgTmFtZQ0K ICAgICBbVEJEMV0gICAgICAgICAgICAgICBVbmRlcmxheSBEZXN0aW5hdGlvbiBVbnJlYWNoYWJs ZQ0KICAgICBbVEJEMl0gICAgICAgICAgICAgICBVbmRlcmxheSBUaW1lIGV4Y2VlZGVkDQogICAg IFtUQkQzXSAgICAgICAgICAgICAgIE1lc3NhZ2UgRXhwaXJlZA0KICAgICBbVEJENF0gICAgICAg ICAgICAgICBVcHN0cmVhbSBNaXNyb3V0aW5nDQogICAgIFtUQkQ1XSAgICAgICAgICAgICAgIExv b3AgZGV0ZWN0ZWQNCiAgICAgW1RCRDZdICAgICAgICAgICAgICAgVFRMIGhvcHMgZXhjZWVkZWQN Cg0KVGhlc2UgcGxhY2Vob2xkZXJzIHdvdWxkIHRoZW4gZ2V0IHVzZWQgdGhyb3VnaG91dCB0aGUg ZG9jdW1lbnQuDQoNCltoYWliaW5dIHRoZXkgYXJlIHBsYWNlIGhvbGRlcnMuDQoNCk9rLCBwbGVh c2UgY2xhcmlmeSBpdCBpbiB0aGUgZG9jdW1lbnQgaW4gdGhhdCBjYXNlLg0KDQoNCg0KDQpUaGlz IHNlY3Rpb24gYWxzbyBzYXlzOg0KDQoiSW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgaW50cm9k dWNlcyBzZXZlcmFsIHR5cGVzIG9mIGVycm9yIGluZm9ybWF0aW9uIGluIHRoZSBlcnJvcl9pbmZv IGZpZWxkIGluIHRoZSBjYXNlIG9mIENvZGUgMHg2NS4gLi4uIEhlcmUgYXJlIHNvbWUgZXhhbXBs ZXMgZm9yIHRoZSBlcnJvciBpbmZvLiAuLi4gVGhlIGVycm9yX2luZm8gZmllbGQgdmFsdWVzIG9m IHRoZSBDb2RlIDB4NjYgdG8gMHg3MCBhcmUgdG8gYmUgYXBwbGljYXRpb24gc3BlY2lmaWMgYW5k IGRlZmluZWQgYnkgdGhlIHBhcnRpY3VsYXIgb3ZlcmxheS4iDQoNCg0KSSdtIG5vdCBzdXJlIHdo YXQgaXMgbWVhbnQgYnkgYWxsIG9mIHRoaXMgdGV4dC4gQXMgZGVmaW5lZCBpbiBSRkMgNjk0MCwg ZXJyb3JfaW5mbyBpcyBhbiBvcHRpb25hbCBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBieXRlIHN0 cmluZy4gSWYgeW91IGFyZSBpbnRlbmRpbmcgdG8gcmVxdWlyZSBpbXBsZW1lbnRhdGlvbnMgdG8g aW5jbHVkZSBzcGVjaWZpYyB0ZXh0IGluIHRoZSBlcnJvcl9pbmZvIGZvciB0aGUgZmlyc3QgZXJy b3IgY29kZSwgdGhlbiB5b3UgbmVlZCB0byBleHBsYWluIHVuZGVyIHdoYXQgY29uZGl0aW9ucyB0 aGUgc3BlY2lmaWMgdGV4dCBuZWVkcyB0byBiZSBpbmNsdWRlZCBmb3IgZWFjaCBzdHJpbmcuIEFu ZCB0aGUgdGV4dCBhYm91dCB0aGUgb3RoZXIgY29kZXMgc2VlbXMgcmVkdW5kYW50IHdpdGggaG93 IGVycm9yX2luZm8gaXMgYWxyZWFkeSBkZWZpbmVkIGluIFJGQyA2OTQwLg0KDQoNCltoYWliaW5d IGlmIGEgcGVlciByZWNlaXZlcyBhIGRpYWdub3N0aWMgcmVxdWVzdCBmb3VuZCB0aGF0IGl0IGNh bm5vdCByZWFjaCBpdHMgbmV4dCBob3AgZHVlIHRvIHVuZGVybGF5IHByb2JsZW0sIGl0IG5lZWRz IHRvIGV4cGxhaW4gd2l0aCBlcnJvcl9pbmZvIHdoYXQgaGFwcGVuZWQuIEkgZG8gbm90IGtub3cg d2hhdCB5b3UgbWVhbiBieSByZWR1bmRhbnQgd2l0aCBSRkMgNjk0MC4gVGhleSBhcmUgZGlmZmVy ZW50IGVycm9ycy4NCg0KTWF5YmUgaXTigJlzIGp1c3QgYSBsYW5ndWFnZSB0aGluZywgYnV0IHRo ZSBmaXJzdCBzZW50ZW5jZSBzYXlpbmcg4oCcdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIOKApuKA nSBtYWtlcyBpdCBzb3VuZCBsaWtlIHRoZSBsaXN0IG9mIHN0cmluZ3MgaXMgbW9yZSB0aGFuIGp1 c3QgYSBsaXN0IG9mIGV4YW1wbGVzLiBJZiB0aGVzZSBhcmUganVzdCBleGFtcGxlcyB0aGF0IGlt cGxlbWVudGF0aW9ucyBjYW4gY2hvb3NlIHRvIHVzZSBvciBub3QsIEkgd291bGQgc3VnZ2VzdCB0 aGUgZm9sbG93aW5nIHJlLXBocmFzaW5nOg0KDQpPTEQNCg0KSW4gYWRkaXRpb24sIHRoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyBzZXZlcmFsIHR5cGVzIG9mIGVycm9yDQoNCiAgIGluZm9ybWF0aW9u IGluIHRoZSBlcnJvcl9pbmZvIGZpZWxkIGluIHRoZSBjYXNlIG9mIENvZGUgMHg2NS4gIFRoZXNl DQoNCiAgIGFyZSByZXByZXNlbnRlZCBhcyBhbiBvcGFxdWUgVVRGLTggdGV4dCBzdHJpbmcuICBI ZXJlIGFyZSBzb21lDQoNCiAgIGV4YW1wbGVzIGZvciB0aGUgZXJyb3IgaW5mby4NCg0KDQpORVcN Cg0KSGVyZSBhcmUgc29tZSBleGFtcGxlcyBvZiBlcnJvcnMgdGhhdCBtaWdodCBiZSBleHByZXNz ZWQgdXNpbmcgdGhlIGVycm9yX2luZm8gZmllbGQgaW4gdGhlIGNhc2Ugb2YgQ29kZSBbVEJEMV06 DQoNCg0KDQoNCg0KPSBTZWN0aW9uIDUuMjoNCg0KDQoiZXh0X2xlbmd0aCA6IHRoZSBsZW5ndGgg b2YgdGhlIHJldHVybmVkIERpYWdub3N0aWNJbmZvIGluZm9ybWF0aW9uDQogICAgIGluIGJ5dGVz LiAgSWYgdGhlIHZhbHVlIGlzIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byAxLCB0aGVuIHNvbWUN CiAgICAgZXh0ZW5kZWQgZGlhZ25vc3RpYyBpbmZvcm1hdGlvbiBpcyByZXF1ZXN0ZWQuIg0KDQpU aGlzIGlzIGRlZmluaW5nIHRoZSBkaWFnbm9zdGljIHJlc3BvbnNlIC0gd2h5IHdvdWxkIHRoZSBl eHRlbnNpb24gYmUgcmVxdWVzdGluZyBzb21ldGhpbmc/IEFuZCBpZiBpdCBpcyBwb3NzaWJsZSB0 byB1c2UgYW4gZXh0ZW5zaW9uIGluIHRoYXQgd2F5LCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgZnJv bSB0aGUgaW5pdGlhdG9yIHdoZW4gaXQgcmVjZWl2ZXMgc3VjaCBhbiBleHRlbnNpb24gbmVlZHMg dG8gYmUgZGVzY3JpYmVkLCBvciBhdCBsZWFzdCBpdCBuZWVkcyB0byBiZSBub3RlZCB0aGF0IGEg ZGlhZ25vc3RpYyByZXNwb25zZSBjb3VsZCBwcm92b2tlIGEgcmVxdWVzdCBiYWNrIHRvIHRoZSBp bml0aWF0b3IuDQoNCltoYWliaW5dIGl0IGlzIHBvc3NpYmxlIHRvIHJld29yZCBpdCBhcyAiLi4u LnRoZW4gc29tZSBleHRlbmRlZCBkaWFnbm9zdGljIGluZm9ybWF0aW9uIGlzIHJlc3BvbmRlZC7i gJ0NCg0KSG93IGFib3V0IOKAnGlzIGJlaW5nIHNlbnQgaW4gdGhlIHJlc3BvbnNl4oCdPw0KDQoN Cg0KDQpBbHNvLCBpbiB0aGUgc3RydWN0IHRoZSBkaWFnbm9zdGljIGluZm8gaXMgY2FsbGVkICJk aWFnbm9zdGljX2luZm9fY29udGVudHMiIGJ1dCBpbiB0aGUgdGV4dCBpdCBpcyBjYWxsZWQgImRp YWdub3N0aWNfaW5mb3JtYXRpb24uIiBUaGVzZSBzaG91bGQgYmUgdGhlIHNhbWUgSSB0aGluay4N Cg0KW2hhaWJpbl0gWWVzLiBJdCB3aWxsIGJlIGNvcnJlY3RlZC4NCg0KT2sNCg0KDQoNCg0KPSBT ZWN0aW9uIDUuMzoNCg0KSSdtIGNvbmNlcm5lZCBhYm91dCB0aGUgd2F5IFNUQVRVU19JTkZPIGlz IGRlZmluZWQuIEZpcnN0LCB3aHkgYXJlIHRoZXJlIDE2IGRpZmZlcmVudCBsZXZlbHMgb2YgY29u Z2VzdGlvbiBzdGF0dXM/IFdoYXQgYXJlIHRoZXkgc3VwcG9zZWQgdG8gc2lnbmlmeT8gSWYgdGhl cmUgaXMgbm8gc3RhbmRhcmRpemVkIHdheSBvZiBtZWFzdXJpbmcgY29uZ2VzdGlvbiBkZWZpbmVk LCBob3cgaXMgYSBub2RlIHN1cHBvc2VkIHRvIGludGVycHJldCBTVEFUVVNfSU5GTyByZWNlaXZl ZCBmcm9tIGRpZmZlcmVudCBwZWVycz8gVGhhdCBpcywgY291bGRuJ3Qgb25lIHBlZXIncyBsZXZl bCA3IGFjdHVhbGx5IG1lYW4gaXQgaXMgbGVzcyBjb25nZXN0ZWQgdGhhbiBhbm90aGVyIHBlZXIn cyBsZXZlbCAzLCBhbmQgd29uJ3QgdGhhdCBtYWtlIHRoZSBpbmZvcm1hdGlvbiBzb21ld2hhdCBt ZWFuaW5nbGVzcyB0byB0aGUgaW5pdGlhdG9yPyBNYXliZSB0aGlzIHdvdWxkIGJlIGNsZWFyZXIg aWYgeW91IGNvdWxkIGV4cGxhaW4gd2hhdCB5b3UgZXhwZWN0IGFuIGluaXRpYXRvciB0byBkbyB3 aXRoIHRoZSBpbmZvcm1hdGlvbiBhYm91dCAxNiBkaWZmZXJlbnQgbGV2ZWxzIG9mIGNvbmdlc3Rp b24uDQoNCltoYWliaW5dIFlvdXIgY29uY2VybiBtYWtlcyBzZW5zZS4gQWN0dWFsbHkgaXQgaXMg aW50ZW5kZWQgdG8gbGVhdmUgaXQgZm9yIG92ZXJsYXkgaW1wbGVtZW50ZXJzIG9yIGEgZnV0dXJl IHN0YW5kYXJkIHRvIGRlZmluZSB0aGUgY29uZ2VzdGlvbiBsZXZlbCBhbGdvcml0aG1zIC4gVGhp cyBkcmFmdCBqdXN0IGRlZmluZXMgdGhlIGZvcm1hdCBhbmQgcmVzZXJ2ZXMgdGhlIGJpdHMgZm9y IHRoZWlyIHVzZS4gQXMgdGhlIHNlY3Rpb24gc2F5cyAiIFRoaXMgZG9jdW1lbnQgZG9lcyBub3Qg cHJvdmlkZSBhIHNwZWNpZmljIG1ldGhvZCBmb3IgY29uZ2VzdGlvbiwgbGVhdmluZyB0aGlzIGRl Y2lzaW9uIHRvIGVhY2ggbm9kZS4gIE9uZSBwb3NzaWJsZSBvcHRpb24gZm9yIGEgbm9kZSB3b3Vs ZCBiZSB0byB0YWtlIGl0cyBDUFUvbWVtb3J5L2JhbmR3aWR0aCB1c2FnZSBwZXJjZW50YWdlIGlu IHRoZSBwYXN0IDYwMCBzZWNvbmRzIGFuZCBub3JtYWxpemUgdGhlIGhpZ2hlc3QgdmFsdWUgdG8g dGhlIHJhbmdlIFsweDAwLCAweDBGXS4gIEEgZnV0dXJlIGRyYWZ0IG1heSBkZWZpbmUgYW4gb2Jq ZWN0aXZlIG1lYXN1cmUgb3Igc3BlY2lmaWMgYWxnb3JpdGhtIGZvciB0aGlzLiIgSSB0aGluayB3 ZSBzaG91bGQgY2hhbmdlIHRoZSBub2RlIGRlY2lzaW9uIHRvIG92ZXJsYXkgZGVjaXNpb24uIEFu ZCBhbiBvdmVybGF5IGltcGxlbWVudGVyIG1heSBjaG9vc2UgdG8gbm90IHVzZSBhbGwgdGhhdCAx NiB2YWx1ZXMuDQoNCk9rLCBmdXJ0aGVyIGNsYXJpZmljYXRpb24gd291bGQgaGVscC4NCg0KDQoN Cg0KU09GVFdBUkVfVkVSU0lPTiBkb2Vzbid0IHJlYWxseSBzZWVtIGxpa2UgZGlhZ25vc3RpYyBp bmZvcm1hdGlvbi4gV2hpbGUgYWxsIG9mIHRoZSBvdGhlciBmaWVsZHMgbWF5IGJlIGNvbnN0YW50 bHkgY2hhbmdpbmcgYW5kIHRoZXJlZm9yZSBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGlucXVpcmUg YWJvdXQgdGhlbSBpbiBhIGRpYWdub3N0aWMgZmFzaGlvbiwgU09GVFdBUkVfVkVSU0lPTiBzZWVt cyBtb3JlIGxpa2UgZGF0YSB0aGF0IG5vZGVzIGNvdWxkIHJlZ2lzdGVyIG9yIGV4Y2hhbmdlIHdo ZW4gdGhleSBqb2luIHRoZSBvdmVybGF5LiBXaHkgaXMgaXQgaW5jbHVkZWQgYXMgYSBkaWFnbm9z dGljPw0KDQpbaGFpYmluXSBEaWFnbm9zdGljcyB1c3VhbGx5IHRha2UgcGxhY2Ugd2hlbiB0aGVy ZSBhcmUgZmFpbHVyZXMgb3IgYWJub3JtYWwgYmVoYXZpb3JzLiBTb2Z0d2FyZSB2ZXJzaW9uIGlu Y29tcGF0aWJpbGl0eSBtaWdodCBiZSBhIGNhdXNlLg0KDQpPaywgZmFpciBlbm91Z2guIFN0aWxs IHNlZW1zIGxpa2UgYW4gb2RkIGNob2ljZSB0byBtZS4NCg0KDQoNCg0KQWxzbywgZG9lc24ndCB0 aGUgU09GVFdBUkVfVkVSU0lPTiB0eXBlIG5lZWQgYSBsZW5ndGggb3IgYSBzcGVjaWZpZWQgZGVs aW1pdGVyIHRoYXQgaW5kaWNhdGVzIHRoZSBlbmQgb2YgdGhlIHN0cmluZz8gT3RoZXJ3aXNlLCBo b3cgaXMgdGhlIHJlY2lwaWVudCBzdXBwb3NlZCB0byBrbm93IHdoZW4gdG8gc3RvcCBwYXJzaW5n IGl0Pw0KDQpbaGFpYmluXSBXaWxsIGFkZCBpdC4NCg0KT2sNCg0KDQoNCg0KVGhlIGRlZmluaXRp b25zIG9mIEVXTUFfQllURVNfU0VOVCBhbmQgRVdNQV9CWVRFU19SQ1ZEIHNlZW0gcHJvYmxlbWF0 aWMuDQoNCnNlbnQgPSBhbHBoYSB4IHNlbnRfcHJlc2VudCArICgxIC0gYWxwaGEpIHggc2VudA0K cmN2ZCA9IGFscGhhIHggcmN2ZF9wcmVzZW50ICsgKDEgLSBhbHBoYSkgeCByY3ZkDQoNCkFzIHdy aXR0ZW4gdGhlc2UgZXF1YXRpb25zIGFyZSBub3QgcmlnaHQgYmVjYXVzZSBzZW50L3JjdmQgYXBw ZWFyIG9uIGJvdGggc2lkZXMuIEl0IHdvdWxkIGJlIGNsZWFyZXIgdG8gdXNlIGxhc3Rfc2VudCBh bmQgbGFzdF9yY3ZkIG9yIHNvbWUgc3VjaCBvbiB0aGUgcmlnaHQtaGFuZCBzaWRlIG9mIHRoZXNl IGVxdWF0aW9ucy4gQnV0IHRoaXMgYmVncyBzb21lIGJpZ2dlciBxdWVzdGlvbnM6DQoNCi0gRG9l cyB0aGlzIHBsYWNlIGEgcmVxdWlyZW1lbnQgb24gYWxsIG5vZGVzIGltcGxlbWVudGluZyB0aGlz IHNwZWNpZmljYXRpb24gdG8gaGF2ZSB0byBjYWxjdWxhdGUgdGhlc2UgdmFsdWVzIGV2ZXJ5IDUg c2Vjb25kcz8NCi0gSG93IGFyZSB0aGUgdmFsdWVzIGNhbGN1bGF0ZWQgdGhlIGZpcnN0IHRpbWU/ DQotIEhvdyB3YXMgdGhlIHZhbHVlIG9mIDUgc2Vjb25kcyBjaG9zZW4/DQoNCltIYWliaW5dIFRo aXMgaXMgaW5jb3Jwb3JhdGVkIGZyb20gdGhlIGVhcmx5IFJFTE9BRCBkb2N1bWVudC4gTWF5YmUg c29tZSBhdXRob3Igb2YgdGhlIFJFTE9BRCBwcm90b2NvbCBjYW4gZ2l2ZSBhIGJldHRlciBleHBs YW5hdGlvbi4NCg0KRmluYWxseSwgSSBoYXZlIHRyb3VibGUgdW5kZXJzdGFuZGluZyB3aHkgb25s eSBzb21lIG9mIHRoZSB0eXBlcyBhcmUgc3ViamVjdCB0byBhY2Nlc3MgY29udHJvbCBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiA3LiBJdCBzZWVtcyB0byBtZSB0aGF0IGluIHNvbWUgc2l0dWF0aW9u cyBhbGwgb2YgdGhlIGZpZWxkcyBkZWZpbmVkIGhlcmUgY291bGQgYmUgY29uc2lkZXJlZCBzZW5z aXRpdmUgYnkgY2VydGFpbiBub2RlcyBvciBvbiBjZXJ0YWluIG5ldHdvcmtzLiBXaGF0IGlzIHRo ZSBqdXN0aWZpY2F0aW9uIGZvciBvbmx5IG1ha2luZyBzb21lIG9mIHRoZW0gc3ViamVjdCB0byBh Y2Nlc3MgY29udHJvbD8NCg0KW2hhaWJpbl0gQWN0dWFsbHkgaXQgc2F5cyBkaWZmZXJlbnQgbGV2 ZWwgb2YgYWNjZXNzIGNvbnRyb2wgY2FuIGJlIG1hZGUuIEZvciBleGFtcGxlLCBkaWFnbm9zdGlj IGluZm9ybWF0aW9uIEEgY2FuIGJlIGFjY2Vzc2VkIGJ5IG5vZGUgMSBhbmQgMiwgYnV0IGRpYWdu b3N0aWMgaW5mb3JtYXRpb24gQiBjYW4gb25seSBiZSBhY2Nlc3NlZCBieSBub2RlIDIuIFdlIGNh biBhZGQgc29tZSBleHBsYW5hdGlvbnMgYXMgaXQgc2VlbXMgbm90IGNsZWFyIHRvIHJlYWRlcnMu DQoNCk9rLCB3aWxsIGF3YWl0IHRoZSByZXZpc2lvbi4NCg0KDQoNCg0KDQo9IFNlY3Rpb24gNi4x Og0KDQoiVGhlIGRlc3RpbmF0aW9uIGZpZWxkIE1VU1QgYmUgc2V0IHRvIHRoZSBkZXNpcmVkIGRl c3RpbmF0aW9uLCB3aGljaCBNQVkgYmUgZWl0aGVyIGEgTm9kZUlkIG9yIFJlc291cmNlSUQgYnV0 IFNIT1VMRCBOT1QgYmUgdGhlIGJyb2FkY2FzdCBOb2RlSUQuIg0KDQpXaGF0IGlzIHRoZSBleHBl Y3RlZCBiZWhhdmlvciBpZiBhIFBpbmcgb3IgYSBQYXRoVHJhY2sgZG9lcyBnZXQgc2VudCB0byB0 aGUgYnJvYWRjYXN0IE5vZGVJRD8gT3Igc2hvdWxkIHRoZXNlIHJlcXVpcmVtZW50cyByZWFsbHkg YmUgTVVTVCBOT1RzPw0KDQpbaGFpYmluXSBJIGd1ZXNzIHRoZXkgc2hvdWxkIGJlIE1VU1QgTk9U cy4NCg0KT2sNCg0KDQoNCg0KPSBTZWN0aW9uIDYuNDoNCg0KIkhvd2V2ZXIsIGZvciBhIHNpbmds ZSBob3ANCiAgbWVhc3VyZW1lbnQsIHRoZSB0cmFkaXRpb25hbCBtZWFzdXJlbWVudCBtZXRob2Rz IE1VU1QgYmUgdXNlZCBpbnN0ZWFkDQogIG9mIHRoZSBvdmVybGF5IGxheWVyIGRpYWdub3N0aWNz IG1ldGhvZHMuIg0KDQpXaGF0IGlzIG1lYW50IGJ5IHRoZSB0cmFkaXRpb25hbCBtZWFzdXJlbWVu dCBtZXRob2RzPw0KDQpbaGFpYmluXSBJdCBtYWlubHkgbWVhbnMgSVAgbGF5ZXIgcGluZy4NCg0K V291bGQgYmUgZ29vZCB0byBzcGVjaWZ5Lg0KDQpUaGFua3MsDQpBbGlzc2ENCg0KDQoNCg0KPSBT ZWN0aW9uIDk6DQoNClBsZWFzZSBvbmx5IHVzZSBlaXRoZXIgUkZDLVhYWFggb3IgUkZDLUFBQUEg YnV0IG5vdCBib3RoIGFzIHBsYWNlaG9sZGVycy4NCg0KW2hhaWJpbl0gUkZDLUFBQUEgaXMgUkZD IDY5NDAuIFJGQy1YWFhYIGlzIHRoZSBwbGFjZWhvbGRlci4gVGhleSB3aWxsIGJlIGNvcnJlY3Rl ZC4NCg0KUGxlYXNlIGFsc28gdXNlIFtUQkRYXSBmb3IgdmFsdWVzIHlvdSBleHBlY3QgdG8gYmUg YWxsb2NhdGVkIGJ5IElBTkEuDQoNCltoYWliaW5dIG9rLg0KDQo9PSBOaXRzID09DQoNCg0KPSBH ZW5lcmFsDQoNCg0KVGhlIGRvY3VtZW50IHNlZW1zIHRvIHJlcGVhdGVkbHkgZXhwbGFpbiB0aGF0 IGl0IGlzIGRvaW5nIHRoaW5ncyAiYXMgc3BlY2lmaWVkIGluIFJGQzY5NDAuIiBJIGRvbid0IHRo aW5rIHRoaXMgbmVjZXNzYXJ5IGluIG1hbnkgY2FzZXMuIEl0J3Mgd29ydGggZG9pbmcgYSBwYXNz IHRocm91Z2ggYW5kIHJlbW92aW5nIHRoZSBwbGFjZXMgd2hlcmUgaXQncyBvYnZpb3VzIHRoYXQg dGhpcyBzcGVjIGlzIGJ1aWxkaW5nIG9uIFJGQyA2OTQwLg0KDQpbaGFpYmluXSBvay4NCg0KPSBT ZWN0aW9uIDQuMToNCg0KDQpPTEQNClRoZSBleHRlbnNpb25zIHN0cmljdGx5IGZvbGxvdyBSRUxP QUQNCiAgc3BlY2lmaWNhdGlvbiBvbiB0aGUgbWVzc2FnZXMgcm91dGluZywgdHJhbnNwb3J0LCBO QVQgdHJhdmVyc2FsIGV0Yy4NCg0KTkVXDQpUaGUgZXh0ZW5zaW9ucyBzdHJpY3RseSBmb2xsb3cg aG93IFJFTE9BRCBzcGVjaWZpZXMgbWVzc2FnZSByb3V0aW5nLCB0cmFuc3BvcnQsIE5BVCB0cmF2 ZXJzYWwsIGFuZCBvdGhlciBSRUxPQUQgcHJvdG9jb2wgZmVhdHVyZXMuDQoNCj0gU2VjdGlvbiA0 LjIuMToNCg0KDQpzL2FzIHNwZWNpZmllZCBpbiBUYWJsZSA0IGFuZCBzcGVjaWZpZWQgaW4gdGhl IFJFTE9BRC9hcyBzcGVjaWZpZWQgaW4gVGFibGUgNC8NCg0Kcy9uZXcgcmVxdWVzdHMgb2YgdGhl IHRoZS9uZXcgcmVxdWVzdHMgb2YgdGhlLw0KDQo9IFNlY3Rpb24gNC4zOg0KDQpPTEQNCldlIGRl ZmluZSBhIHNpbXBsZSBQYXRoVHJhY2sgbWV0aG9kIGZvciByZXRyaWV2aW5nIGRpYWdub3N0aWMN CiAgaW5mb3JtYXRpb24gaXRlcmF0aXZlbHkuICBUaGUgbWVjaGFuaXNtIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudA0KICBmb2xsb3dzIHRoZSBSRUxPQUQgc3BlY2lmaWNhdGlvbiwgdGhlIG5ldyBy ZXF1ZXN0IGFuZCByZXNwb25zZQ0KICBtZXNzYWdlIHVzZSB0aGUgbWVzc2FnZSBmb3JtYXQgc3Bl Y2lmaWVkIGluIFJFTE9BRCBtZXNzYWdlcy4gIFBsZWFzZQ0KICByZWZlciB0byB0aGUgUkVMT0FE IFtSRkM2OTQwXSBmb3IgZGV0YWlscyBvZiB0aGUgcHJvdG9jb2wuDQoNCiAgVGhlIG9wZXJhdGlv biBvZiB0aGlzIHJlcXVlc3QgaXMgc2hvd24gYmVsb3cgaW4gRmlndXJlIDIuDQoNCg0KTkVXDQpX ZSBkZWZpbmUgYSBzaW1wbGUgUGF0aFRyYWNrIG1ldGhvZCBmb3IgcmV0cmlldmluZyBkaWFnbm9z dGljDQogIGluZm9ybWF0aW9uIGl0ZXJhdGl2ZWx5LiAgVGhlIG9wZXJhdGlvbiBvZiB0aGlzIHJl cXVlc3QgaXMgc2hvd24gYmVsb3cgaW4gRmlndXJlIDIuDQoNCj0gU2VjdGlvbiA0LjMuMS4yOg0K DQpzL2FmdGVyIHRoYXQvYWZ0ZXIgcmVjZWl2aW5nIGEgUGF0aFRyYWNrQW5zIHdoZXJlIHRoZSBu ZXh0X2hvcCBub2RlIElEIGVxdWFscyB0aGUgcmVzcG9uZGluZyBub2RlIElELw0KDQo9IFNlY3Rp b24gNC4zLjIuMToNCg0Kcy9QYXRoVHJhY2sgUmVzcG9uc2UvUGF0aFRyYWNrIHJlc3BvbnNlLw0K DQo9IFNlY3Rpb24gNC40Og0KDQpzL2NvZGUuIGFuZCB3ZSBkZWZpbmUvY29kZS4gV2UgZGVmaW5l Lw0KDQo9IFNlY3Rpb24gNToNCg0Kcy9QYXRoX3RyYWNrIG1ldGhvZHMvUGF0aFRyYWNrIG1ldGhv ZHMvDQoNCj0gU2VjdGlvbiA1LjE6DQoNCnMvTm90ZSB0aGF0IGlzIE5PVC9Ob3RlIHRoYXQgaXQg aXMgbm90Lw0KDQo9IFNlY3Rpb24gNS4yOg0KDQpzL05vdGUgdGhhdCBpcyBOT1QvTm90ZSB0aGF0 IGl0IGlzIG5vdC8NCg0Kcy9jb25zaXN0cyBvbmUgb3IgbW9yZS9jb25zaXN0cyBvZiBvbmUgb3Ig bW9yZS8NCg0KPSBTZWN0aW9uIDYuMToNCg0Kcy9gTUFZL01BWS8NCg0KPSBTZWN0aW9uIDYuMjoN Cg0Kcy9yZXR1cm4gdGhlIHJlc3BvbnNlIHRoZSBpbml0aWF0b3Igbm9kZS9yZXR1cm4gdGhlIHJl c3BvbnNlIHRvIHRoZSBpbml0aWF0b3Igbm9kZS8NCg0Kcy9UaGUgcGVlciBTSE9VTEQvVGhlIGlu dGVybWVkaWF0ZSBwZWVyIFNIT1VMRC8NCg0KW2hhaWJpbl0gVGhhbmtzIGFnYWluLg0KDQpCUiwN Ci1IYWliaW4gU29uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmc8bWFpbHRvOlAy UFNJUEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJw c2lwDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KUDJQU0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGlldGYub3JnPG1haWx0bzpQMlBTSVBAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQo= --_000_E33E01DFD5BEA24B9F3F18671078951F653C3123nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzl vI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9u dC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbGlzc2EsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIGFjY2VwdCB0aGUgc2Vjb25kIHN1Z2dlc3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBmb3IgdGhlIGZpcnN0 IGNvbW1lbnQsIEnigJltIG5vdCBzdXJlLiBJTU8sIGl0IGRvZXMgbm90IGRpc3Rpbmd1aXNoIHRo ZSBieXRlcyBzZW50L3JjdmQgdG8vZnJvbSB1cHN0cmVhbSBvciBkb3duc3RyZWFtIHBlZXIsIGJ1 dCBvbmx5IGNhbGN1bGF0ZQ0KIHRoYXQgaW4gdG90YWwuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPi1IYWliaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNvb3BlcncuaW5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDEyLCAyMDE1IDc6MTAgQU08YnI+DQo8Yj5Ubzo8 L2I+IFNvbmdoYWliaW4gKEEpPGJyPg0KPGI+Q2M6PC9iPiBwMnBzaXA7IGRyYWZ0LWlldGYtcDJw c2lwLWRpYWdub3N0aWNzQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb UDJQU0lQXSBBRCBldmFsdWF0aW9uOiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xNzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgSGFpYmluLiBU aGlzIGxvb2tzIGdvb2QgYnV0IHRoZXJlIGFyZSBzdGlsbCBhIGZldyB1bnJlc29sdmVkIGlzc3Vl cyBmcm9tIG91ciBlYXJsaWVyIG1haWwgZXhjaGFuZ2U6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZGVmaW5pdGlvbnMgb2YmbmJz cDtFV01BX0JZVEVTX1NFTlQgYW5kJm5ic3A7RVdNQV9CWVRFU19SQ1ZEIHNlZW0gcHJvYmxlbWF0 aWMuPGJyPg0KPGJyPg0Kc2VudCA9IGFscGhhIHggc2VudF9wcmVzZW50ICYjNDM7ICgxIC0gYWxw aGEpIHggc2VudDxicj4NCnJjdmQgPSBhbHBoYSB4IHJjdmRfcHJlc2VudCAmIzQzOyAoMSAtIGFs cGhhKSB4IHJjdmQ8YnI+DQo8YnI+DQpBcyB3cml0dGVuIHRoZXNlIGVxdWF0aW9ucyBhcmUgbm90 IHJpZ2h0IGJlY2F1c2Ugc2VudC9yY3ZkIGFwcGVhciBvbiBib3RoIHNpZGVzLiBJdCB3b3VsZCBi ZSBjbGVhcmVyIHRvIHVzZSBsYXN0X3NlbnQgYW5kIGxhc3RfcmN2ZCBvciBzb21lIHN1Y2ggb24g dGhlIHJpZ2h0LWhhbmQgc2lkZSBvZiB0aGVzZSBlcXVhdGlvbnMuIEJ1dCB0aGlzIGJlZ3Mgc29t ZSBiaWdnZXIgcXVlc3Rpb25zOjxicj4NCjxicj4NCi0gRG9lcyB0aGlzIHBsYWNlIGEgcmVxdWly ZW1lbnQgb24gYWxsIG5vZGVzIGltcGxlbWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24gdG8gaGF2 ZSB0byBjYWxjdWxhdGUgdGhlc2UgdmFsdWVzIGV2ZXJ5IDUgc2Vjb25kcz88YnI+DQotIEhvdyBh cmUgdGhlIHZhbHVlcyBjYWxjdWxhdGVkIHRoZSBmaXJzdCB0aW1lPzxicj4NCi0gSG93IHdhcyB0 aGUgdmFsdWUgb2YgNSBzZWNvbmRzIGNob3Nlbj88YnI+DQo8YnI+DQpbSGFpYmluXSBUaGlzIGlz IGluY29ycG9yYXRlZCBmcm9tIHRoZSBlYXJseSBSRUxPQUQgZG9jdW1lbnQuIE1heWJlIHNvbWUg YXV0aG9yIG9mIHRoZSBSRUxPQUQgcHJvdG9jb2wgY2FuIGdpdmUgYSBiZXR0ZXIgZXhwbGFuYXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGlzIHN0aWxsIGhhcyBub3QgYmVlbiBleHBsYWluZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpGaW5hbGx5LCBJIGhhdmUgdHJvdWJs ZSB1bmRlcnN0YW5kaW5nIHdoeSBvbmx5IHNvbWUgb2YgdGhlIHR5cGVzIGFyZSBzdWJqZWN0IHRv IGFjY2VzcyBjb250cm9sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuIEl0IHNlZW1zIHRvIG1l IHRoYXQgaW4gc29tZSBzaXR1YXRpb25zIGFsbCBvZiB0aGUgZmllbGRzIGRlZmluZWQgaGVyZSBj b3VsZCBiZSBjb25zaWRlcmVkIHNlbnNpdGl2ZSBieSBjZXJ0YWluIG5vZGVzIG9yIG9uIGNlcnRh aW4gbmV0d29ya3MuDQogV2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiBmb3Igb25seSBtYWtpbmcg c29tZSBvZiB0aGVtIHN1YmplY3QgdG8gYWNjZXNzIGNvbnRyb2w/PGJyPg0KPGJyPg0KW2hhaWJp bl0gQWN0dWFsbHkgaXQgc2F5cyBkaWZmZXJlbnQgbGV2ZWwgb2YgYWNjZXNzIGNvbnRyb2wgY2Fu IGJlIG1hZGUuIEZvciBleGFtcGxlLCBkaWFnbm9zdGljIGluZm9ybWF0aW9uIEEgY2FuIGJlIGFj Y2Vzc2VkIGJ5IG5vZGUgMSBhbmQgMiwgYnV0IGRpYWdub3N0aWMgaW5mb3JtYXRpb24gQiBjYW4g b25seSBiZSBhY2Nlc3NlZCBieSBub2RlIDIuIFdlIGNhbiBhZGQgc29tZSBleHBsYW5hdGlvbnMg YXMgaXQgc2VlbXMgbm90IGNsZWFyIHRvDQogcmVhZGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWx0aG91Z2ggSSBzZWUgdGhlIG5ldyB0ZXh0LCB0aGUgcHJv YmxlbSBzdGlsbCByZW1haW5zIHRoYXQgaW4gU2VjdGlvbiA1LjMgb25seSBzb21lIG9mIHRoZSBm aWVsZHMgaGF2ZSB0aGlzIGRpc2NsYWltZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5czt3aWRvd3M6IDEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+QWNjZXNzIHRvIHRoaXMga2luZCBvZiBkaWFnbm9zdGljIGluZm9ybWF0 aW9uIE1VU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTk9UIGJlIGFsbG93ZWQgdW5sZXNzIGNv bXBsaWFudCB0byB0aGUgcnVsZXMgZGVmaW5lZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTgjc2VjdGlvbi03Ij5T ZWN0aW9uIDc8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JIHRoaW5rIHRoZSBkaXNjbGFpbWVyIHNob3VsZCBhcHBseSB0byBhbGwgb2YgdGhl IGZpZWxkcywgbm90IG9ubHkgYSBzZWxlY3Rpb24gb2YgdGhlbS4gQXMgc3VjaCwgSSB3b3VsZCBy ZWNvbW1lbmQganVzdCBwdXR0aW5nIHRoZSBkaXNjbGFpbWVyIG9uY2UgYXQgdGhlIHRvcCBvZiBz ZWN0aW9uIDUuMyBhbmQgZXhwbGFpbmluZyB0aGF0IGl0IGFwcGxpZXMgdG8gYWxsIG9mIHRoZQ0K IGZpZWxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxpc3NhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBOb3YgOCwgMjAxNSwgYXQgNTo0MSBQTSwgU29uZ2hh aWJpbiAoQSkgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWliaW4uc29uZ0BodWF3ZWkuY29tIj5oYWli aW4uc29uZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhp IEFsaXNzYSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSByZXZpc2lvbiBvZiB0aGlzIGRyYWZ0 IGlzIG5vdyBhdmFpbGFibGUuIFBsZWFzZSBjaGVjayBpZiBpdCBzb2x2ZXMgeW91ciBjb21tZW50 cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQt anVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzITwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pi1IYWliaW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkFsaXNzYQ0KIENvb3BlciBbPGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86YWxpc3NhQGNvb3BlcncuaW48L3NwYW4+ PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlNhdHVyZGF5LCBPY3RvYmVyIDAzLCAyMDE1IDg6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNvbmdoYWli aW4gKEEpPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5wMnBzaXA7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGlj c0B0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZHJhZnQtaWV0Zi1w MnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5S ZTogW1AyUFNJUF0gQUQgZXZhbHVhdGlvbjogZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3Mt MTc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5XYW50ZWQgdG8gY2hlY2sgaWYgYSByZXYgb2YgdGhpcyBkb2N1bWVudCBp cyBmb3J0aGNvbWluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QWxpc3Nh PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PbiBTZXAgNCwgMjAxNSwgYXQgMzo1 MSBQTSwgQWxpc3NhIENvb3BlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3Lmlu Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGlzc2FAY29vcGVydy5pbjwvc3Bhbj48L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmtz IGZvciB0aGUgcmVwbHkuIENvbW1lbnRzIGFyZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5PbiBBdWcgMjAsIDIwMTUsIGF0IDg6MjIgUE0sIFNvbmdoYWliaW4gKEEp ICZsdDs8YSBocmVmPSJtYWlsdG86aGFpYmluLnNvbmdAaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aGFpYmluLnNvbmdAaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhpIEFsaXNzYSw8YnI+DQo8YnI+DQpUaGFuayB5 b3UgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIGZpbmQgbXkgZXhwbGFuYXRpb25zIGluIGxpbmUg d2l0aCBbaGFpYmluXS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+VGhhbmtzLiBJIGRpZCBoYXZlIG9uZSBmdXJ0aGVyIHRob3VnaHQgZm9yIFNl Y3Rpb24gOC4gSXQgc3RyaWtlcyBtZSB0aGF0IHRoZSBjb21iaW5hdGlvbiBvZiBkaWFnbm9zdGlj IGVsZW1lbnRzIHRoYXQgdGhpcyBzcGVjIG1ha2VzIGF2YWlsYWJsZSBjb3VsZCBlYXNpbHkgYmUg dXNlZCB0byBmaW5nZXJwcmludA0KIGEgcGVlciBpbiBhbiBvdmVybGF5IHdoZXJlIHBlZXJzIG1h eSBvdGhlcndpc2UgYmUgYXR0ZW1wdGluZyB0byByZW1haW4gYW5vbnltb3VzLiBBbHRob3VnaCBk ZWZlbnNlcyBhZ2FpbnN0IHN1Y2ggZmluZ2VycHJpbnRpbmcgYXJlIHByb2JhYmx5IGhhcmQgdG8g Y29tZSBieSAoc2hvcnQgb2YgZGlzYWxsb3dpbmcgYWNjZXNzIHRvIHRoZSBkaWFnbm9zdGljcyB2 aWEgdGhlIGNvbmZpZyBmaWxlKSwgdGhlIHRocmVhdCBpcyB3b3J0aCBub3RpbmcgYXQNCiBsZWFz dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxi cj4NCltoYWliaW5dQWN0dWFsbHkgd2UgaW1wbHkgeW91ciBjb25jZXJuIHdpdGggdGhlIHNlbnRl bmNlICZxdW90O0l0IHNob3VsZCBhbHNvIGJlIG5vdGVkIHRoYXQgYXR0YWNrZXJzIGNhbiB1c2Ug ZGlhZ25vc3RpY3MgdG8gYW5hbHl6ZSBvdmVybGF5IGluZm9ybWF0aW9uIHRvIGF0dGFjayBjZXJ0 YWluIGtleSBwZWVycy4mcXVvdDsgQnV0IHdlIGNvdWxkIGVsYWJvcmF0ZSBtb3JlIGluIHRoaXMg c2VjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Z ZXMsIGZ1cnRoZXIgZWxhYm9yYXRpb24gd291bGQgYmUgYXBwcmVjaWF0ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpGcm9tOiBBbGlzc2EgQ29vcGVyIFs8YSBo cmVmPSJtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1haWx0bzphbGlzc2FAY29vcGVydy5pbjwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCAxOSwgMjAxNSAxMjowNCBBTTxicj4NClRvOiBEYXZpZCBCcnlhbjxicj4NCkNjOiBwMnBzaXA7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0b29scy5pZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3NAdG9v bHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBBRCBldmFs dWF0aW9uOiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xNzxicj4NCjxicj4NCk9uIEF1 ZyAxNywgMjAxNSwgYXQgODo1NCBBTSwgRGF2aWQgQnJ5YW4gJmx0OzxhIGhyZWY9Im1haWx0bzpk YnJ5YW5AZXRoZXJub3Qub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kYnJ5YW5AZXRo ZXJub3Qub3JnPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxicj4NClRoYW5rcyBm b3IgdGhlIGNvbW1lbnRzLiBJJ2xsIGNpcmNsZSBiYWNrIHdpdGggdGhlIHRlYW0gYW5kIHdpbGwg cmV2aXNlLjxicj4NCjxicj4NClRoYW5rcy4gSSBkaWQgaGF2ZSBvbmUgZnVydGhlciB0aG91Z2h0 IGZvciBTZWN0aW9uIDguIEl0IHN0cmlrZXMgbWUgdGhhdCB0aGUgY29tYmluYXRpb24gb2YgZGlh Z25vc3RpYyBlbGVtZW50cyB0aGF0IHRoaXMgc3BlYyBtYWtlcyBhdmFpbGFibGUgY291bGQgZWFz aWx5IGJlIHVzZWQgdG8gZmluZ2VycHJpbnQgYSBwZWVyIGluIGFuIG92ZXJsYXkgd2hlcmUgcGVl cnMgbWF5IG90aGVyd2lzZSBiZSBhdHRlbXB0aW5nIHRvIHJlbWFpbiBhbm9ueW1vdXMuDQogQWx0 aG91Z2ggZGVmZW5zZXMgYWdhaW5zdCBzdWNoIGZpbmdlcnByaW50aW5nIGFyZSBwcm9iYWJseSBo YXJkIHRvIGNvbWUgYnkgKHNob3J0IG9mIGRpc2FsbG93aW5nIGFjY2VzcyB0byB0aGUgZGlhZ25v c3RpY3MgdmlhIHRoZSBjb25maWcgZmlsZSksIHRoZSB0aHJlYXQgaXMgd29ydGggbm90aW5nIGF0 IGxlYXN0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCkkgaGF2ZSB0byBjaGVjaywgYnV0IEkgYWN0 dWFsbHkgdGhpbmsgdGhlIGZpcnN0IGZldyB2ZXJzaW9ucyBvZiB0aGlzICh3aGVuIGl0IHdhcyBp bmRpdmlkdWFsKSAqbWF5KiBiZSBwcmUtNTM3OCwgYnV0IHdpbGwgZG91YmxlIGNoZWNrLjxicj4N Cjxicj4NCkFoIG9rLjxicj4NCjxicj4NCltoYWliaW5dIEl0IGlzIHRydWUgdGhhdCB0aGUgZmly c3QgdmVyc2lvbiBvZiB0aGUgaW5kaXZpZHVhbCBkcmFmdCBpcyBwcmUtNTM3OC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9rLCBteSBtaXN0YWtlIHRoZW4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpBbGlzc2E8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpPbiBGcmksIEF1ZyAxNCwgMjAxNSBhdCA2OjMzIFBNLCBBbGlzc2EgQ29vcGVy ICZsdDs8YSBocmVmPSJtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4iPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmFsaXNzYUBjb29wZXJ3LmluPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxicj4NCkkg aGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGluIHByZXBhcmF0aW9uIGZvciBJRVRGIGxhc3Qg Y2FsbC4gQmVmb3JlIHByb2NlZWRpbmcgdG8gbGFzdCBjYWxsLCBJIGhhdmUgc29tZSBjb21tZW50 cyBhbmQgcXVlc3Rpb25zIHRoYXQgSSdkIGxpa2UgdG8gZGlzY3Vzcy4gSSd2ZSBhbHNvIGluY2x1 ZGVkIGEgbGlzdCBvZiBuaXRzIHRoYXQgc2hvdWxkIGJlIHJlc29sdmVkIHRvZ2V0aGVyIHdpdGgg YW55IGxhc3QgY2FsbCBjb21tZW50cy48YnI+DQo8YnI+DQo8YnI+DQo9PSBTdWJzdGFudGl2ZSBj b21tZW50cyBhbmQgcXVlc3Rpb25zID09PGJyPg0KPGJyPg0KPSBHZW5lcmFsJm5ic3A7PGJyPg0K PGJyPg0KSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBsaXN0ZWQgYXMgdXBkYXRpbmcg UkZDIDY5NDAgaW4gdGhlIGRvY3VtZW50IGhlYWRlci48YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQg Y29udGFpbnMmbmJzcDthIGRpc2NsYWltZXIgZm9yIHByZS1SRkM1Mzc4IHdvcmssIHdoaWNoIEkg YXNzdW1lIGlzIGluIGVycm9yLiBJZiB1c2luZyB4bWwycmZjIHRvIGdlbmVyYXRlIHRoZSB0ZXh0 LCB1c2luZyB0aGUgbW9zdCB1cC10by1kYXRlIHZlcnNpb24gb2YgeG1sMnJmYyB0byBjcmVhdGUg dGhlIG5leHQgdmVyc2lvbiBzaG91bGQgZml4IHRoaXMuPGJyPg0KPGJyPg0KPSBTZWN0aW9uIDQu Mzo8YnI+DQo8YnI+DQomcXVvdDtUaGVyZSBoYXZlIGJlZW4gcHJvcG9zYWxzIHRoYXQgUm91dGVR dWVyeSBhbmQgYSBzZXJpZXMgb2YgRmV0Y2g8YnI+DQombmJzcDsmbmJzcDtyZXF1ZXN0cyBjYW4g YmUgdXNlZCB0byByZXBsYWNlIHRoZSBQYXRoVHJhY2sgbWVjaGFuaXNtLCBidXQgaW4gdGhlPGJy Pg0KJm5ic3A7Jm5ic3A7cHJlc2VuY2Ugb2YgY2h1cm4gc3VjaCBhbiBvcGVyYXRpb24gd291bGQg bm90LCBzdHJpY3RseSBzcGVha2luZyw8YnI+DQombmJzcDsmbmJzcDtwcm92aWRlIGlkZW50aWNh bCByZXN1bHRzLCBhcyB0aGUgcGF0aCBtYXkgY2hhbmdlIGJldHdlZW4gUm91dGVRdWVyeTxicj4N CiZuYnNwOyZuYnNwO2FuZCBGZXRjaCBvcGVyYXRpb25zLiAoYWx0aG91Z2ggb2J2aW91c2x5IHRo ZSBwYXRoIGNvdWxkIGNoYW5nZTxicj4NCiZuYnNwOyZuYnNwO2JldHdlZW4gc3RlcHMgb2YgUGF0 aFRyYWNrIGFzIHdlbGwpLiZxdW90Ozxicj4NCjxicj4NClRoaXMgdGV4dCBpcyBjb25mdXNpbmcu IEl0IGRvZXNuJ3QgZXhwbGFpbiB3aHkgUGF0aFRyYWNrIGlzIGJlaW5nIGRlZmluZWQgcmF0aGVy IHRoYW4gcGVlcnMgdXNpbmcgUm91dGVRdWVyeSBwbHVzIEZldGNoLiBGdXJ0aGVybW9yZSwgdGhl IGRvY3VtZW50IGRvZXMgbm90IGV4cGxhaW4gaG93IHBlZXJzIGFyZSBzdXBwb3NlZCB0byBpbnRl cnByZXQgdGhlIHJlc3VsdHMgb2YgdGhlIFBhdGhUcmFjayBtZXRob2QgaW4gdGhlIGV2ZW50IHRo YXQgdGhlDQogcm91dGUgZG9lcyBjaGFuZ2UgaW4gYmV0d2VlbiBzdGVwcy4gVGhpcyBzZWVtcyBs aWtlIGEgc3Vic3RhbnRpYWwgb21pc3Npb24uPGJyPg0KPGJyPg0KW2hhaWJpbl0gVGhpcyBpcyBh IGdvb2QgcXVlc3Rpb24uIEFzIHRoZSByb3V0ZSBjaGFuZ2UgaXMgYSBwcm9ibGVtICh3aXRoIGxp dHRsZSBwcm9iYWJpbGl0eSksIHdlIHdvdWxkIGxpa2UgdG8gcmV0cmlldmUgZGlhZ25vc3RpY3Mg aW5mbyBpbiBhbiBlZmZpY2llbnQgd2F5LCBzbyBvbmUgc2ltcGxlIG1lc3NhZ2UgaXMgcHJlZmVy cmVkLiBBbmQgeW91IGFyZSByaWdodCwgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSB0cnV0aCB0aGF0 IHJvdXRlIGNhbg0KIGNoYW5nZSAmbmJzcDtpbiBiZXR3ZWVuIHN0ZXBzLiBXZSBuZWVkIHJlLXdv cmRpbmcgdGhlIHNlY3Rpb24uIFRoZSBpbXBsaWNhdGlvbiBvZiByb3V0ZSBjaGFuZ2UgaXMgdGhh dCwgdGhlIHJlc3VsdCBvZiB0aGUgZGlhZ25vc3RpY3MgY2Fubm90IGJlIHRydXN0ZWQgd2l0aCBv bmUgaHVuZHJlZCBwZXJjZW50LCB3aGljaCBzaG91bGQgYmUgbm90ZWQgdG8gdGhlIHVzZXJzIHRo YXQgcGVyZm9ybSB0aGUgZGlhZ25vc3RpY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5PaywgbmV3IHRleHQgd291bGQgYmUgYXBwcmVjaWF0ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpJbiBnZW5lcmFsLCB0aGlzIGRvY3VtZW50 IHByb3ZpZGVzIHZlcnkgbGl0dGxlIGluZm9ybWF0aW9uIGFib3V0IGhvdyBwZWVycyBhcmUgZXhw ZWN0ZWQgdG8gaW50ZXJwcmV0IGFuZCB1c2UgdGhlIGRpYWdub3N0aWMgaW5mb3JtYXRpb24uIEkg dW5kZXJzdGFuZCB0aGF0IHBlZXJzIGNhbiBkbyB3aGF0ZXZlciB0aGV5IHdhbnQgd2l0aCBpdCwg YnV0IGluIHNldmVyYWwgcGxhY2VzIHRoZSBmYWN0IHRoYXQgdGhpcyBpcyBub3QgZXhwbGFpbmVk IG1ha2VzDQogdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhlIHByb3RvY29sIGRlc2lnbiBkZWNpc2lv bnMgb3BhcXVlLiBJIHdvdWxkIHN1Z2dlc3QgcHJvdmlkaW5nIGEgbGl0dGxlIG1vcmUgY29udGV4 dCwgYXQgdGhlIHZlcnkgbGVhc3QgYnkgbW92aW5nIHRoZSBleGFtcGxlcyBpbnRvIHRoZSBib2R5 IG9mIHRoZSBkcmFmdCBzb21ld2hlcmUuJm5ic3A7PGJyPg0KPGJyPg0KW2hhaWJpbl0gV2UgY2Fu IGFkZCBzb21lIG1vcmUgZXhwbGFuYXRpb25zIHdpdGggZGlhZ25vc3RpY3MgaW5mbyBpbnRlcnBy ZXRhdGlvbi48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PaywgZ29vZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCj0gU2VjdGlvbiA0LjQ6PGJyPg0K PGJyPg0KSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHRoZSB2YWx1ZXMgZ2l2ZW4gZm9yIHRo ZSBlcnJvciBjb2Rlcy4gRG8geW91IHdhbnQgSUFOQSB0byBjaG9zZSB0aGVzZSBzcGVjaWZpYyB2 YWx1ZXM/IE9yIGFyZSB0aGV5IGp1c3QgdGhlcmUgYXMgcGxhY2Vob2xkZXJzPyBUaGUgY3VzdG9t YXJ5IHdheSBvZiBkb2luZyBwbGFjZWhvbGRlcnMgd291bGQgYmUgYXMgZm9sbG93czo8YnI+DQo8 YnI+DQpDb2RlIFZhbHVlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO0Vycm9yIENvZGUgTmFtZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1tUQkQxXSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtVbmRlcmxheSBEZXN0aW5hdGlvbiBV bnJlYWNoYWJsZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tUQkQyXSAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtVbmRlcmxheSBUaW1lIGV4Y2VlZGVkPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1RCRDNdICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O01lc3NhZ2UgRXhwaXJlZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tUQkQ0 XSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtVcHN0cmVhbSBNaXNyb3V0aW5nPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1RCRDVdICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0xvb3AgZGV0ZWN0ZWQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbVEJE Nl0gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VFRMIGhvcHMgZXhjZWVkZWQ8YnI+DQo8YnI+ DQpUaGVzZSBwbGFjZWhvbGRlcnMgd291bGQgdGhlbiBnZXQgdXNlZCB0aHJvdWdob3V0IHRoZSBk b2N1bWVudC48YnI+DQo8YnI+DQpbaGFpYmluXSB0aGV5IGFyZSBwbGFjZSBob2xkZXJzLjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9rLCBwbGVhc2UgY2xhcmlmeSBpdCBpbiB0aGUg ZG9jdW1lbnQgaW4gdGhhdCBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PGJyPg0KVGhpcyBzZWN0aW9uIGFsc28gc2F5czo8YnI+DQo8YnI+DQomcXVvdDtJbiBhZGRp dGlvbiwgdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHNldmVyYWwgdHlwZXMgb2YgZXJyb3IgaW5m b3JtYXRpb24gaW4gdGhlIGVycm9yX2luZm8gZmllbGQgaW4gdGhlIGNhc2Ugb2YgQ29kZSAweDY1 LiAuLi4gSGVyZSBhcmUgc29tZSBleGFtcGxlcyBmb3IgdGhlIGVycm9yIGluZm8uIC4uLiBUaGUg ZXJyb3JfaW5mbyBmaWVsZCB2YWx1ZXMgb2YgdGhlIENvZGUgMHg2NiB0byAweDcwIGFyZSB0byBi ZSBhcHBsaWNhdGlvbiBzcGVjaWZpYw0KIGFuZCBkZWZpbmVkIGJ5IHRoZSBwYXJ0aWN1bGFyIG92 ZXJsYXkuJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KSSdtIG5vdCBzdXJlIHdoYXQgaXMgbWVhbnQg YnkgYWxsIG9mIHRoaXMgdGV4dC4gQXMgZGVmaW5lZCBpbiBSRkMgNjk0MCwgZXJyb3JfaW5mbyBp cyBhbiBvcHRpb25hbCBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBieXRlIHN0cmluZy4gSWYgeW91 IGFyZSBpbnRlbmRpbmcgdG8gcmVxdWlyZSBpbXBsZW1lbnRhdGlvbnMgdG8gaW5jbHVkZSBzcGVj aWZpYyB0ZXh0IGluIHRoZSBlcnJvcl9pbmZvIGZvciB0aGUgZmlyc3QgZXJyb3IgY29kZSwgdGhl bg0KIHlvdSBuZWVkIHRvIGV4cGxhaW4gdW5kZXIgd2hhdCBjb25kaXRpb25zIHRoZSBzcGVjaWZp YyB0ZXh0IG5lZWRzIHRvIGJlIGluY2x1ZGVkIGZvciBlYWNoIHN0cmluZy4gQW5kIHRoZSB0ZXh0 IGFib3V0IHRoZSBvdGhlciBjb2RlcyBzZWVtcyByZWR1bmRhbnQgd2l0aCBob3cgZXJyb3JfaW5m byBpcyBhbHJlYWR5IGRlZmluZWQgaW4gUkZDIDY5NDAuPGJyPg0KPGJyPg0KPGJyPg0KW2hhaWJp bl0gaWYgYSBwZWVyIHJlY2VpdmVzIGEgZGlhZ25vc3RpYyByZXF1ZXN0IGZvdW5kIHRoYXQgaXQg Y2Fubm90IHJlYWNoIGl0cyBuZXh0IGhvcCBkdWUgdG8gdW5kZXJsYXkgcHJvYmxlbSwgaXQgbmVl ZHMgdG8gZXhwbGFpbiB3aXRoIGVycm9yX2luZm8gd2hhdCBoYXBwZW5lZC4gSSBkbyBub3Qga25v dyB3aGF0IHlvdSBtZWFuIGJ5IHJlZHVuZGFudCB3aXRoIFJGQyA2OTQwLiBUaGV5IGFyZSBkaWZm ZXJlbnQgZXJyb3JzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+TWF5 YmUgaXTigJlzIGp1c3QgYSBsYW5ndWFnZSB0aGluZywgYnV0IHRoZSBmaXJzdCBzZW50ZW5jZSBz YXlpbmcg4oCcdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIOKApuKAnSBtYWtlcyBpdCBzb3VuZCBs aWtlIHRoZSBsaXN0IG9mIHN0cmluZ3MgaXMgbW9yZSB0aGFuIGp1c3QgYSBsaXN0IG9mIGV4YW1w bGVzLg0KIElmIHRoZXNlIGFyZSBqdXN0IGV4YW1wbGVzIHRoYXQgaW1wbGVtZW50YXRpb25zIGNh biBjaG9vc2UgdG8gdXNlIG9yIG5vdCwgSSB3b3VsZCBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgcmUt cGhyYXNpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PTEQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5czt3aWRvd3M6IDEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ SW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBzZXZlcmFsIHR5cGVzIG9mIGVy cm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9u IGluIHRoZSBlcnJvcl9pbmZvIGZpZWxkIGluIHRoZSBjYXNlIG9mIENvZGUgMHg2NS4mbmJzcDsg VGhlc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYXJlIHJlcHJl c2VudGVkIGFzIGFuIG9wYXF1ZSBVVEYtOCB0ZXh0IHN0cmluZy4mbmJzcDsgSGVyZSBhcmUgc29t ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBleGFtcGxlcyBmb3Ig dGhlIGVycm9yIGluZm8uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+TkVXPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXM7d2lkb3dzOiAxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhlcmUg YXJlIHNvbWUgZXhhbXBsZXMgb2YgZXJyb3JzIHRoYXQgbWlnaHQgYmUgZXhwcmVzc2VkIHVzaW5n IHRoZSBlcnJvcl9pbmZvIGZpZWxkIGluIHRoZSBjYXNlIG9mIENvZGUgW1RCRDFdOjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 YnI+DQo9IFNlY3Rpb24gNS4yOjxicj4NCjxicj4NCjxicj4NCiZxdW90O2V4dF9sZW5ndGggOiB0 aGUgbGVuZ3RoIG9mIHRoZSByZXR1cm5lZCBEaWFnbm9zdGljSW5mbyBpbmZvcm1hdGlvbjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luIGJ5dGVzLiAmbmJzcDtJZiB0aGUgdmFs dWUgaXMgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIDEsIHRoZW4gc29tZTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2V4dGVuZGVkIGRpYWdub3N0aWMgaW5mb3JtYXRpb24gaXMg cmVxdWVzdGVkLiZxdW90Ozxicj4NCjxicj4NClRoaXMgaXMgZGVmaW5pbmcgdGhlIGRpYWdub3N0 aWMgcmVzcG9uc2UgLSB3aHkgd291bGQgdGhlIGV4dGVuc2lvbiBiZSByZXF1ZXN0aW5nIHNvbWV0 aGluZz8gQW5kIGlmIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSBhbiBleHRlbnNpb24gaW4gdGhhdCB3 YXksIHRoZSBleHBlY3RlZCBiZWhhdmlvciBmcm9tIHRoZSBpbml0aWF0b3Igd2hlbiBpdCByZWNl aXZlcyBzdWNoIGFuIGV4dGVuc2lvbiBuZWVkcyB0byBiZSBkZXNjcmliZWQsIG9yIGF0IGxlYXN0 DQogaXQgbmVlZHMgdG8gYmUgbm90ZWQgdGhhdCBhIGRpYWdub3N0aWMgcmVzcG9uc2UgY291bGQg cHJvdm9rZSBhIHJlcXVlc3QgYmFjayB0byB0aGUgaW5pdGlhdG9yLjxicj4NCjxicj4NCltoYWli aW5dIGl0IGlzIHBvc3NpYmxlIHRvIHJld29yZCBpdCBhcyAmcXVvdDsuLi4udGhlbiBzb21lIGV4 dGVuZGVkIGRpYWdub3N0aWMgaW5mb3JtYXRpb24gaXMgcmVzcG9uZGVkLuKAnTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+SG93IGFib3V0IOKAnGlzIGJlaW5nIHNlbnQgaW4gdGhlIHJlc3BvbnNl 4oCdPzxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyPg0KQWxzbywgaW4gdGhlIHN0cnVjdCB0aGUgZGlhZ25vc3RpYyBpbmZvIGlz IGNhbGxlZCAmcXVvdDtkaWFnbm9zdGljX2luZm9fY29udGVudHMmcXVvdDsgYnV0IGluIHRoZSB0 ZXh0IGl0IGlzIGNhbGxlZCZuYnNwOyZxdW90O2RpYWdub3N0aWNfaW5mb3JtYXRpb24uJnF1b3Q7 IFRoZXNlIHNob3VsZCBiZSB0aGUgc2FtZSBJIHRoaW5rLjxicj4NCjxicj4NCltoYWliaW5dIFll cy4gSXQgd2lsbCBiZSBjb3JyZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5PazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPSBT ZWN0aW9uIDUuMzo8YnI+DQo8YnI+DQpJJ20gY29uY2VybmVkIGFib3V0IHRoZSB3YXkgU1RBVFVT X0lORk8gaXMgZGVmaW5lZC4gRmlyc3QsIHdoeSBhcmUgdGhlcmUgMTYgZGlmZmVyZW50IGxldmVs cyBvZiBjb25nZXN0aW9uIHN0YXR1cz8gV2hhdCBhcmUgdGhleSBzdXBwb3NlZCB0byBzaWduaWZ5 PyBJZiB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgd2F5IG9mIG1lYXN1cmluZyBjb25nZXN0aW9u IGRlZmluZWQsIGhvdyBpcyBhIG5vZGUgc3VwcG9zZWQgdG8gaW50ZXJwcmV0IFNUQVRVU19JTkZP DQogcmVjZWl2ZWQgZnJvbSBkaWZmZXJlbnQgcGVlcnM/IFRoYXQgaXMsIGNvdWxkbid0IG9uZSBw ZWVyJ3MgbGV2ZWwgNyBhY3R1YWxseSBtZWFuIGl0IGlzIGxlc3MgY29uZ2VzdGVkIHRoYW4gYW5v dGhlciBwZWVyJ3MgbGV2ZWwgMywgYW5kIHdvbid0IHRoYXQgbWFrZSB0aGUgaW5mb3JtYXRpb24g c29tZXdoYXQgbWVhbmluZ2xlc3MgdG8gdGhlIGluaXRpYXRvcj8gTWF5YmUgdGhpcyB3b3VsZCBi ZSBjbGVhcmVyIGlmIHlvdSBjb3VsZCBleHBsYWluDQogd2hhdCB5b3UgZXhwZWN0IGFuIGluaXRp YXRvciB0byBkbyB3aXRoIHRoZSBpbmZvcm1hdGlvbiBhYm91dCAxNiBkaWZmZXJlbnQgbGV2ZWxz IG9mIGNvbmdlc3Rpb24uPGJyPg0KPGJyPg0KW2hhaWJpbl0gWW91ciBjb25jZXJuIG1ha2VzIHNl bnNlLiBBY3R1YWxseSBpdCBpcyBpbnRlbmRlZCB0byBsZWF2ZSBpdCBmb3Igb3ZlcmxheSBpbXBs ZW1lbnRlcnMgb3IgYSBmdXR1cmUgc3RhbmRhcmQgdG8gZGVmaW5lIHRoZSBjb25nZXN0aW9uIGxl dmVsIGFsZ29yaXRobXMgLiBUaGlzIGRyYWZ0IGp1c3QgZGVmaW5lcyB0aGUgZm9ybWF0IGFuZCBy ZXNlcnZlcyB0aGUgYml0cyBmb3IgdGhlaXIgdXNlLiBBcyB0aGUgc2VjdGlvbiBzYXlzICZxdW90 OyBUaGlzDQogZG9jdW1lbnQgZG9lcyBub3QgcHJvdmlkZSBhIHNwZWNpZmljIG1ldGhvZCBmb3Ig Y29uZ2VzdGlvbiwgbGVhdmluZyB0aGlzIGRlY2lzaW9uIHRvIGVhY2ggbm9kZS4gJm5ic3A7T25l IHBvc3NpYmxlIG9wdGlvbiBmb3IgYSBub2RlIHdvdWxkIGJlIHRvIHRha2UgaXRzIENQVS9tZW1v cnkvYmFuZHdpZHRoIHVzYWdlIHBlcmNlbnRhZ2UgaW4gdGhlIHBhc3QgNjAwIHNlY29uZHMgYW5k IG5vcm1hbGl6ZSB0aGUgaGlnaGVzdCB2YWx1ZSB0byB0aGUgcmFuZ2UNCiBbMHgwMCwgMHgwRl0u ICZuYnNwO0EgZnV0dXJlIGRyYWZ0IG1heSBkZWZpbmUgYW4gb2JqZWN0aXZlIG1lYXN1cmUgb3Ig c3BlY2lmaWMgYWxnb3JpdGhtIGZvciB0aGlzLiZxdW90OyBJIHRoaW5rIHdlIHNob3VsZCBjaGFu Z2UgdGhlIG5vZGUgZGVjaXNpb24gdG8gb3ZlcmxheSBkZWNpc2lvbi4gQW5kIGFuIG92ZXJsYXkg aW1wbGVtZW50ZXIgbWF5IGNob29zZSB0byBub3QgdXNlIGFsbCB0aGF0IDE2IHZhbHVlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9rLCBmdXJ0aGVyIGNsYXJpZmlj YXRpb24gd291bGQgaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxi cj4NClNPRlRXQVJFX1ZFUlNJT04gZG9lc24ndCByZWFsbHkgc2VlbSBsaWtlIGRpYWdub3N0aWMg aW5mb3JtYXRpb24uIFdoaWxlIGFsbCBvZiB0aGUgb3RoZXIgZmllbGRzIG1heSBiZSBjb25zdGFu dGx5IGNoYW5naW5nIGFuZCB0aGVyZWZvcmUgaXQgd291bGQgbWFrZSBzZW5zZSB0byBpbnF1aXJl IGFib3V0IHRoZW0gaW4gYSBkaWFnbm9zdGljIGZhc2hpb24sIFNPRlRXQVJFX1ZFUlNJT04gc2Vl bXMgbW9yZSBsaWtlIGRhdGEgdGhhdCBub2RlcyBjb3VsZA0KIHJlZ2lzdGVyIG9yIGV4Y2hhbmdl IHdoZW4gdGhleSBqb2luIHRoZSBvdmVybGF5LiBXaHkgaXMgaXQgaW5jbHVkZWQgYXMgYSBkaWFn bm9zdGljPzxicj4NCjxicj4NCltoYWliaW5dIERpYWdub3N0aWNzIHVzdWFsbHkgdGFrZSBwbGFj ZSB3aGVuIHRoZXJlIGFyZSBmYWlsdXJlcyBvciBhYm5vcm1hbCBiZWhhdmlvcnMuIFNvZnR3YXJl IHZlcnNpb24gaW5jb21wYXRpYmlsaXR5IG1pZ2h0IGJlIGEgY2F1c2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PaywgZmFpciBlbm91Z2guIFN0aWxsIHNlZW1zIGxp a2UgYW4gb2RkIGNob2ljZSB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxicj4NCkFsc28sIGRvZXNuJ3QgdGhlIFNPRlRXQVJFX1ZFUlNJT04gdHlwZSBuZWVkIGEg bGVuZ3RoIG9yIGEgc3BlY2lmaWVkIGRlbGltaXRlciB0aGF0IGluZGljYXRlcyB0aGUgZW5kIG9m IHRoZSBzdHJpbmc/IE90aGVyd2lzZSwgaG93IGlzIHRoZSByZWNpcGllbnQgc3VwcG9zZWQgdG8g a25vdyB3aGVuIHRvIHN0b3AgcGFyc2luZyBpdD88YnI+DQo8YnI+DQpbaGFpYmluXSBXaWxsIGFk ZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9rPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpUaGUgZGVmaW5pdGlvbnMgb2YmbmJz cDtFV01BX0JZVEVTX1NFTlQgYW5kJm5ic3A7RVdNQV9CWVRFU19SQ1ZEIHNlZW0gcHJvYmxlbWF0 aWMuPGJyPg0KPGJyPg0Kc2VudCA9IGFscGhhIHggc2VudF9wcmVzZW50ICYjNDM7ICgxIC0gYWxw aGEpIHggc2VudDxicj4NCnJjdmQgPSBhbHBoYSB4IHJjdmRfcHJlc2VudCAmIzQzOyAoMSAtIGFs cGhhKSB4IHJjdmQ8YnI+DQo8YnI+DQpBcyB3cml0dGVuIHRoZXNlIGVxdWF0aW9ucyBhcmUgbm90 IHJpZ2h0IGJlY2F1c2Ugc2VudC9yY3ZkIGFwcGVhciBvbiBib3RoIHNpZGVzLiBJdCB3b3VsZCBi ZSBjbGVhcmVyIHRvIHVzZSBsYXN0X3NlbnQgYW5kIGxhc3RfcmN2ZCBvciBzb21lIHN1Y2ggb24g dGhlIHJpZ2h0LWhhbmQgc2lkZSBvZiB0aGVzZSBlcXVhdGlvbnMuIEJ1dCB0aGlzIGJlZ3Mgc29t ZSBiaWdnZXIgcXVlc3Rpb25zOjxicj4NCjxicj4NCi0gRG9lcyB0aGlzIHBsYWNlIGEgcmVxdWly ZW1lbnQgb24gYWxsIG5vZGVzIGltcGxlbWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24gdG8gaGF2 ZSB0byBjYWxjdWxhdGUgdGhlc2UgdmFsdWVzIGV2ZXJ5IDUgc2Vjb25kcz88YnI+DQotIEhvdyBh cmUgdGhlIHZhbHVlcyBjYWxjdWxhdGVkIHRoZSBmaXJzdCB0aW1lPzxicj4NCi0gSG93IHdhcyB0 aGUgdmFsdWUgb2YgNSBzZWNvbmRzIGNob3Nlbj88YnI+DQo8YnI+DQpbSGFpYmluXSBUaGlzIGlz IGluY29ycG9yYXRlZCBmcm9tIHRoZSBlYXJseSBSRUxPQUQgZG9jdW1lbnQuIE1heWJlIHNvbWUg YXV0aG9yIG9mIHRoZSBSRUxPQUQgcHJvdG9jb2wgY2FuIGdpdmUgYSBiZXR0ZXIgZXhwbGFuYXRp b24uPGJyPg0KPGJyPg0KRmluYWxseSwgSSBoYXZlIHRyb3VibGUgdW5kZXJzdGFuZGluZyB3aHkg b25seSBzb21lIG9mIHRoZSB0eXBlcyBhcmUgc3ViamVjdCB0byBhY2Nlc3MgY29udHJvbCBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiA3LiBJdCBzZWVtcyB0byBtZSB0aGF0IGluIHNvbWUgc2l0dWF0 aW9ucyBhbGwgb2YgdGhlIGZpZWxkcyBkZWZpbmVkIGhlcmUgY291bGQgYmUgY29uc2lkZXJlZCBz ZW5zaXRpdmUgYnkgY2VydGFpbiBub2RlcyBvciBvbiBjZXJ0YWluIG5ldHdvcmtzLg0KIFdoYXQg aXMgdGhlIGp1c3RpZmljYXRpb24gZm9yIG9ubHkgbWFraW5nIHNvbWUgb2YgdGhlbSBzdWJqZWN0 IHRvIGFjY2VzcyBjb250cm9sPzxicj4NCjxicj4NCltoYWliaW5dIEFjdHVhbGx5IGl0IHNheXMg ZGlmZmVyZW50IGxldmVsIG9mIGFjY2VzcyBjb250cm9sIGNhbiBiZSBtYWRlLiBGb3IgZXhhbXBs ZSwgZGlhZ25vc3RpYyBpbmZvcm1hdGlvbiBBIGNhbiBiZSBhY2Nlc3NlZCBieSBub2RlIDEgYW5k IDIsIGJ1dCBkaWFnbm9zdGljIGluZm9ybWF0aW9uIEIgY2FuIG9ubHkgYmUgYWNjZXNzZWQgYnkg bm9kZSAyLiBXZSBjYW4gYWRkIHNvbWUgZXhwbGFuYXRpb25zIGFzIGl0IHNlZW1zIG5vdCBjbGVh ciB0bw0KIHJlYWRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5P aywgd2lsbCBhd2FpdCB0aGUgcmV2aXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48YnI+DQo8YnI+DQo9IFNlY3Rpb24gNi4xOjxicj4NCjxicj4NCiZxdW90O1RoZSZu YnNwO2Rlc3RpbmF0aW9uIGZpZWxkIE1VU1QgYmUgc2V0IHRvIHRoZSBkZXNpcmVkIGRlc3RpbmF0 aW9uLCB3aGljaCBNQVkmbmJzcDtiZSBlaXRoZXIgYSBOb2RlSWQgb3IgUmVzb3VyY2VJRCBidXQg U0hPVUxEIE5PVCBiZSB0aGUgYnJvYWRjYXN0Jm5ic3A7Tm9kZUlELiZxdW90Ozxicj4NCjxicj4N CldoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIGEgUGluZyBvciBhIFBhdGhUcmFjayBk b2VzIGdldCBzZW50IHRvIHRoZSBicm9hZGNhc3QgTm9kZUlEPyBPciBzaG91bGQgdGhlc2UgcmVx dWlyZW1lbnRzIHJlYWxseSBiZSBNVVNUIE5PVHM/PGJyPg0KPGJyPg0KW2hhaWJpbl0gSSBndWVz cyB0aGV5IHNob3VsZCBiZSBNVVNUIE5PVHMuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+T2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCj0gU2VjdGlv biA2LjQ6PGJyPg0KPGJyPg0KJnF1b3Q7SG93ZXZlciwgZm9yIGEgc2luZ2xlIGhvcDxicj4NCiZu YnNwOyZuYnNwO21lYXN1cmVtZW50LCB0aGUgdHJhZGl0aW9uYWwgbWVhc3VyZW1lbnQgbWV0aG9k cyBNVVNUIGJlIHVzZWQgaW5zdGVhZDxicj4NCiZuYnNwOyZuYnNwO29mIHRoZSBvdmVybGF5IGxh eWVyIGRpYWdub3N0aWNzIG1ldGhvZHMuJnF1b3Q7PGJyPg0KPGJyPg0KV2hhdCBpcyBtZWFudCBi eSB0aGUgdHJhZGl0aW9uYWwgbWVhc3VyZW1lbnQgbWV0aG9kcz88YnI+DQo8YnI+DQpbaGFpYmlu XSBJdCBtYWlubHkgbWVhbnMgSVAgbGF5ZXIgcGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPldvdWxkIGJlIGdvb2QgdG8gc3BlY2lmeS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+QWxpc3NhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPSBTZWN0aW9uIDk6PGJyPg0KPGJy Pg0KUGxlYXNlIG9ubHkgdXNlIGVpdGhlciBSRkMtWFhYWCBvciBSRkMtQUFBQSBidXQgbm90IGJv dGggYXMgcGxhY2Vob2xkZXJzLjxicj4NCjxicj4NCltoYWliaW5dIFJGQy1BQUFBIGlzIFJGQyA2 OTQwLiBSRkMtWFhYWCBpcyB0aGUgcGxhY2Vob2xkZXIuIFRoZXkgd2lsbCBiZSBjb3JyZWN0ZWQu PGJyPg0KPGJyPg0KUGxlYXNlIGFsc28gdXNlIFtUQkRYXSBmb3IgdmFsdWVzIHlvdSBleHBlY3Qg dG8gYmUgYWxsb2NhdGVkIGJ5IElBTkEuPGJyPg0KPGJyPg0KW2hhaWJpbl0gb2suPGJyPg0KPGJy Pg0KPT0gTml0cyA9PTxicj4NCjxicj4NCjxicj4NCj0gR2VuZXJhbDxicj4NCjxicj4NCjxicj4N ClRoZSBkb2N1bWVudCBzZWVtcyB0byByZXBlYXRlZGx5IGV4cGxhaW4gdGhhdCBpdCBpcyBkb2lu ZyB0aGluZ3MgJnF1b3Q7YXMgc3BlY2lmaWVkIGluIFJGQzY5NDAuJnF1b3Q7IEkgZG9uJ3QgdGhp bmsgdGhpcyBuZWNlc3NhcnkgaW4gbWFueSBjYXNlcy4gSXQncyB3b3J0aCBkb2luZyBhIHBhc3Mg dGhyb3VnaCBhbmQgcmVtb3ZpbmcgdGhlIHBsYWNlcyB3aGVyZSBpdCdzIG9idmlvdXMgdGhhdCB0 aGlzIHNwZWMgaXMgYnVpbGRpbmcgb24gUkZDIDY5NDAuPGJyPg0KPGJyPg0KW2hhaWJpbl0gb2su PGJyPg0KPGJyPg0KPSBTZWN0aW9uIDQuMTo8YnI+DQo8YnI+DQo8YnI+DQpPTEQ8YnI+DQpUaGUg ZXh0ZW5zaW9ucyBzdHJpY3RseSBmb2xsb3cgUkVMT0FEPGJyPg0KJm5ic3A7Jm5ic3A7c3BlY2lm aWNhdGlvbiBvbiB0aGUgbWVzc2FnZXMgcm91dGluZywgdHJhbnNwb3J0LCBOQVQgdHJhdmVyc2Fs IGV0Yy48YnI+DQo8YnI+DQpORVc8YnI+DQpUaGUgZXh0ZW5zaW9ucyBzdHJpY3RseSBmb2xsb3cg aG93IFJFTE9BRCBzcGVjaWZpZXMgbWVzc2FnZSByb3V0aW5nLCB0cmFuc3BvcnQsIE5BVCB0cmF2 ZXJzYWwsIGFuZCBvdGhlciBSRUxPQUQgcHJvdG9jb2wgZmVhdHVyZXMuPGJyPg0KPGJyPg0KPSBT ZWN0aW9uIDQuMi4xOjxicj4NCjxicj4NCjxicj4NCnMvYXMgc3BlY2lmaWVkIGluIFRhYmxlIDQg YW5kJm5ic3A7c3BlY2lmaWVkIGluIHRoZSBSRUxPQUQvYXMgc3BlY2lmaWVkIGluIFRhYmxlIDQv PGJyPg0KPGJyPg0Kcy9uZXcgcmVxdWVzdHMgb2YgdGhlIHRoZS9uZXcgcmVxdWVzdHMgb2YgdGhl Lzxicj4NCjxicj4NCj0gU2VjdGlvbiA0LjM6PGJyPg0KPGJyPg0KT0xEPGJyPg0KV2UgZGVmaW5l IGEgc2ltcGxlIFBhdGhUcmFjayBtZXRob2QgZm9yIHJldHJpZXZpbmcgZGlhZ25vc3RpYzxicj4N CiZuYnNwOyZuYnNwO2luZm9ybWF0aW9uIGl0ZXJhdGl2ZWx5LiAmbmJzcDtUaGUgbWVjaGFuaXNt IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudDxicj4NCiZuYnNwOyZuYnNwO2ZvbGxvd3MgdGhlIFJF TE9BRCBzcGVjaWZpY2F0aW9uLCB0aGUgbmV3IHJlcXVlc3QgYW5kIHJlc3BvbnNlPGJyPg0KJm5i c3A7Jm5ic3A7bWVzc2FnZSB1c2UgdGhlIG1lc3NhZ2UgZm9ybWF0IHNwZWNpZmllZCBpbiBSRUxP QUQgbWVzc2FnZXMuICZuYnNwO1BsZWFzZTxicj4NCiZuYnNwOyZuYnNwO3JlZmVyIHRvIHRoZSBS RUxPQUQgW1JGQzY5NDBdIGZvciBkZXRhaWxzIG9mIHRoZSBwcm90b2NvbC48YnI+DQo8YnI+DQom bmJzcDsmbmJzcDtUaGUgb3BlcmF0aW9uIG9mIHRoaXMgcmVxdWVzdCBpcyBzaG93biBiZWxvdyBp biBGaWd1cmUgMi48YnI+DQo8YnI+DQo8YnI+DQpORVc8YnI+DQpXZSBkZWZpbmUgYSBzaW1wbGUg UGF0aFRyYWNrIG1ldGhvZCBmb3IgcmV0cmlldmluZyBkaWFnbm9zdGljPGJyPg0KJm5ic3A7Jm5i c3A7aW5mb3JtYXRpb24gaXRlcmF0aXZlbHkuICZuYnNwO1RoZSBvcGVyYXRpb24gb2YgdGhpcyBy ZXF1ZXN0IGlzIHNob3duIGJlbG93IGluIEZpZ3VyZSAyLjxicj4NCjxicj4NCj0gU2VjdGlvbiA0 LjMuMS4yOjxicj4NCjxicj4NCnMvYWZ0ZXIgdGhhdC9hZnRlciByZWNlaXZpbmcgYSBQYXRoVHJh Y2tBbnMgd2hlcmUgdGhlJm5ic3A7bmV4dF9ob3Agbm9kZSBJRCBlcXVhbHMgdGhlIHJlc3BvbmRp bmcgbm9kZSBJRC88YnI+DQo8YnI+DQo9IFNlY3Rpb24gNC4zLjIuMTo8YnI+DQo8YnI+DQpzL1Bh dGhUcmFjayBSZXNwb25zZS9QYXRoVHJhY2sgcmVzcG9uc2UvPGJyPg0KPGJyPg0KPSBTZWN0aW9u IDQuNDo8YnI+DQo8YnI+DQpzL2NvZGUuIGFuZCB3ZSBkZWZpbmUvY29kZS4gV2UgZGVmaW5lLzxi cj4NCjxicj4NCj0gU2VjdGlvbiA1Ojxicj4NCjxicj4NCnMvUGF0aF90cmFjayBtZXRob2RzL1Bh dGhUcmFjayBtZXRob2RzLzxicj4NCjxicj4NCj0gU2VjdGlvbiA1LjE6PGJyPg0KPGJyPg0Kcy9O b3RlIHRoYXQgaXMgTk9UL05vdGUgdGhhdCBpdCBpcyBub3QvPGJyPg0KPGJyPg0KPSBTZWN0aW9u IDUuMjo8YnI+DQo8YnI+DQpzL05vdGUgdGhhdCBpcyBOT1QvTm90ZSB0aGF0IGl0IGlzIG5vdC88 YnI+DQo8YnI+DQpzL2NvbnNpc3RzIG9uZSBvciBtb3JlL2NvbnNpc3RzIG9mIG9uZSBvciBtb3Jl Lzxicj4NCjxicj4NCj0gU2VjdGlvbiA2LjE6PGJyPg0KPGJyPg0Kcy9gTUFZL01BWS88YnI+DQo8 YnI+DQo9IFNlY3Rpb24gNi4yOjxicj4NCjxicj4NCnMvcmV0dXJuIHRoZSByZXNwb25zZSB0aGUg aW5pdGlhdG9yIG5vZGUvcmV0dXJuIHRoZSByZXNwb25zZSB0byB0aGUgaW5pdGlhdG9yIG5vZGUv PGJyPg0KPGJyPg0Kcy9UaGUgcGVlciBTSE9VTEQvVGhlIGludGVybWVkaWF0ZSBwZWVyIFNIT1VM RC88YnI+DQo8YnI+DQpbaGFpYmluXSBUaGFua3MgYWdhaW4uPGJyPg0KPGJyPg0KQlIsPGJyPg0K LUhhaWJpbiBTb25nPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOlAyUFNJUEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+UDJQ U0lQQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L3NwYW4+PC9hPjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpQMlBTSVBAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPlAyUFNJUEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E33E01DFD5BEA24B9F3F18671078951F653C3123nkgeml501mbschi_-- From nobody Wed Nov 18 07:21:33 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B411B3288 for ; Wed, 18 Nov 2015 07:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 bJalQYUVwEhE for ; Wed, 18 Nov 2015 07:21:24 -0800 (PST) Received: from mail1.trendhosting.net (mail1.trendhosting.net [195.8.117.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686301B327B for ; Wed, 18 Nov 2015 07:21:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id B7130150FE for ; Wed, 18 Nov 2015 15:21:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail; t=1447860081; bh=66a0+7smzkUjwU6he085Rk5uHZmLEm9sRgl0U5/1iqI=; h=Date:From:To:Subject:From; b=I8VtjY+lOneQ0E4+SwH59q142sw6NF7hMGKFXyk03p6eRtqsGrxHPpno8eBTwNVtx DH5mXZnccxNxzFiHCyBn5O8fDbC6mRI1ZyYgd62CY7oZunA8CLSEgOZ+R96gHDsEDv EHGgFU0QieHjN1tan1WQ42ntF2ieynJ9dRPvnj6g= Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jTdpdLXtgBkL for ; Wed, 18 Nov 2015 15:21:19 +0000 (GMT) Message-ID: <564C976E.6010300@pocock.pro> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail; t=1447860078; bh=66a0+7smzkUjwU6he085Rk5uHZmLEm9sRgl0U5/1iqI=; h=Date:From:To:Subject:From; b=q6+ZWCuyCqqwKM8I4ArYQKULd+wN0wh6xmTr2lHUuw8WZunxyHiuVgDABKCZ2oziF Yt53e6vVcPi8lzYDr7lmHQwE1Bac3fw0n37E+15PJHDcl94DfPWIMDBuZKYkeJicW+ QofforWrdgGQ7icO6tdUOeza2wzUjWgW65oxBC9Y= Date: Wed, 18 Nov 2015 16:21:18 +0100 From: Daniel Pocock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [P2PSIP] [CFP] FOSDEM 2016, RTC devroom, speakers, volunteers neeeded X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 15:21:31 -0000 FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2016 takes place 30-31 January 2016 in Brussels, Belgium. http://fosdem.org This email contains information about: - Real-Time communications dev-room and lounge, - speaking opportunities, - volunteering in the dev-room and lounge, - related events around FOSDEM, including the XMPP summit, - social events (including the Saturday night dinner), - the Planet aggregation sites for RTC blogs Call for participation - Real Time Communications (RTC) ======================================================= The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge. The dev-room is only on Saturday, 30 January 2016. The lounge will be present for both days. To discuss the dev-room and lounge, please join the FSFE-sponsored Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc Speaking opportunities ---------------------- Note: if you used Pentabarf before, please use the same account/username Main track: the deadline for main track presentations is midnight today, 30 October. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track at https://fosdem.org/submit Real-Time Communications dev-room: deadline 27 November Please also use the Pentabarf system to submit a talk proposal for the dev-room. On the "General" tab, please look for the "Track" option and choose "Real-Time devroom". https://penta.fosdem.org/submission/FOSDEM16/ Other dev-rooms: some speakers may find their topic is in the scope of more than one dev-room. It is permitted to apply to more than one dev-room but please be kind enough to tell us if you do this. You can find the full list of dev-rooms at https://www.fosdem.org/2016/schedule/tracks/ Lightning talks: deadline 27 November The lightning talks are an excellent opportunity to introduce a wider audience to your project. Given that dev-rooms are becoming increasingly busy, all speakers are encouraged to consider applying for a lightning talk as well as a slot in the dev-room. On the "General" tab, please look for the "Track" option and choose "Lightning Talks". https://fosdem.org/submit First-time speaking? -------------------- FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it. Submission guidelines --------------------- The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one. In the "Submission notes", please tell us about: - the purpose of your talk - any other talk applications (dev-rooms, lightning talks, main track) - availability constraints and special needs You can use HTML in your bio, abstract and description. If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work. We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics. Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate. Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used. For any questions, please join the FSFE-sponsored Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc Volunteers needed ================= To make the dev-room and lounge run successfully, we are looking for volunteers: - FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this - organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 30 January - participation in the Real-Time lounge - helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses - circulating this Call for Participation to other mailing lists FOSDEM is made possible by volunteers and if you have time to contribute, please feel free to get involved through https://volunteers.fosdem.org/ Related events - XMPP and RTC summits ===================================== The XMPP Standards Foundation (XSF) has traditionally held a summit in the days before FOSDEM. There is discussion about a similar summit taking place on 28 and 29 January 2016 http://wiki.xmpp.org/web/Summit_19 - please join the mailing list for details: http://mail.jabber.org/mailman/listinfo/summit We are also considering a more general RTC or telephony summit, potentially on 29 January. Please join the Free-RTC mailing list and send an email if you would be interested in participating, sponsoring or hosting such an event. Social events and dinners ========================= The traditional FOSDEM beer night occurs on Friday, 29 January On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat: https://lists.fsfe.org/mailman/listinfo/free-rtc Spread the word and discuss =========================== If you know of any mailing lists where this CfP would be relevant, please forward this email. If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk. If you regularly blog about RTC topics, please send details about your blog to the planet site administrators: http://planet.jabber.org ralphm@ik.nu http://planet.sip5060.net daniel@pocock.pro http://planet.opentelecoms.org daniel@pocock.pro Please also link to the Planet sites from your own blog or web site. Contact ======= For discussion and queries, please join the free-rtc mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc The dev-room administration team: Daniel Pocock Ralph Meijer Saúl Ibarra Corretgé Iain R. Learmonth From nobody Wed Nov 18 07:26:40 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F831B327E for ; Wed, 18 Nov 2015 07:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 uCl-XN4uiiFf for ; Wed, 18 Nov 2015 07:26:37 -0800 (PST) Received: from mail1.trendhosting.net (mail1.trendhosting.net [195.8.117.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92E11B328A for ; Wed, 18 Nov 2015 07:26:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id 6413F150FE for ; Wed, 18 Nov 2015 15:26:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail; t=1447860396; bh=cXvhY3EmMcLKELyviztHn1c1cartFnFhzUkeJmbYV3U=; h=Date:From:To:Subject:From; b=WxdJ7dyw+uaFc5Ow2iPbH+vO1FAFmoYZ9xrBcPdYDXZxtn8Um1DbIOsiXtGyfkmHO KU5smKRu+CJ28m6mb7/mAHiQbvSKfq+hjZjVy+tiyssirP+9GhFmvAdudOaZbiy1bj zIsql3GKeM35hlaSvNwLVnqTON+3jpMizi5H1ogI= Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hmwjUXjTPX9i for ; Wed, 18 Nov 2015 15:26:34 +0000 (GMT) Message-ID: <564C98A9.8010207@pocock.pro> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail; t=1447860394; bh=cXvhY3EmMcLKELyviztHn1c1cartFnFhzUkeJmbYV3U=; h=Date:From:To:Subject:From; b=IXkYKw7eJc2T2u45eB3D18iJUKghCso1lgfXAgYqySQZfK26l8FeBfuGWUm0WDb3H RvUgBtg78VCcDrjmoj3oV4tD8/guhsdZB8md2s+J3JV4WDeathPVQ0ADqiK2sEUJ7S 0QmbT2CfZcR77D1lTkeT9ttxPPOLzekoDSaGIj9Q= Date: Wed, 18 Nov 2015 16:26:33 +0100 From: Daniel Pocock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: P2PSIP@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [P2PSIP] FOSDEM, SIP RELOAD and alternative P2P implementations? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 15:26:39 -0000 Can anybody give any examples of projects implementing SIP RELOAD? Is anybody keeping track of any alternatives and how they relate to p2psip work? Two projects I've seen already (not SIP based): http://tox.chat https://ring.cx/ It would be interesting to have a dedicated time slot in the FOSDEM RTC dev-room to look at anything in this space. I've forwarded a copy of the call for participation and would be happy to discuss it with anybody who wants to participate. Regards, Daniel From nobody Wed Nov 18 13:30:02 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F031B2F79 for ; Wed, 18 Nov 2015 13:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 5RqFPshWNHpj for ; Wed, 18 Nov 2015 13:29:59 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1623C1B2F7A for ; Wed, 18 Nov 2015 13:29:59 -0800 (PST) Received: by lfaz4 with SMTP id z4so35596559lfa.0 for ; Wed, 18 Nov 2015 13:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e97shclNwFPHVbfL6w09DELb9LOI+Wju1KreAoTafE4=; b=qZuPquuWR6Y9yJHkVvGCMN7lDa4ncNQGWb6K4/0VRhq++TdImJk0IYV1NkcC3jLH0G jMxbD1KhnwwLiuMj7K/pldCJev2dp5H0gPcYmAO23rH169i1cZ3b9TFmT8nMRt2w2EVq tdHKbkP6FY98lSwq+1umt7aGyowpE7xejyb0EdSNMCMGMi94hC3/j+ka4pU4cLI+VyDM QHgH50hWttvUarsSq/p2e87vI3G0rLB/ftDLpTg/ZDIug2KrD+4lwI9cDpIVAhl2GAWR NGokD4NX1oqF45SOHI2/pCpW505jA1VQZ1YZiPTT2BbkU/MVaf13T0xm7YcHAz7+243i OPIA== X-Received: by 10.25.209.77 with SMTP id i74mr1713058lfg.143.1447882197054; Wed, 18 Nov 2015 13:29:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.158.84 with HTTP; Wed, 18 Nov 2015 13:29:37 -0800 (PST) In-Reply-To: <564C98A9.8010207@pocock.pro> References: <564C98A9.8010207@pocock.pro> From: EdPimentl Date: Wed, 18 Nov 2015 16:29:37 -0500 Message-ID: To: Daniel Pocock Content-Type: multipart/alternative; boundary=001a11411164083f260524d75855 Archived-At: Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] FOSDEM, SIP RELOAD and alternative P2P implementations? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 21:30:01 -0000 --001a11411164083f260524d75855 Content-Type: text/plain; charset=UTF-8 To contribute to Ring.cx development : git clone https://gerrit-ring.savoirfairelinux.com/ring-daemon git clone https://gerrit-ring.savoirfairelinux.com/ring-client-gnome git clone https://gerrit-ring.savoirfairelinux.com/ring-client-windows git clone https://gerrit-ring.savoirfairelinux.com/ring-client-macosx git clone https://gerrit-ring.savoirfairelinux.com/ring-client-android -E IoT Cloud Labs (In Stealth Mode) --001a11411164083f260524d75855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To contribute to Ring.cx development :

git clone https://gerr= it-ring.savoirfairelinux.com/ring-daemon
git clone https://gerrit-ring.s= avoirfairelinux.com/ring-client-gnome
git clone https://gerrit-ring.sa= voirfairelinux.com/ring-client-windows
git clone https://gerrit-ring.sa= voirfairelinux.com/ring-client-macosx
git clone https://gerrit-ring.sa= voirfairelinux.com/ring-client-android



-E
IoT Cloud Labs (In Stealth Mode)
--001a11411164083f260524d75855-- From nobody Wed Nov 18 13:38:57 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F91A1A55 for ; Wed, 18 Nov 2015 13:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 TuVaYHWcom7z for ; Wed, 18 Nov 2015 13:38:55 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE791B2F9A for ; Wed, 18 Nov 2015 13:38:55 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 79D0120565 for ; Wed, 18 Nov 2015 16:38:54 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 18 Nov 2015 16:38:54 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=HtVIU vttrA/b8uiQNh94jZwm+kI=; b=j3hLkvZd5it/7zxAiny2HyPInEOe8W0KO0Fdl 2dbxe/3+gOkgC1JUEMcHOZndgjD/vmvwCK/T4h4KUrNstac5JRgoAR0O+7CwvPJw F0Nga7RIsyQJROQuA6UEd+jW1KNykMz8stT28EwKbJkRKsPQRorZsdlLlbYef1fO MgwHWM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=HtVIUvttrA/b8uiQNh94jZwm+kI=; b=ZKrq+ DXNp9iE3TZLB0yepLaLrqdPnMa7z2u1/6v5M0tbDXkO2FhJXttFaoXQxKMmrE1+k A+8JGvZTMm4qNYdLNp1HHTUi0SWNjiTF2DtTBq0ArJRn41voSiMOBpcZBIcjIILB JUGSGpCns/W3LB/ND0Y8Mrgd7VvlGzAJw/1xPQ= X-Sasl-enc: rlgHXPj4a2/bLdcRsm5J5//K1IVAlVtnE48SFL3ReNCz 1447882734 Received: from dhcp-171-68-20-140.cisco.com (dhcp-171-68-20-140.cisco.com [171.68.20.140]) by mail.messagingengine.com (Postfix) with ESMTPA id C34CAC018FA; Wed, 18 Nov 2015 16:38:53 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_72280038-0045-468B-93D2-9A2D1D63D479" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 18 Nov 2015 13:38:52 -0800 Message-Id: References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> To: "Songhaibin (A)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 21:38:56 -0000 --Apple-Mail=_72280038-0045-468B-93D2-9A2D1D63D479 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Haibin, > On Nov 16, 2015, at 10:44 PM, Songhaibin (A) = wrote: >=20 > Hi Alissa, > =20 > I can accept the second suggestion. > =20 > But for the first comment, I=E2=80=99m not sure. IMO, it does not = distinguish the bytes sent/rcvd to/from upstream or downstream peer, but = only calculate that in total.=20 Ok. Please answer the questions below, though. The answers are not = evident from the draft. Thanks, Alissa > =20 > Best Regards! > -Haibin > =20 > From: Alissa Cooper [mailto:alissa@cooperw.in = ]=20 > Sent: Thursday, November 12, 2015 7:10 AM > To: Songhaibin (A) > Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org = > Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 > =20 > Thanks Haibin. This looks good but there are still a few unresolved = issues from our earlier mail exchange: > =20 > The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem = problematic. >=20 > sent =3D alpha x sent_present + (1 - alpha) x sent > rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd >=20 > As written these equations are not right because sent/rcvd appear on = both sides. It would be clearer to use last_sent and last_rcvd or some = such on the right-hand side of these equations. But this begs some = bigger questions: >=20 > - Does this place a requirement on all nodes implementing this = specification to have to calculate these values every 5 seconds? > - How are the values calculated the first time? > - How was the value of 5 seconds chosen? --Apple-Mail=_72280038-0045-468B-93D2-9A2D1D63D479 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Haibin,

On Nov 16, 2015, at 10:44 PM, = Songhaibin (A) <haibin.song@huawei.com> wrote:

Hi Alissa,
 
I can accept the second suggestion.
 
But for the first comment, I=E2=80=99m not sure. IMO, it does = not distinguish the bytes sent/rcvd to/from upstream or downstream peer, = but only calculate that in total. 

Ok. Please answer the questions = below, though. The answers are not evident from the draft.

Thanks,
Alissa

 
Best Regards!
-Haibin
 
From: Alissa = Cooper [mailto:alissa@cooperw.in] 
Sent: Thursday, November 12, 2015 = 7:10 AM
To: Songhaibin (A)
Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: [P2PSIP] AD evaluation: = draft-ietf-p2psip-diagnostics-17
 
Thanks Haibin. This looks good but there are still a few = unresolved issues from our earlier mail exchange:
 
The definitions of EWMA_BYTES_SENT = and EWMA_BYTES_RCVD seem problematic.

sent =3D alpha x sent_present + (1 - alpha) x sent
rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd

As written these equations are not right = because sent/rcvd appear on both sides. It would be clearer to use = last_sent and last_rcvd or some such on the right-hand side of these = equations. But this begs some bigger questions:

- Does this place a requirement on all nodes implementing = this specification to have to calculate these values every 5 seconds?
- How are the values calculated the first time?
-= How was the value of 5 seconds chosen?

= --Apple-Mail=_72280038-0045-468B-93D2-9A2D1D63D479-- From nobody Wed Nov 18 13:41:41 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F171B2FA3 for ; Wed, 18 Nov 2015 13:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VpQHDZE5YZfw for ; Wed, 18 Nov 2015 13:41:37 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72191B2F9B for ; Wed, 18 Nov 2015 13:41:37 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 112872099D for ; Wed, 18 Nov 2015 16:41:37 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 18 Nov 2015 16:41:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=+RiMt QmLbL9ME1I8AWarzwl/WEw=; b=uBrT4WFPzgGEN94ydxHung4eTtC8n/OQvBuOu ConERIxednZNVOvl8AvHTQuBlNQOdfj5YBnd9E+IagmwzpR/TYqHjAR3KbnVaqHt pqFGJZcDx/KKexLEVsbwSFiKwub/ugeUAqMSU5GcWef1OWCqNa6mE/M1LgHv96EB oeuAlY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=+RiMtQmLbL9ME1I8AWarzwl/WEw=; b=Z4E5d uIFDYSAHB+Eixp5r+qSpjHC9wSarba8rJamwmb/SnjTehbcv6dH2xXwRc9CE4yAE Qt+xkYsRZKFCWo9BBG4kTAApTBqUR/IFMs77Tj3P44p0AmbsY/1V1z+1g6A8Wr7Z 2qYXiiItOXFFsbMogi1a3s1BBVMBM5nEyMfFN8= X-Sasl-enc: w7TLj5BD5kGHQnL+3WY7VfZu5ix2eulFwrhndnIWKAR6 1447882896 Received: from dhcp-171-68-20-140.cisco.com (dhcp-171-68-20-140.cisco.com [171.68.20.140]) by mail.messagingengine.com (Postfix) with ESMTPA id 58FF7C018F8; Wed, 18 Nov 2015 16:41:36 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F91B099B-7357-4454-A662-2F05ECBE6737" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 18 Nov 2015 13:41:35 -0800 Message-Id: References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> To: "Songhaibin (A)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 21:41:40 -0000 --Apple-Mail=_F91B099B-7357-4454-A662-2F05ECBE6737 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I should have also said: I think we can continue the discussion on this = one point during IETF LC. So once you post the rev with the changes to = section 5 I will initiate IETF LC. Thanks, Alissa > On Nov 18, 2015, at 1:38 PM, Alissa Cooper wrote: >=20 > Hi Haibin, >=20 >> On Nov 16, 2015, at 10:44 PM, Songhaibin (A) > wrote: >>=20 >> Hi Alissa, >> =20 >> I can accept the second suggestion. >> =20 >> But for the first comment, I=E2=80=99m not sure. IMO, it does not = distinguish the bytes sent/rcvd to/from upstream or downstream peer, but = only calculate that in total.=20 >=20 > Ok. Please answer the questions below, though. The answers are not = evident from the draft. >=20 > Thanks, > Alissa >=20 >> =20 >> Best Regards! >> -Haibin >> =20 >> From: Alissa Cooper [mailto:alissa@cooperw.in = ]=20 >> Sent: Thursday, November 12, 2015 7:10 AM >> To: Songhaibin (A) >> Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org = >> Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 >> =20 >> Thanks Haibin. This looks good but there are still a few unresolved = issues from our earlier mail exchange: >> =20 >> The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem = problematic. >>=20 >> sent =3D alpha x sent_present + (1 - alpha) x sent >> rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd >>=20 >> As written these equations are not right because sent/rcvd appear on = both sides. It would be clearer to use last_sent and last_rcvd or some = such on the right-hand side of these equations. But this begs some = bigger questions: >>=20 >> - Does this place a requirement on all nodes implementing this = specification to have to calculate these values every 5 seconds? >> - How are the values calculated the first time? >> - How was the value of 5 seconds chosen? >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail=_F91B099B-7357-4454-A662-2F05ECBE6737 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I should have also said: I think we can = continue the discussion on this one point during IETF LC. So once you = post the rev with the changes to section 5 I will initiate IETF = LC.

Thanks,
Alissa

On = Nov 18, 2015, at 1:38 PM, Alissa Cooper <alissa@cooperw.in> = wrote:

Hi Haibin,

On Nov 16, 2015, at 10:44 PM, = Songhaibin (A) <haibin.song@huawei.com> wrote:

Hi Alissa,
 
I can accept the second suggestion.
 
But for the first comment, I=E2=80=99m not sure. IMO, it does = not distinguish the bytes sent/rcvd to/from upstream or downstream peer, = but only calculate that in total. 

Ok. Please = answer the questions below, though. The answers are not evident from the = draft.

Thanks,
Alissa

 
Best Regards!
-Haibin
 
From: Alissa = Cooper [mailto:alissa@cooperw.in] 
Sent: Thursday, November 12, 2015 = 7:10 AM
To: Songhaibin (A)
Cc: p2psip; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: [P2PSIP] AD evaluation: = draft-ietf-p2psip-diagnostics-17
 
Thanks Haibin. This looks good but there are still a few = unresolved issues from our earlier mail exchange:
 
The definitions of EWMA_BYTES_SENT = and EWMA_BYTES_RCVD seem problematic.

sent =3D alpha x sent_present + (1 - alpha) x sent
rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd

As written these equations are not right = because sent/rcvd appear on both sides. It would be clearer to use = last_sent and last_rcvd or some such on the right-hand side of these = equations. But this begs some bigger questions:

- Does this place a requirement on all nodes implementing = this specification to have to calculate these values every 5 seconds?
- How are the values calculated the first time?
-= How was the value of 5 seconds chosen?

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip


= --Apple-Mail=_F91B099B-7357-4454-A662-2F05ECBE6737-- From nobody Wed Nov 18 21:57:06 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973511A88D8 for ; Wed, 18 Nov 2015 21:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 qmc0Y3RtNcgG for ; Wed, 18 Nov 2015 21:56:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC331A88DA for ; Wed, 18 Nov 2015 21:56:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAN58528; Thu, 19 Nov 2015 05:56:45 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 19 Nov 2015 05:56:44 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Thu, 19 Nov 2015 13:56:40 +0800 From: "Songhaibin (A)" To: Alissa Cooper Thread-Topic: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 Thread-Index: AQHQ1umosqhZ/UWGA0i8P+k8SWdo8p4P1gUAgAGVAoCAAygiwIAYAXYAgCzfIQCAOf21AIAEBqUAgAjfnlCAAgdhAIAAAMKAgAEQYNA= Date: Thu, 19 Nov 2015 05:56:39 +0000 Message-ID: References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F653CD77Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.564D649E.00A6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 49454a7dd6667c7db696732ecdcea0da Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 05:56:55 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F653CD77Ankgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0suIFN1cmUuDQoNCkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCg0KRnJvbTogQWxpc3NhIENvb3Bl ciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE5 LCAyMDE1IDU6NDIgQU0NClRvOiBTb25naGFpYmluIChBKQ0KQ2M6IHAycHNpcDsgZHJhZnQtaWV0 Zi1wMnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUDJQU0lQ XSBBRCBldmFsdWF0aW9uOiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xNw0KDQpJIHNo b3VsZCBoYXZlIGFsc28gc2FpZDogSSB0aGluayB3ZSBjYW4gY29udGludWUgdGhlIGRpc2N1c3Np b24gb24gdGhpcyBvbmUgcG9pbnQgZHVyaW5nIElFVEYgTEMuIFNvIG9uY2UgeW91IHBvc3QgdGhl IHJldiB3aXRoIHRoZSBjaGFuZ2VzIHRvIHNlY3Rpb24gNSBJIHdpbGwgaW5pdGlhdGUgSUVURiBM Qy4NCg0KVGhhbmtzLA0KQWxpc3NhDQoNCk9uIE5vdiAxOCwgMjAxNSwgYXQgMTozOCBQTSwgQWxp c3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4g d3JvdGU6DQoNCkhpIEhhaWJpbiwNCg0KT24gTm92IDE2LCAyMDE1LCBhdCAxMDo0NCBQTSwgU29u Z2hhaWJpbiAoQSkgPGhhaWJpbi5zb25nQGh1YXdlaS5jb208bWFpbHRvOmhhaWJpbi5zb25nQGh1 YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQWxpc3NhLA0KDQpJIGNhbiBhY2NlcHQgdGhlIHNlY29u ZCBzdWdnZXN0aW9uLg0KDQpCdXQgZm9yIHRoZSBmaXJzdCBjb21tZW50LCBJ4oCZbSBub3Qgc3Vy ZS4gSU1PLCBpdCBkb2VzIG5vdCBkaXN0aW5ndWlzaCB0aGUgYnl0ZXMgc2VudC9yY3ZkIHRvL2Zy b20gdXBzdHJlYW0gb3IgZG93bnN0cmVhbSBwZWVyLCBidXQgb25seSBjYWxjdWxhdGUgdGhhdCBp biB0b3RhbC4NCg0KT2suIFBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9ucyBiZWxvdywgdGhvdWdo LiBUaGUgYW5zd2VycyBhcmUgbm90IGV2aWRlbnQgZnJvbSB0aGUgZHJhZnQuDQoNClRoYW5rcywN CkFsaXNzYQ0KDQoNCg0KQmVzdCBSZWdhcmRzIQ0KLUhhaWJpbg0KDQpGcm9tOiBBbGlzc2EgQ29v cGVyIFttYWlsdG86YWxpc3NhQGNvb3BlcncuaW5dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIg MTIsIDIwMTUgNzoxMCBBTQ0KVG86IFNvbmdoYWliaW4gKEEpDQpDYzogcDJwc2lwOyBkcmFmdC1p ZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1w MnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1AyUFNJUF0g QUQgZXZhbHVhdGlvbjogZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTcNCg0KVGhhbmtz IEhhaWJpbi4gVGhpcyBsb29rcyBnb29kIGJ1dCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcgdW5yZXNv bHZlZCBpc3N1ZXMgZnJvbSBvdXIgZWFybGllciBtYWlsIGV4Y2hhbmdlOg0KDQpUaGUgZGVmaW5p dGlvbnMgb2YgRVdNQV9CWVRFU19TRU5UIGFuZCBFV01BX0JZVEVTX1JDVkQgc2VlbSBwcm9ibGVt YXRpYy4NCg0Kc2VudCA9IGFscGhhIHggc2VudF9wcmVzZW50ICsgKDEgLSBhbHBoYSkgeCBzZW50 DQpyY3ZkID0gYWxwaGEgeCByY3ZkX3ByZXNlbnQgKyAoMSAtIGFscGhhKSB4IHJjdmQNCg0KQXMg d3JpdHRlbiB0aGVzZSBlcXVhdGlvbnMgYXJlIG5vdCByaWdodCBiZWNhdXNlIHNlbnQvcmN2ZCBh cHBlYXIgb24gYm90aCBzaWRlcy4gSXQgd291bGQgYmUgY2xlYXJlciB0byB1c2UgbGFzdF9zZW50 IGFuZCBsYXN0X3JjdmQgb3Igc29tZSBzdWNoIG9uIHRoZSByaWdodC1oYW5kIHNpZGUgb2YgdGhl c2UgZXF1YXRpb25zLiBCdXQgdGhpcyBiZWdzIHNvbWUgYmlnZ2VyIHF1ZXN0aW9uczoNCg0KLSBE b2VzIHRoaXMgcGxhY2UgYSByZXF1aXJlbWVudCBvbiBhbGwgbm9kZXMgaW1wbGVtZW50aW5nIHRo aXMgc3BlY2lmaWNhdGlvbiB0byBoYXZlIHRvIGNhbGN1bGF0ZSB0aGVzZSB2YWx1ZXMgZXZlcnkg NSBzZWNvbmRzPw0KLSBIb3cgYXJlIHRoZSB2YWx1ZXMgY2FsY3VsYXRlZCB0aGUgZmlyc3QgdGlt ZT8NCi0gSG93IHdhcyB0aGUgdmFsdWUgb2YgNSBzZWNvbmRzIGNob3Nlbj8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxp c3QNClAyUFNJUEBpZXRmLm9yZzxtYWlsdG86UDJQU0lQQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQo= --_000_E33E01DFD5BEA24B9F3F18671078951F653CD77Ankgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i WkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0suIFN1cmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1 c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVz dGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LUhhaWJpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMTksIDIwMTUgNTo0MiBBTTxicj4NCjxiPlRv OjwvYj4gU29uZ2hhaWJpbiAoQSk8YnI+DQo8Yj5DYzo8L2I+IHAycHNpcDsgZHJhZnQtaWV0Zi1w MnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtQMlBTSVBdIEFEIGV2YWx1YXRpb246IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzLTE3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgc2hvdWxkIGhhdmUg YWxzbyBzYWlkOiBJIHRoaW5rIHdlIGNhbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlz IG9uZSBwb2ludCBkdXJpbmcgSUVURiBMQy4gU28gb25jZSB5b3UgcG9zdCB0aGUgcmV2IHdpdGgg dGhlIGNoYW5nZXMgdG8gc2VjdGlvbiA1IEkgd2lsbCBpbml0aWF0ZSBJRVRGIExDLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5BbGlzc2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPk9uIE5vdiAxOCwgMjAxNSwgYXQgMTozOCBQTSwgQWxpc3NhIENvb3BlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIj5hbGlzc2FAY29vcGVydy5pbjwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I aSBIYWliaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBO b3YgMTYsIDIwMTUsIGF0IDEwOjQ0IFBNLCBTb25naGFpYmluIChBKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmhhaWJpbi5zb25nQGh1YXdlaS5jb20iPmhhaWJpbi5zb25nQGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQWxpc3NhLDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjYW4gYWNjZXB0 IHRoZSBzZWNvbmQgc3VnZ2VzdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBmb3IgdGhlIGZpcnN0IGNvbW1lbnQsIEni gJltIG5vdCBzdXJlLiBJTU8sIGl0IGRvZXMgbm90IGRpc3Rpbmd1aXNoIHRoZSBieXRlcyBzZW50 L3JjdmQgdG8vZnJvbSB1cHN0cmVhbSBvciBkb3duc3RyZWFtIHBlZXIsIGJ1dCBvbmx5IGNhbGN1 bGF0ZQ0KIHRoYXQgaW4gdG90YWwuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9r LiBQbGVhc2UgYW5zd2VyIHRoZSBxdWVzdGlvbnMgYmVsb3csIHRob3VnaC4gVGhlIGFuc3dlcnMg YXJlIG5vdCBldmlkZW50IGZyb20gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGlz c2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVv Z3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QmVzdCBSZWdhcmRzITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1IYWliaW48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkFsaXNzYQ0KIENvb3BlciBbPGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBj b29wZXJ3LmluIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86YWxpc3NhQGNvb3Bl cncuaW48L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAxNSA3OjEwIEFNPGJy Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5Tb25naGFpYmluIChBKTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+cDJwc2lwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1wMnBz aXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+UmU6IFtQMlBTSVBdIEFEIGV2YWx1YXRpb246IGRyYWZ0LWlldGYtcDJwc2lw LWRpYWdub3N0aWNzLTE3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhhbmtzIEhhaWJpbi4gVGhpcyBsb29rcyBnb29kIGJ1dCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcg dW5yZXNvbHZlZCBpc3N1ZXMgZnJvbSBvdXIgZWFybGllciBtYWlsIGV4Y2hhbmdlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRlZmluaXRpb25zIG9mJm5ic3A7RVdNQV9CWVRF U19TRU5UIGFuZCZuYnNwO0VXTUFfQllURVNfUkNWRCBzZWVtIHByb2JsZW1hdGljLjxicj4NCjxi cj4NCnNlbnQgPSBhbHBoYSB4IHNlbnRfcHJlc2VudCAmIzQzOyAoMSAtIGFscGhhKSB4IHNlbnQ8 YnI+DQpyY3ZkID0gYWxwaGEgeCByY3ZkX3ByZXNlbnQgJiM0MzsgKDEgLSBhbHBoYSkgeCByY3Zk PGJyPg0KPGJyPg0KQXMgd3JpdHRlbiB0aGVzZSBlcXVhdGlvbnMgYXJlIG5vdCByaWdodCBiZWNh dXNlIHNlbnQvcmN2ZCBhcHBlYXIgb24gYm90aCBzaWRlcy4gSXQgd291bGQgYmUgY2xlYXJlciB0 byB1c2UgbGFzdF9zZW50IGFuZCBsYXN0X3JjdmQgb3Igc29tZSBzdWNoIG9uIHRoZSByaWdodC1o YW5kIHNpZGUgb2YgdGhlc2UgZXF1YXRpb25zLiBCdXQgdGhpcyBiZWdzIHNvbWUgYmlnZ2VyIHF1 ZXN0aW9uczo8YnI+DQo8YnI+DQotIERvZXMgdGhpcyBwbGFjZSBhIHJlcXVpcmVtZW50IG9uIGFs bCBub2RlcyBpbXBsZW1lbnRpbmcgdGhpcyBzcGVjaWZpY2F0aW9uIHRvIGhhdmUgdG8gY2FsY3Vs YXRlIHRoZXNlIHZhbHVlcyBldmVyeSA1IHNlY29uZHM/PGJyPg0KLSBIb3cgYXJlIHRoZSB2YWx1 ZXMgY2FsY3VsYXRlZCB0aGUgZmlyc3QgdGltZT88YnI+DQotIEhvdyB3YXMgdGhlIHZhbHVlIG9m IDUgc2Vjb25kcyBjaG9zZW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpQMlBTSVBAaWV0Zi5vcmciPlAyUFNJUEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycHNpcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBz aXA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E33E01DFD5BEA24B9F3F18671078951F653CD77Ankgeml501mbschi_-- From nobody Wed Nov 25 14:58:21 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFA21B323B for ; Wed, 25 Nov 2015 14:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 q1UA2XigqHxi for ; Wed, 25 Nov 2015 14:58:17 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489C81B3239 for ; Wed, 25 Nov 2015 14:58:17 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5798A201B9 for ; Wed, 25 Nov 2015 17:58:16 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 25 Nov 2015 17:58:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=z0O nz+ts0LPPk4X608iOaKhDYq4=; b=yhgHxrCCGekAmXCzcJjEQzB/JI8ZJtuAFIy YjrIIDao2SgzLn3K/vhVYz+V9dsG0oTzXk4AGETuGtUv3qCIlE4z67A12m+YDLD+ UQ/Y9u9wqoYtShMEFkkcnFDCo4YWbXZ+WBABEOjvIsNWhr/Pq4yy8NCP2o+FtoOM gIf4J0hU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=z0Onz+ts0LPPk4X608iOaKhDYq4=; b=S6yEi wbEtRabRh44Rj4qIJTsK2x41z4Q56oO9OVhIFL3LFX9zE6khFpzRZt9S1a3IdNel e23LI10VhoEo3F/KbIDRSoQ8hcoyKe9a6WBxrEgSuiRa1jSyYXh0hOV+eC1a66tr 0Ffwey4m4kA2sK3QLs7hs1fQm6G+P+94zqM3qI= X-Sasl-enc: M0p21iXA17xzTUYu60lT/ehyDDllQ0Jg/YijV5yus+zI 1448492295 Received: from dhcp-171-68-20-58.cisco.com (dhcp-171-68-20-58.cisco.com [171.68.20.58]) by mail.messagingengine.com (Postfix) with ESMTPA id DE7C1C0001C for ; Wed, 25 Nov 2015 17:58:15 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> Date: Wed, 25 Nov 2015 14:58:14 -0800 To: p2psip Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [P2PSIP] AD evaluation: draft-ietf-p2psip-concepts-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 22:58:19 -0000 I have reviewed this document in preparation for IETF last call. There = are a few edits that need to be made before this document can be = last-called: 1) The document needs a security considerations section. It is perfectly = fine if this section mostly points to the security considerations of the = other p2psip documents, but it needs to be there. 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved. 3) Section 1 should be deleted. While you=E2=80=99re making changes, please address the following: 4) Fix the ID nits. 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour. 6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem = appropriate and don=E2=80=99t add much value, so I would suggest = deleting them. 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call = it a draft and should reference the RFC. Thanks, Alissa= From nobody Wed Nov 25 19:55:47 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992631AC411 for ; Wed, 25 Nov 2015 19:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no 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 EIQMwCzDXIQs for ; Wed, 25 Nov 2015 19:55:45 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C661AC40C for ; Wed, 25 Nov 2015 19:55:44 -0800 (PST) Received: by igvg19 with SMTP id g19so6873132igv.1 for ; Wed, 25 Nov 2015 19:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ethernot-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mdnrE3sjXoBjzYmsgE5QSFkJZW5ENyGpcAdpg0NwsJk=; b=VoocCs2HO+YpWMs4yU8gByQuBIF4V6TRLeJI2N4r+Wy1BjN7r09QXNTts7dM0ekYCn +CPy+ViOfhm1pso1bXapO9mjzvZJ/ZXPJa3LP2XFn+tZC2rhcAVyBX9GWtl458ofUtjU kdYB1x0YeDE+FZCvY0Tfh28g246A1bYRdCL0Tux/LtnQTLvMZVYWr1yEqxjG4RZZ1P3/ sEyyvfn0bNfS/zx+TxzI0wFn5jn6oG8KQ238iwaDkkQzTtNBV2E6eUnwrMU4I6QPqumF ilpi1pWylo3XmyIsv0m+98eFp8qhBgFrzXPqUOnBR5FPSzBWTGh/w7TNt9twaTg66063 Y1Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mdnrE3sjXoBjzYmsgE5QSFkJZW5ENyGpcAdpg0NwsJk=; b=l4522UkTM3roTvR++1rVNIwNKQ5tjhECbutfA2dya8SAK6aaIcuDqPpf1msmK/+Zfb hAf+rx+wdLN08J/yUIhhMi1aPSnwTzf17ZCWhSZPcjMf0wPXkxgxlWqhcDBZwU6RVgIQ WeVBEdEP4YQxy1bAxrniutKTTh6pBiSbJ4astgBVQDA9QDhdQMqv5T/HHdWkWBT30sdl GuFXHshGY9DXXMO4SkfeRXHNbM+PJ8mG96Beof4NZNyMWOGVhaWmW1ZoSAeOOYJ8GKkw Z7T0FphUJCi1pRUJft//A40F4Acgtgx5p6RHjoN12AfGGFgN3J2e2gvuKdFlwu2BD3kV aWig== X-Gm-Message-State: ALoCoQm4rSCVZ+thvH82a/SVHdbz3oJT7Dpj3ai9ksbmtESAgFolTTB71ZJok2N6riavizVYmz6x MIME-Version: 1.0 X-Received: by 10.50.66.144 with SMTP id f16mr949068igt.22.1448510143327; Wed, 25 Nov 2015 19:55:43 -0800 (PST) Received: by 10.107.14.1 with HTTP; Wed, 25 Nov 2015 19:55:43 -0800 (PST) Received: by 10.107.14.1 with HTTP; Wed, 25 Nov 2015 19:55:43 -0800 (PST) In-Reply-To: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> Date: Wed, 25 Nov 2015 21:55:43 -0600 Message-ID: From: David Bryan To: Alissa Cooper Content-Type: multipart/alternative; boundary=047d7bdc9dae8c06790525698c43 Archived-At: Cc: P2PSIP WG Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-concepts-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 03:55:46 -0000 --047d7bdc9dae8c06790525698c43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you very much for the review and comments. I will look over the comments, and revise shortly. On Nov 25, 2015 4:58 PM, "Alissa Cooper" wrote: > I have reviewed this document in preparation for IETF last call. There ar= e > a few edits that need to be made before this document can be last-called: > > 1) The document needs a security considerations section. It is perfectly > fine if this section mostly points to the security considerations of the > other p2psip documents, but it needs to be there. > > 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2= =80=9D These need > to be resolved. > > 3) Section 1 should be deleted. > > > While you=E2=80=99re making changes, please address the following: > > 4) Fix the ID nits. > > 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than > Bonjour. > > 6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem > appropriate and don=E2=80=99t add much value, so I would suggest deleting= them. > > 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call = it a draft and > should reference the RFC. > > > Thanks, > Alissa > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --047d7bdc9dae8c06790525698c43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you very much for the review and comments.

I will look over the comments, and revise shortly.

On Nov 25, 2015 4:58 PM, "Alissa Cooper&quo= t; <alissa@cooperw.in> wrote= :
I have reviewed th= is document in preparation for IETF last call. There are a few edits that n= eed to be made before this document can be last-called:

1) The document needs a security considerations section. It is perfectly fi= ne if this section mostly points to the security considerations of the othe= r p2psip documents, but it needs to be there.

2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

3) Section 1 should be deleted.


While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

5) I think Section 3.5 should reference RFC 6762 and 6763 rather than Bonjo= ur.

6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem ap= propriate and don=E2=80=99t add much value, so I would suggest deleting the= m.

7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call it= a draft and should reference the RFC.


Thanks,
Alissa
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--047d7bdc9dae8c06790525698c43-- From nobody Thu Nov 26 08:55:58 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB87F1B2BF8 for ; Thu, 26 Nov 2015 08:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 51ht1-KuToFI for ; Thu, 26 Nov 2015 08:55:55 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B211B2BF6 for ; Thu, 26 Nov 2015 08:55:55 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1a1zpp-0006ka-Fd for ; Thu, 26 Nov 2015 17:55:53 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 63662B00B9E for ; Thu, 26 Nov 2015 17:55:53 +0100 (CET) To: p2psip@ietf.org References: <564C98A9.8010207@pocock.pro> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <56573999.9090706@kit.edu> Date: Thu, 26 Nov 2015 17:55:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564C98A9.8010207@pocock.pro> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1448556953. Archived-At: Subject: Re: [P2PSIP] FOSDEM, SIP RELOAD and alternative P2P implementations? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 16:55:57 -0000 Hi Daniel, Am 18.11.2015 um 16:26 schrieb Daniel Pocock: > Can anybody give any examples of projects implementing SIP RELOAD? Yes, we have got an implementation, called RELOAD-kit. We moved to git VC recently and currently this isn't publicly available, but that should be changed soon. Regards, Roland From nobody Thu Nov 26 18:20:52 2015 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 289311B30D0; Thu, 26 Nov 2015 18:20:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151127022050.23486.3369.idtracker@ietfa.amsl.com> Date: Thu, 26 Nov 2015 18:20:50 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-19.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:20:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-19.txt Pages : 29 Date : 2015-11-26 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 26 18:26:17 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7D1B30F4 for ; Thu, 26 Nov 2015 18:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 Iset22BED3Tu for ; Thu, 26 Nov 2015 18:26:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0BB1B30F3 for ; Thu, 26 Nov 2015 18:26:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAW24842; Fri, 27 Nov 2015 02:26:08 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 27 Nov 2015 02:26:07 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Fri, 27 Nov 2015 10:25:54 +0800 From: "Songhaibin (A)" To: "Songhaibin (A)" , Alissa Cooper Thread-Topic: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 Thread-Index: AQHQ1umosqhZ/UWGA0i8P+k8SWdo8p4P1gUAgAGVAoCAAygiwIAYAXYAgCzfIQCAOf21AIAEBqUAgAjfnlCAAgdhAIAAAMKAgAEQYNCADFdUAA== Date: Fri, 27 Nov 2015 02:25:54 +0000 Message-ID: References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F653D773Bnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5657BF41.00B3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 49454a7dd6667c7db696732ecdcea0da Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:26:15 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F653D773Bnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGlzc2EsDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiB3aXRoIGNoYW5n ZXMgdG8gdGhlIGRpYWdub3N0aWMgaW5mb3JtYXRpb24gYXV0aG9yaXphdGlvbiBwYXJ0LCBhbmQg bGVhdmUgdGhlICBFV01BX0JZVEVTX1NFTlQgYW5kIEVXTUFfQllURVNfUkNWRCBmb3IgZGlzY3Vz c2lvbiBkdXJpbmcgSUVURiBsYXN0IGNhbGwuDQoNCkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCg0K RnJvbTogU29uZ2hhaWJpbiAoQSkgW21haWx0bzpoYWliaW4uc29uZ0BodWF3ZWkuY29tXQ0KU2Vu dDogVGh1cnNkYXksIE5vdmVtYmVyIDE5LCAyMDE1IDE6NTcgUE0NClRvOiBBbGlzc2EgQ29vcGVy DQpDYzogcDJwc2lwOyBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0b29scy5pZXRmLm9y Zw0KU3ViamVjdDogUkU6IFtQMlBTSVBdIEFEIGV2YWx1YXRpb246IGRyYWZ0LWlldGYtcDJwc2lw LWRpYWdub3N0aWNzLTE3DQoNCk9LLiBTdXJlLg0KDQpCZXN0IFJlZ2FyZHMhDQotSGFpYmluDQoN CkZyb206IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbl0NClNlbnQ6IFRo dXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAxNSA1OjQyIEFNDQpUbzogU29uZ2hhaWJpbiAoQSkNCkNj OiBwMnBzaXA7IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0B0b29scy5pZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbUDJQU0lQXSBBRCBldmFsdWF0aW9uOiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9z dGljcy0xNw0KDQpJIHNob3VsZCBoYXZlIGFsc28gc2FpZDogSSB0aGluayB3ZSBjYW4gY29udGlu dWUgdGhlIGRpc2N1c3Npb24gb24gdGhpcyBvbmUgcG9pbnQgZHVyaW5nIElFVEYgTEMuIFNvIG9u Y2UgeW91IHBvc3QgdGhlIHJldiB3aXRoIHRoZSBjaGFuZ2VzIHRvIHNlY3Rpb24gNSBJIHdpbGwg aW5pdGlhdGUgSUVURiBMQy4NCg0KVGhhbmtzLA0KQWxpc3NhDQoNCk9uIE5vdiAxOCwgMjAxNSwg YXQgMTozOCBQTSwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNz YUBjb29wZXJ3LmluPj4gd3JvdGU6DQoNCkhpIEhhaWJpbiwNCg0KT24gTm92IDE2LCAyMDE1LCBh dCAxMDo0NCBQTSwgU29uZ2hhaWJpbiAoQSkgPGhhaWJpbi5zb25nQGh1YXdlaS5jb208bWFpbHRv OmhhaWJpbi5zb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQWxpc3NhLA0KDQpJIGNhbiBh Y2NlcHQgdGhlIHNlY29uZCBzdWdnZXN0aW9uLg0KDQpCdXQgZm9yIHRoZSBmaXJzdCBjb21tZW50 LCBJ4oCZbSBub3Qgc3VyZS4gSU1PLCBpdCBkb2VzIG5vdCBkaXN0aW5ndWlzaCB0aGUgYnl0ZXMg c2VudC9yY3ZkIHRvL2Zyb20gdXBzdHJlYW0gb3IgZG93bnN0cmVhbSBwZWVyLCBidXQgb25seSBj YWxjdWxhdGUgdGhhdCBpbiB0b3RhbC4NCg0KT2suIFBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9u cyBiZWxvdywgdGhvdWdoLiBUaGUgYW5zd2VycyBhcmUgbm90IGV2aWRlbnQgZnJvbSB0aGUgZHJh ZnQuDQoNClRoYW5rcywNCkFsaXNzYQ0KDQoNCkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCg0KRnJv bTogQWxpc3NhIENvb3BlciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KU2VudDogVGh1cnNk YXksIE5vdmVtYmVyIDEyLCAyMDE1IDc6MTAgQU0NClRvOiBTb25naGFpYmluIChBKQ0KQ2M6IHAy cHNpcDsgZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDog UmU6IFtQMlBTSVBdIEFEIGV2YWx1YXRpb246IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNz LTE3DQoNClRoYW5rcyBIYWliaW4uIFRoaXMgbG9va3MgZ29vZCBidXQgdGhlcmUgYXJlIHN0aWxs IGEgZmV3IHVucmVzb2x2ZWQgaXNzdWVzIGZyb20gb3VyIGVhcmxpZXIgbWFpbCBleGNoYW5nZToN Cg0KVGhlIGRlZmluaXRpb25zIG9mIEVXTUFfQllURVNfU0VOVCBhbmQgRVdNQV9CWVRFU19SQ1ZE IHNlZW0gcHJvYmxlbWF0aWMuDQoNCnNlbnQgPSBhbHBoYSB4IHNlbnRfcHJlc2VudCArICgxIC0g YWxwaGEpIHggc2VudA0KcmN2ZCA9IGFscGhhIHggcmN2ZF9wcmVzZW50ICsgKDEgLSBhbHBoYSkg eCByY3ZkDQoNCkFzIHdyaXR0ZW4gdGhlc2UgZXF1YXRpb25zIGFyZSBub3QgcmlnaHQgYmVjYXVz ZSBzZW50L3JjdmQgYXBwZWFyIG9uIGJvdGggc2lkZXMuIEl0IHdvdWxkIGJlIGNsZWFyZXIgdG8g dXNlIGxhc3Rfc2VudCBhbmQgbGFzdF9yY3ZkIG9yIHNvbWUgc3VjaCBvbiB0aGUgcmlnaHQtaGFu ZCBzaWRlIG9mIHRoZXNlIGVxdWF0aW9ucy4gQnV0IHRoaXMgYmVncyBzb21lIGJpZ2dlciBxdWVz dGlvbnM6DQoNCi0gRG9lcyB0aGlzIHBsYWNlIGEgcmVxdWlyZW1lbnQgb24gYWxsIG5vZGVzIGlt cGxlbWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24gdG8gaGF2ZSB0byBjYWxjdWxhdGUgdGhlc2Ug dmFsdWVzIGV2ZXJ5IDUgc2Vjb25kcz8NCi0gSG93IGFyZSB0aGUgdmFsdWVzIGNhbGN1bGF0ZWQg dGhlIGZpcnN0IHRpbWU/DQotIEhvdyB3YXMgdGhlIHZhbHVlIG9mIDUgc2Vjb25kcyBjaG9zZW4/ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQMlBT SVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmc8bWFpbHRvOlAyUFNJUEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQoNCg0K --_000_E33E01DFD5BEA24B9F3F18671078951F653D773Bnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkRlYXIgQWxpc3NhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUg c3VibWl0dGVkIGEgbmV3IHZlcnNpb24gd2l0aCBjaGFuZ2VzIHRvIHRoZSBkaWFnbm9zdGljIGlu Zm9ybWF0aW9uIGF1dGhvcml6YXRpb24gcGFydCwgYW5kIGxlYXZlIHRoZSAmbmJzcDtFV01BX0JZ VEVTX1NFTlQgYW5kJm5ic3A7RVdNQV9CWVRFU19SQ1ZEDQogZm9yIGRpc2N1c3Npb24gZHVyaW5n IElFVEYgbGFzdCBjYWxsLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmVzdCBSZWdhcmRzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tSGFpYmluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU29uZ2hhaWJpbiAo QSkgW21haWx0bzpoYWliaW4uc29uZ0BodWF3ZWkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAxNSAxOjU3IFBNPGJyPg0KPGI+VG86PC9iPiBBbGlzc2Eg Q29vcGVyPGJyPg0KPGI+Q2M6PC9iPiBwMnBzaXA7IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0 aWNzQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbUDJQU0lQXSBBRCBl dmFsdWF0aW9uOiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xNzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PSy4gU3VyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVz dCBSZWdhcmRzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tSGFp YmluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWxpc3NhIENvb3BlciBbPGEg aHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIj5tYWlsdG86YWxpc3NhQGNvb3BlcncuaW48 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAxNSA1OjQy IEFNPGJyPg0KPGI+VG86PC9iPiBTb25naGFpYmluIChBKTxicj4NCjxiPkNjOjwvYj4gcDJwc2lw OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0 Zi5vcmciPg0KZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3NAdG9vbHMuaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUDJQU0lQXSBBRCBldmFsdWF0aW9uOiBkcmFmdC1p ZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5JIHNob3VsZCBoYXZlIGFsc28gc2FpZDogSSB0aGluayB3ZSBjYW4gY29udGlu dWUgdGhlIGRpc2N1c3Npb24gb24gdGhpcyBvbmUgcG9pbnQgZHVyaW5nIElFVEYgTEMuIFNvIG9u Y2UgeW91IHBvc3QgdGhlIHJldiB3aXRoIHRoZSBjaGFuZ2VzIHRvIHNlY3Rpb24gNSBJIHdpbGwg aW5pdGlhdGUgSUVURiBMQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxpc3NhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBOb3YgMTgsIDIwMTUsIGF0IDE6Mzgg UE0sIEFsaXNzYSBDb29wZXIgJmx0OzxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiI+ YWxpc3NhQGNvb3BlcncuaW48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgSGFpYmluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gTm92IDE2LCAyMDE1LCBhdCAxMDo0NCBQTSwgU29uZ2hh aWJpbiAoQSkgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWliaW4uc29uZ0BodWF3ZWkuY29tIj5oYWli aW4uc29uZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhp IEFsaXNzYSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgY2FuIGFjY2VwdCB0aGUgc2Vjb25kIHN1Z2dlc3Rpb24uPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQg Zm9yIHRoZSBmaXJzdCBjb21tZW50LCBJ4oCZbSBub3Qgc3VyZS4gSU1PLCBpdCBkb2VzIG5vdCBk aXN0aW5ndWlzaCB0aGUgYnl0ZXMgc2VudC9yY3ZkIHRvL2Zyb20gdXBzdHJlYW0gb3IgZG93bnN0 cmVhbSBwZWVyLCBidXQgb25seSBjYWxjdWxhdGUNCiB0aGF0IGluIHRvdGFsLjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Pay4gUGxlYXNlIGFuc3dlciB0aGUgcXVlc3Rpb25zIGJl bG93LCB0aG91Z2guIFRoZSBhbnN3ZXJzIGFyZSBub3QgZXZpZGVudCBmcm9tIHRoZSBkcmFmdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWxpc3NhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVz dCBSZWdhcmRzITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1 c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1IYWliaW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkFsaXNzYQ0KIENvb3BlciBbPGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3Lmlu Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86YWxpc3NhQGNvb3BlcncuaW48L3Nw YW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAxNSA3OjEwIEFNPGJyPg0KPGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Tb25n aGFpYmluIChBKTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+cDJwc2lwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25v c3RpY3NAdG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRyYWZ0LWll dGYtcDJwc2lwLWRpYWdub3N0aWNzQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+UmU6IFtQMlBTSVBdIEFEIGV2YWx1YXRpb246IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0 aWNzLTE3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIEhh aWJpbi4gVGhpcyBsb29rcyBnb29kIGJ1dCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcgdW5yZXNvbHZl ZCBpc3N1ZXMgZnJvbSBvdXIgZWFybGllciBtYWlsIGV4Y2hhbmdlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGRlZmluaXRpb25zIG9mJm5ic3A7RVdNQV9CWVRFU19TRU5UIGFu ZCZuYnNwO0VXTUFfQllURVNfUkNWRCBzZWVtIHByb2JsZW1hdGljLjxicj4NCjxicj4NCnNlbnQg PSBhbHBoYSB4IHNlbnRfcHJlc2VudCAmIzQzOyAoMSAtIGFscGhhKSB4IHNlbnQ8YnI+DQpyY3Zk ID0gYWxwaGEgeCByY3ZkX3ByZXNlbnQgJiM0MzsgKDEgLSBhbHBoYSkgeCByY3ZkPGJyPg0KPGJy Pg0KQXMgd3JpdHRlbiB0aGVzZSBlcXVhdGlvbnMgYXJlIG5vdCByaWdodCBiZWNhdXNlIHNlbnQv cmN2ZCBhcHBlYXIgb24gYm90aCBzaWRlcy4gSXQgd291bGQgYmUgY2xlYXJlciB0byB1c2UgbGFz dF9zZW50IGFuZCBsYXN0X3JjdmQgb3Igc29tZSBzdWNoIG9uIHRoZSByaWdodC1oYW5kIHNpZGUg b2YgdGhlc2UgZXF1YXRpb25zLiBCdXQgdGhpcyBiZWdzIHNvbWUgYmlnZ2VyIHF1ZXN0aW9uczo8 YnI+DQo8YnI+DQotIERvZXMgdGhpcyBwbGFjZSBhIHJlcXVpcmVtZW50IG9uIGFsbCBub2RlcyBp bXBsZW1lbnRpbmcgdGhpcyBzcGVjaWZpY2F0aW9uIHRvIGhhdmUgdG8gY2FsY3VsYXRlIHRoZXNl IHZhbHVlcyBldmVyeSA1IHNlY29uZHM/PGJyPg0KLSBIb3cgYXJlIHRoZSB2YWx1ZXMgY2FsY3Vs YXRlZCB0aGUgZmlyc3QgdGltZT88YnI+DQotIEhvdyB3YXMgdGhlIHZhbHVlIG9mIDUgc2Vjb25k cyBjaG9zZW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpQMlBTSVBAaWV0Zi5vcmciPlAyUFNJUEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ay cHNpcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E33E01DFD5BEA24B9F3F18671078951F653D773Bnkgeml501mbschi_-- From nobody Mon Nov 30 12:00:52 2015 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DEE1B301B; Mon, 30 Nov 2015 12:00:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151130200049.7903.29845.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 12:00:49 -0800 Archived-At: Cc: alcoop@cisco.com, draft-ietf-p2psip-diagnostics@ietf.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Last Call: (P2P Overlay Diagnostics) to Proposed Standard X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:00:50 -0000 The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'P2P Overlay Diagnostics' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1427/ https://datatracker.ietf.org/ipr/1190/ From nobody Mon Nov 30 12:06:40 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF391B3050 for ; Mon, 30 Nov 2015 12:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5vJXF3wLs857 for ; Mon, 30 Nov 2015 12:06:27 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02681B304A for ; Mon, 30 Nov 2015 12:06:26 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2D5B020BBD for ; Mon, 30 Nov 2015 15:06:25 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 30 Nov 2015 15:06:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=AciAu NZuWv6JS1RYSOK+XlRhjc8=; b=qKbYWFvAi16vIWNsBXQUN2FcEP5pLwVzlPV0C tSPA49TC3t1fZBaOQeQkCLiLsvmWlmZfBJ8xJV2T48qphlrvIrhjaIHatPe+gMGM V3WtM1MBmiaC51wBsuU7qaLaZF0KCiqTGU8Esps/AjEZGlrIQlvJyjRQEZgqLmo3 y7bw0s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=AciAuNZuWv6JS1RYSOK+XlRhjc8=; b=QCNr2 YjADvymZTaVpXhPt+3W+ehv+2OLn+vkiyxpemQr26M6IPMQsp52tGPePuOV1lXd3 litriuDEo//crMpHwY5prYgV4k/nhhGbtNBgdL3eOoZdC20bj+2a+vwL3Na+TImv ZzuyxzJQjliaF5ZvjEa34H+nhxwhOb9fLStwWM= X-Sasl-enc: Sep/XPtH116q4EM0y6T0It3ulDIAQi9eqZQccORlnKHz 1448913984 Received: from dhcp-171-68-20-106.cisco.com (dhcp-171-68-20-106.cisco.com [171.68.20.106]) by mail.messagingengine.com (Postfix) with ESMTPA id D4AEA680087; Mon, 30 Nov 2015 15:06:23 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E8C082E-BA70-419A-A655-5B07A1F94068" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Mon, 30 Nov 2015 12:06:22 -0800 Message-Id: <0F1001E5-3C1F-4275-A748-06332B5B5FAF@cooperw.in> References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in> To: "Songhaibin (A)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: p2psip , "draft-ietf-p2psip-diagnostics@tools.ietf.org" Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 20:06:33 -0000 --Apple-Mail=_9E8C082E-BA70-419A-A655-5B07A1F94068 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks. Last call has been initiated. Still looking for answers below. >>=20 >> The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem = problematic. >>=20 >> sent =3D alpha x sent_present + (1 - alpha) x sent >> rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd >>=20 >> As written these equations are not right because sent/rcvd appear on = both sides. It would be clearer to use last_sent and last_rcvd or some = such on the right-hand side of these equations. But this begs some = bigger questions: >>=20 >> - Does this place a requirement on all nodes implementing this = specification to have to calculate these values every 5 seconds? >> - How are the values calculated the first time? >> - How was the value of 5 seconds chosen? Alissa > On Nov 26, 2015, at 6:25 PM, Songhaibin (A) = wrote: >=20 > Dear Alissa, > =20 > I have submitted a new version with changes to the diagnostic = information authorization part, and leave the EWMA_BYTES_SENT and = EWMA_BYTES_RCVD for discussion during IETF last call.=20 > =20 > Best Regards! > -Haibin --Apple-Mail=_9E8C082E-BA70-419A-A655-5B07A1F94068 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks. Last call has been initiated. Still = looking for answers below.


The definitions of EWMA_BYTES_SENT = and EWMA_BYTES_RCVD seem problematic.

sent =3D alpha x sent_present + (1 - alpha) x sent
rcvd =3D alpha x rcvd_present + (1 - alpha) x rcvd

As written these equations are not right = because sent/rcvd appear on both sides. It would be clearer to use = last_sent and last_rcvd or some such on the right-hand side of these = equations. But this begs some bigger questions:

- Does this place a requirement on all nodes implementing = this specification to have to calculate these values every 5 seconds?
- How are the values calculated the first time?
-= How was the value of 5 seconds = chosen?

Alissa


On = Nov 26, 2015, at 6:25 PM, Songhaibin (A) <haibin.song@huawei.com> wrote:

Dear Alissa,
 
I have submitted a new version with changes to the diagnostic = information authorization part, and leave the  EWMA_BYTES_SENT = and EWMA_BYTES_RCVD for discussion during IETF last call. 
 
Best Regards!
-Haibin
= --Apple-Mail=_9E8C082E-BA70-419A-A655-5B07A1F94068--