From nobody Fri Apr 6 11:17:30 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33330126BF7 for ; Fri, 6 Apr 2018 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 CdwGbOBzVNXK for ; Fri, 6 Apr 2018 11:17:24 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6242B127136 for ; Fri, 6 Apr 2018 11:17:24 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id w36IHDJs004679-w36IHDJu004679 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2018 20:17:13 +0200 Received: from [192.168.1.86] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id w36IHCxE028165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2018 20:17:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Simon Pietro Romano In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8322F4@DGGEMM506-MBX.china.huawei.com> Date: Fri, 6 Apr 2018 20:17:08 +0200 Cc: "clue@ietf.org" , Roberta Presta Content-Transfer-Encoding: quoted-printable Message-Id: <3A4C3270-A956-4B2A-B886-080AE114EDC9@unina.it> References: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> <6E58094ECC8D8344914996DAD28F1CCD8322F4@DGGEMM506-MBX.china.huawei.com> To: Roni Even , Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:17:28 -0000 Hello Roni and Adam, >>> BLOCKER: Section 5.1: The description of =20 >>> describes a scheme in which multiple supported versions can be=20 >>> listed; and, if the list is omitted, it implies that only the = version=20 >>> described in is supported. This text does not define (nor does=20= >>> any other text that I can find) what should be set to when=20 >>> is used. Intuitively, it seems that should = be=20 >>> set to the largest minor version of the smallest major version=20 >>> advertised in , but that (or whatever the correct=20= >>> answer is) needs to be clearly spelled out. >>>=20 >> [SPR] I believe we were giving for granted that =E2=80=9Cv=E2=80=9D = should be, in such=20 >> case, the highest supported version (i.e., largest major and larger=20= >> minor numbers). Now that you make me think around that, I would = simply=20 >> say that the =E2=80=9Cv=E2=80=9D attribute MUST be set to one of the = versions that the=20 >> entity in question supports, as per the list. I=20= >> can, e.g., decide that I send an =E2=80=98options=E2=80=99 with = =E2=80=9Cv=3D12.23=E2=80=9D if the=20 >> list is like in the following: >>=20 >> 33.44 >> 27.0 >> 12.345 >> 1.44 >=20 > I think this formulation is a problem. I assume the intention behind = the "v" field is that some implementation that receives a version number = in the "v" field with a major number higher than it understands is = supposed to close the connection, since it runs a risk of = misinterpreting the contents of messages. So, in your example, if you = sent "v=3D12.23" to my implementation that only spoke major version 1, I = would reject it, even though you also support major version 1. That's = why I was thinking it should contain the smallest major version being = advertised. >=20 > The minor version is obviously less useful in this context, since = they're defined to be backwards and forwards compatible, but it's more = useful to know the highest minor version supported than some random = minor version, as it indicates the full feature set that is supported.=20= > The reason it's less useful is that the value can be parsed out of the = list. >=20 >=20 > [Roni] I think that even selecting the lower major for "v" does not = solve the problem since in the example above the Channel Receiver may = support any of the above versions and the channel initiator does not = know which. I think recommending the higher version is also how RFC6120 = specify it Did we reach any consensus on this point, in the end? I=E2=80=99m asking = since we=E2=80=99re working on the revised version of the document and = this part seems to be still controversial. Thanks, Simon From nobody Fri Apr 6 11:27:58 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E8C127333 for ; Fri, 6 Apr 2018 11:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 2HXoq5HkRknG for ; Fri, 6 Apr 2018 11:27:55 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46BF127136 for ; Fri, 6 Apr 2018 11:27:54 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id w36IRk2T010851-w36IRk2V010851 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2018 20:27:46 +0200 Received: from [192.168.1.86] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id w36IRiB1029773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2018 20:27:45 +0200 From: Simon Pietro Romano Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FA59F3DE-5D53-4D8A-9C1A-AF0C4891D06C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 6 Apr 2018 20:27:43 +0200 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD863A56@DGGEMM506-MBX.china.huawei.com> Cc: "clue@ietf.org" , Adam Roach , Roberta Presta To: "Roni Even (A)" References: <6E58094ECC8D8344914996DAD28F1CCD863A56@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [clue] Question about timers (retry and timeouts) in draft-ietf-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:27:58 -0000 --Apple-Mail=_FA59F3DE-5D53-4D8A-9C1A-AF0C4891D06C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello again Roni, > Hi, > An important issue that was made by Adam during his AD review has to = do with timeout and retry thresholds, please provide feedback > =20 > This is the comment: > BLOCKER: General: There are several mentions of timeouts and retry = thresholds in the text and its corresponding state machines; however, = the document neither defines nor cites a document as defining what these = timeout and retry values are. These need to be defined and described. If = the timer and retry scheme allows the two ends of the connection to have = different values for timeouts and number of retries, then there need to = be additional error procedures that allow the MC and MP state machines = to stay in sync (if the timer/retry values can be different, it's = possible for one state machine to transition to "terminated," while the = other is still active, and you need messaging to clean this up). The = remainder of this comment is non-blocking: Related to this, the document = frequently refers to retries as "expiring" (e.g., "retry expired" on the = state diagrams). That doesn't really make sense unless "retry" is the = name of a timer rather than a counter; I think you mean to say = "exhausted" or something similar. >=20 > =20 > My view as individual: > =20 > The CLUE protocol is delivered using SCTP =E2=80=9CCLUE entities are = required to use ordered SCTP message delivery, with full reliability=E2=80= =9D so there is no problem with timeout for retry for the data channel = (https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-3.3.2 = = ) > =20 > So the retry and timeout are for the application level and not for the = sctp transport. > =20 > =46rom the discussion on the mailing list during the WGLC > =20 > =E2=80=9CThe idea here is that the MC avoids entering a loop where the = MP keeps on sending an erroneous ADV hence forcing the MC to respond = with a NACK. If this situation iterates for a while (# of retries), the = MC terminates the ongoing CLUE =E2=80=9Csession=E2=80=9D.=20 > I noticed that the discussion started even earlier and the conclusion = was that retry and timeout are needed but we also need default values = which were never listed > My understanding is that when a receiver of a protocol message sends a = negative ack as response he allows for reties of fixed message and will = allow it n times or quit after x time if no new message arrives. > I think that for retries any number is good but I think that 2 is OK = since is the message sender cannot send a valid message we should = abandon the call. As for timeout this can be a short one that will still = allow for a round trip so my view that 1 second is enough > Other thoughs? There is indeed Adam=E2=80=99s answer to my answer, that I=E2=80=99m = copy/pasting below for the benefit of the readers: > In thinking through what this scheme should look like, it occurs to me = that the CLUE messages are defined to be sent over a reliable transport = (SCTP), which has its own retransmission timers and eventual timeouts. = Implementing a retransmission scheme on top of a reliable transport -- = especially one as aggressive as you suggest above -- will put more = traffic on the network when congestion occurs rather than less. >=20 > So, in the final analysis, I think the action here is to remove = retransmission timers and retry counts altogether. If the underlying = transport takes longer to detect a failure than is sensible for CLUE = (and it likely does), then a supervisory timer that declares the session = failed might make sense. I would be personally inclined to take Adam=E2=80=99s suggestion and get = rid of those timers and retry counts altogether. What is your feeling = about that? Thanks, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > =20 > One side comment in section 6.2 there are two instances of =E2=80=9Cnumb= er of timeouts=E2=80=9D ? > =20 > =20 > =20 > Roni Even > Clue co-chair > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_FA59F3DE-5D53-4D8A-9C1A-AF0C4891D06C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hello again Roni,

Hi,
An important issue that was made by Adam during his AD review = has to do with timeout and retry thresholds, please provide feedback

This is the comment:
BLOCKER: General: = There are several mentions of timeouts and retry thresholds in the text = and its corresponding state machines; however, the document neither = defines nor cites a document as defining what these timeout and retry = values are. These need to be defined and described. If the timer and = retry scheme allows the two ends of the connection to have different = values for timeouts and number of retries, then there need to be = additional error procedures that allow the MC and MP state machines to = stay in sync (if the timer/retry values can be different, it's possible = for one state machine to transition to "terminated," while the other is = still active, and you need messaging to clean this up). The remainder of = this comment is non-blocking: Related to this, the document frequently = refers to retries as "expiring" (e.g., "retry expired" on the state = diagrams). That doesn't really make sense unless "retry" is the name of = a timer rather than a counter; I think you mean to say "exhausted" or = something similar.

My view as = individual:

The CLUE protocol is = delivered using SCTP =E2=80=9CCLUE entities = are required to use ordered SCTP message delivery, with full = reliability=E2=80=9D so there is no problem with timeout for retry for = the data channel (https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#sect= ion-3.3.2 )

So the retry and = timeout are for the application level and not for the sctp = transport.

=46rom the = discussion on the mailing list during the WGLC

=E2=80=9CThe idea here is that the MC avoids = entering a loop where the MP keeps on sending an erroneous ADV hence = forcing the MC to respond with a NACK. If this situation iterates for a = while (# of retries), the MC terminates the ongoing CLUE =E2=80=9Csession=E2= =80=9D.
I noticed that the discussion started even earlier and the = conclusion was that retry and timeout are needed but we also need = default values which were never listed
My understanding is that when a receiver of a protocol = message sends a negative ack as response he allows for reties of fixed = message and will allow it n times or quit after x time if no new message = arrives.
I think that for retries any number is good but I think that = 2 is OK since is the message sender cannot send a valid message we = should abandon the call. As for timeout this can be a short one that = will still allow for a round trip so my view that 1 second is enough
Other thoughs?

There is indeed Adam=E2=80=99s answer to my answer, = that I=E2=80=99m copy/pasting below for the benefit of the = readers:

In thinking through what this scheme should = look like, it occurs to me that the CLUE messages are defined to be sent = over a reliable transport (SCTP), which has its own retransmission = timers and eventual timeouts. Implementing a retransmission scheme on = top of a reliable transport -- especially one as aggressive as you = suggest above -- will put more traffic on the network when congestion = occurs rather than less.

So, in the final = analysis, I think the action here is to remove retransmission timers and = retry counts altogether. If the underlying transport takes longer to = detect a failure than is sensible for CLUE (and it likely does), then a = supervisory timer that declares the session failed might make = sense.

I would be personally = inclined to take Adam=E2=80=99s suggestion and get rid of those timers = and retry counts altogether. What is your feeling about that?

Thanks,

Simon

= =       _\\|//_
= =    ( O-O )
= ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=    Simon Pietro Romano
= Universita' di Napoli Federico II
=    = Computer Engineering Department
= Phone: +39 081 = 7683823 -- Fax: +39 081 7683816
= = = e-mail: spromano@unina.it

= <<Molti mi dicono che lo scoraggiamento = =C3=A8 l'alibi degli
idioti. Ci = rifletto un istante; e mi scoraggio>>. Magritte.
= = oooO
= ~~~~~~~~~~~~~~~~~~~~~~~( = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
= = \ ( ( )
= = \_) = ) /
= = = = (_/

 
One side =
comment in section 6.2 there are two instances of =E2=80=9Cnumber of timeouts=E2=80=9D =
?
Roni Even
Clue co-chair
_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_FA59F3DE-5D53-4D8A-9C1A-AF0C4891D06C-- From nobody Sat Apr 7 22:48:35 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C517B12711D for ; Sat, 7 Apr 2018 22:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 9CkyA-Sphj42 for ; Sat, 7 Apr 2018 22:48:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 CEF22126FB3 for ; Sat, 7 Apr 2018 22:48:30 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 596F4768379EF for ; Sun, 8 Apr 2018 06:48:25 +0100 (IST) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 06:48:26 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 13:48:22 +0800 From: "Roni Even (A)" To: Simon Pietro Romano CC: "clue@ietf.org" , Adam Roach , "Roberta Presta" Thread-Topic: [clue] Question about timers (retry and timeouts) in draft-ietf-clue-protocol Thread-Index: AQHTzdT7Q206d8/kzU+mjJtceT/eGaP2W3tg Date: Sun, 8 Apr 2018 05:48:22 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD871B66@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD863A56@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.69] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD871B66DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [clue] Question about timers (retry and timeouts) in draft-ietf-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 05:48:34 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD871B66DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgU2ltb24sDQpJIHRoaW5rIHRoYXQgQWRhbeKAmXMgYW5kIHlvdXJzIHN1Z2dlc3Rpb24gdG8g cmVtb3ZlIHRoZSB0aW1lcnMgbWFrZSBzZW5zZSBzaW5jZSB3ZSBhcmUgdXNpbmcgYSByZWxpYWJs ZSBwcm90b2NvbCBidXQgSSBhbSB3b25kZXJpbmcgaWYgdGhlIGNhc2Ugd2hlbiB0aGUgTVAgY29u dGludWVzIHRvIHNlbmQgQWR2ZXJ0aXNlbWVudHMgYW5kIGtlZXAgZ2V0dGluZyBOQUNLIGJhY2sg ZnJvbSB0aGUgTUMgaXMgYSByZWFsIGNhc2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCAoc2Vj dGlvbiA2LjEpLCB0aGlzIHdpbGwgc3RpbGwgcmVxdWlyZSBhICByZXRyeSBjb3VudCBidXQgd2Ug Y2FuIGFkZCB0ZXh0IHRoYXQgd2lsbCB0ZWxsIHRoZSBNUCBob3cgbWFueSB0aW1lIHRvIHJldHJ5 IHdpdGhvdXQgaGF2aW5nIGFuIGV4cGxpY2l0IHBhcmFtZXRlci4NClJvbmkNCg0KRnJvbTogU2lt b24gUGlldHJvIFJvbWFubyBbbWFpbHRvOnNwcm9tYW5vQHVuaW5hLml0XQ0KU2VudDogRnJpZGF5 LCBBcHJpbCAwNiwgMjAxOCA5OjI4IFBNDQpUbzogUm9uaSBFdmVuIChBKQ0KQ2M6IGNsdWVAaWV0 Zi5vcmc7IEFkYW0gUm9hY2g7IFJvYmVydGEgUHJlc3RhDQpTdWJqZWN0OiBSZTogW2NsdWVdIFF1 ZXN0aW9uIGFib3V0IHRpbWVycyAocmV0cnkgYW5kIHRpbWVvdXRzKSBpbiBkcmFmdC1pZXRmLWNs dWUtcHJvdG9jb2wNCg0KSGVsbG8gYWdhaW4gUm9uaSwNCg0KDQpIaSwNCkFuIGltcG9ydGFudCBp c3N1ZSB0aGF0IHdhcyBtYWRlIGJ5IEFkYW0gZHVyaW5nIGhpcyBBRCByZXZpZXcgaGFzIHRvIGRv IHdpdGggdGltZW91dCBhbmQgcmV0cnkgdGhyZXNob2xkcywgcGxlYXNlIHByb3ZpZGUgZmVlZGJh Y2sNCg0KVGhpcyBpcyB0aGUgY29tbWVudDoNCkJMT0NLRVI6IEdlbmVyYWw6IFRoZXJlIGFyZSBz ZXZlcmFsIG1lbnRpb25zIG9mIHRpbWVvdXRzIGFuZCByZXRyeSB0aHJlc2hvbGRzIGluIHRoZSB0 ZXh0IGFuZCBpdHMgY29ycmVzcG9uZGluZyBzdGF0ZSBtYWNoaW5lczsgaG93ZXZlciwgdGhlIGRv Y3VtZW50IG5laXRoZXIgZGVmaW5lcyBub3IgY2l0ZXMgYSBkb2N1bWVudCBhcyBkZWZpbmluZyB3 aGF0IHRoZXNlIHRpbWVvdXQgYW5kIHJldHJ5IHZhbHVlcyBhcmUuIFRoZXNlIG5lZWQgdG8gYmUg ZGVmaW5lZCBhbmQgZGVzY3JpYmVkLiBJZiB0aGUgdGltZXIgYW5kIHJldHJ5IHNjaGVtZSBhbGxv d3MgdGhlIHR3byBlbmRzIG9mIHRoZSBjb25uZWN0aW9uIHRvIGhhdmUgZGlmZmVyZW50IHZhbHVl cyBmb3IgdGltZW91dHMgYW5kIG51bWJlciBvZiByZXRyaWVzLCB0aGVuIHRoZXJlIG5lZWQgdG8g YmUgYWRkaXRpb25hbCBlcnJvciBwcm9jZWR1cmVzIHRoYXQgYWxsb3cgdGhlIE1DIGFuZCBNUCBz dGF0ZSBtYWNoaW5lcyB0byBzdGF5IGluIHN5bmMgKGlmIHRoZSB0aW1lci9yZXRyeSB2YWx1ZXMg Y2FuIGJlIGRpZmZlcmVudCwgaXQncyBwb3NzaWJsZSBmb3Igb25lIHN0YXRlIG1hY2hpbmUgdG8g dHJhbnNpdGlvbiB0byAidGVybWluYXRlZCwiIHdoaWxlIHRoZSBvdGhlciBpcyBzdGlsbCBhY3Rp dmUsIGFuZCB5b3UgbmVlZCBtZXNzYWdpbmcgdG8gY2xlYW4gdGhpcyB1cCkuIFRoZSByZW1haW5k ZXIgb2YgdGhpcyBjb21tZW50IGlzIG5vbi1ibG9ja2luZzogUmVsYXRlZCB0byB0aGlzLCB0aGUg ZG9jdW1lbnQgZnJlcXVlbnRseSByZWZlcnMgdG8gcmV0cmllcyBhcyAiZXhwaXJpbmciIChlLmcu LCAicmV0cnkgZXhwaXJlZCIgb24gdGhlIHN0YXRlIGRpYWdyYW1zKS4gVGhhdCBkb2Vzbid0IHJl YWxseSBtYWtlIHNlbnNlIHVubGVzcyAicmV0cnkiIGlzIHRoZSBuYW1lIG9mIGEgdGltZXIgcmF0 aGVyIHRoYW4gYSBjb3VudGVyOyBJIHRoaW5rIHlvdSBtZWFuIHRvIHNheSAiZXhoYXVzdGVkIiBv ciBzb21ldGhpbmcgc2ltaWxhci4NCg0KTXkgdmlldyBhcyBpbmRpdmlkdWFsOg0KDQpUaGUgQ0xV RSBwcm90b2NvbCBpcyBkZWxpdmVyZWQgdXNpbmcgU0NUUCDigJxDTFVFIGVudGl0aWVzIGFyZSBy ZXF1aXJlZCB0byB1c2Ugb3JkZXJlZCBTQ1RQIG1lc3NhZ2UgZGVsaXZlcnksIHdpdGggZnVsbCBy ZWxpYWJpbGl0eeKAnSBzbyB0aGVyZSBpcyBubyBwcm9ibGVtIHdpdGggdGltZW91dCBmb3IgcmV0 cnkgZm9yIHRoZSBkYXRhIGNoYW5uZWwgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwtMTQjc2VjdGlvbi0zLjMuMiApDQoNClNvIHRoZSByZXRy eSBhbmQgdGltZW91dCBhcmUgZm9yIHRoZSBhcHBsaWNhdGlvbiBsZXZlbCBhbmQgbm90IGZvciB0 aGUgc2N0cCB0cmFuc3BvcnQuDQoNCkZyb20gdGhlIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcg bGlzdCBkdXJpbmcgdGhlIFdHTEMNCg0KDQrigJxUaGUgaWRlYSBoZXJlIGlzIHRoYXQgdGhlIE1D IGF2b2lkcyBlbnRlcmluZyBhIGxvb3Agd2hlcmUgdGhlIE1QIGtlZXBzIG9uIHNlbmRpbmcgYW4g ZXJyb25lb3VzIEFEViBoZW5jZSBmb3JjaW5nIHRoZSBNQyB0byByZXNwb25kIHdpdGggYSBOQUNL LiBJZiB0aGlzIHNpdHVhdGlvbiBpdGVyYXRlcyBmb3IgYSB3aGlsZSAoIyBvZiByZXRyaWVzKSwg dGhlIE1DIHRlcm1pbmF0ZXMgdGhlIG9uZ29pbmcgQ0xVRSDigJxzZXNzaW9u4oCdLg0KDQpJIG5v dGljZWQgdGhhdCB0aGUgZGlzY3Vzc2lvbiBzdGFydGVkIGV2ZW4gZWFybGllciBhbmQgdGhlIGNv bmNsdXNpb24gd2FzIHRoYXQgcmV0cnkgYW5kIHRpbWVvdXQgYXJlIG5lZWRlZCBidXQgd2UgYWxz byBuZWVkIGRlZmF1bHQgdmFsdWVzIHdoaWNoIHdlcmUgbmV2ZXIgbGlzdGVkDQoNCk15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCB3aGVuIGEgcmVjZWl2ZXIgb2YgYSBwcm90b2NvbCBtZXNzYWdlIHNl bmRzIGEgbmVnYXRpdmUgYWNrIGFzIHJlc3BvbnNlIGhlIGFsbG93cyBmb3IgcmV0aWVzIG9mIGZp eGVkIG1lc3NhZ2UgYW5kIHdpbGwgYWxsb3cgaXQgbiB0aW1lcyBvciBxdWl0IGFmdGVyIHggdGlt ZSBpZiBubyBuZXcgbWVzc2FnZSBhcnJpdmVzLg0KDQpJIHRoaW5rIHRoYXQgZm9yIHJldHJpZXMg YW55IG51bWJlciBpcyBnb29kIGJ1dCBJIHRoaW5rIHRoYXQgMiBpcyBPSyBzaW5jZSBpcyB0aGUg bWVzc2FnZSBzZW5kZXIgY2Fubm90IHNlbmQgYSB2YWxpZCBtZXNzYWdlIHdlIHNob3VsZCBhYmFu ZG9uIHRoZSBjYWxsLiBBcyBmb3IgdGltZW91dCB0aGlzIGNhbiBiZSBhIHNob3J0IG9uZSB0aGF0 IHdpbGwgc3RpbGwgYWxsb3cgZm9yIGEgcm91bmQgdHJpcCBzbyBteSB2aWV3IHRoYXQgMSBzZWNv bmQgaXMgZW5vdWdoDQoNCk90aGVyIHRob3VnaHM/DQoNClRoZXJlIGlzIGluZGVlZCBBZGFt4oCZ cyBhbnN3ZXIgdG8gbXkgYW5zd2VyLCB0aGF0IEnigJltIGNvcHkvcGFzdGluZyBiZWxvdyBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIHJlYWRlcnM6DQoNCkluIHRoaW5raW5nIHRocm91Z2ggd2hhdCB0 aGlzIHNjaGVtZSBzaG91bGQgbG9vayBsaWtlLCBpdCBvY2N1cnMgdG8gbWUgdGhhdCB0aGUgQ0xV RSBtZXNzYWdlcyBhcmUgZGVmaW5lZCB0byBiZSBzZW50IG92ZXIgYSByZWxpYWJsZSB0cmFuc3Bv cnQgKFNDVFApLCB3aGljaCBoYXMgaXRzIG93biByZXRyYW5zbWlzc2lvbiB0aW1lcnMgYW5kIGV2 ZW50dWFsIHRpbWVvdXRzLiBJbXBsZW1lbnRpbmcgYSByZXRyYW5zbWlzc2lvbiBzY2hlbWUgb24g dG9wIG9mIGEgcmVsaWFibGUgdHJhbnNwb3J0IC0tIGVzcGVjaWFsbHkgb25lIGFzIGFnZ3Jlc3Np dmUgYXMgeW91IHN1Z2dlc3QgYWJvdmUgLS0gd2lsbCBwdXQgbW9yZSB0cmFmZmljIG9uIHRoZSBu ZXR3b3JrIHdoZW4gY29uZ2VzdGlvbiBvY2N1cnMgcmF0aGVyIHRoYW4gbGVzcy4NCg0KU28sIGlu IHRoZSBmaW5hbCBhbmFseXNpcywgSSB0aGluayB0aGUgYWN0aW9uIGhlcmUgaXMgdG8gcmVtb3Zl IHJldHJhbnNtaXNzaW9uIHRpbWVycyBhbmQgcmV0cnkgY291bnRzIGFsdG9nZXRoZXIuIElmIHRo ZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCB0YWtlcyBsb25nZXIgdG8gZGV0ZWN0IGEgZmFpbHVyZSB0 aGFuIGlzIHNlbnNpYmxlIGZvciBDTFVFIChhbmQgaXQgbGlrZWx5IGRvZXMpLCB0aGVuIGEgc3Vw ZXJ2aXNvcnkgdGltZXIgdGhhdCBkZWNsYXJlcyB0aGUgc2Vzc2lvbiBmYWlsZWQgbWlnaHQgbWFr ZSBzZW5zZS4NCg0KDQpJIHdvdWxkIGJlIHBlcnNvbmFsbHkgaW5jbGluZWQgdG8gdGFrZSBBZGFt 4oCZcyBzdWdnZXN0aW9uIGFuZCBnZXQgcmlkIG9mIHRob3NlIHRpbWVycyBhbmQgcmV0cnkgY291 bnRzIGFsdG9nZXRoZXIuIFdoYXQgaXMgeW91ciBmZWVsaW5nIGFib3V0IHRoYXQ/DQoNClRoYW5r cywNCg0KU2ltb24NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfXFx8Ly9fDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoIE8tTyApDQogICAgICB+fn5+fn5+fn5+fn5+fn5+fn5+fn5+bzAwfn4oXyl+fjAwb35+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2ltb24gUGlldHJvIFJvbWFubw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVuaXZlcnNp dGEnIGRpIE5hcG9saSBGZWRlcmljbyBJSQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDb21wdXRlciBFbmdpbmVlcmluZyBEZXBhcnRtZW50DQogICAgICAgICAgICAg ICAgICAgICAgICAgUGhvbmU6ICszOSAwODEgNzY4MzgyMyAtLSBGYXg6ICszOSAwODEgNzY4Mzgx Ng0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGUtbWFpbDogc3By b21hbm9AdW5pbmEuaXQ8bWFpbHRvOnNwcm9tYW5vQHVuaW5hLml0Pg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgPDxNb2x0aSBtaSBkaWNvbm8gY2hlIGxvIHNjb3JhZ2dpYW1lbnRvIMOo IGwnYWxpYmkgZGVnbGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZGlvdGkuIENpIHJp ZmxldHRvIHVuIGlzdGFudGU7IGUgbWkgc2NvcmFnZ2lvPj4uIE1hZ3JpdHRlLg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgb29vTw0KICAgICAgIH5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+KCAgICl+fn4gT29vb35+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAoICAgICAgICAgICAg KCAgICkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBcXykgICAgICAgICAgKSAvDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChfLw0K DQoNCg0KDQpPbmUgc2lkZSBjb21tZW50IGluIHNlY3Rpb24gNi4yIHRoZXJlIGFyZSB0d28gaW5z dGFuY2VzIG9mIOKAnG51bWJlciBvZiB0aW1lb3V0c+KAnSA/DQoNCg0KDQpSb25pIEV2ZW4NCkNs dWUgY28tY2hhaXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD871B66DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt dGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SEkgU2ltb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCBB ZGFt4oCZcyBhbmQgeW91cnMgc3VnZ2VzdGlvbiB0byByZW1vdmUgdGhlIHRpbWVycyBtYWtlIHNl bnNlIHNpbmNlIHdlIGFyZSB1c2luZyBhIHJlbGlhYmxlIHByb3RvY29sIGJ1dCBJIGFtIHdvbmRl cmluZyBpZiB0aGUgY2FzZSB3aGVuIHRoZSBNUCBjb250aW51ZXMNCiB0byBzZW5kIEFkdmVydGlz ZW1lbnRzIGFuZCBrZWVwIGdldHRpbmcgTkFDSyBiYWNrIGZyb20gdGhlIE1DIGlzIGEgcmVhbCBj YXNlIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgKHNlY3Rpb24gNi4xKSwgdGhpcyB3aWxsIHN0 aWxsIHJlcXVpcmUgYSAmbmJzcDtyZXRyeSBjb3VudCBidXQgd2UgY2FuIGFkZCB0ZXh0IHRoYXQg d2lsbCB0ZWxsIHRoZSBNUCBob3cgbWFueSB0aW1lIHRvIHJldHJ5IHdpdGhvdXQgaGF2aW5nIGFu IGV4cGxpY2l0IHBhcmFtZXRlci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25p DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTaW1vbiBQaWV0cm8gUm9tYW5vIFttYWlsdG86c3Byb21h bm9AdW5pbmEuaXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAwNiwgMjAxOCA5 OjI4IFBNPGJyPg0KPGI+VG86PC9iPiBSb25pIEV2ZW4gKEEpPGJyPg0KPGI+Q2M6PC9iPiBjbHVl QGlldGYub3JnOyBBZGFtIFJvYWNoOyBSb2JlcnRhIFByZXN0YTxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2NsdWVdIFF1ZXN0aW9uIGFib3V0IHRpbWVycyAocmV0cnkgYW5kIHRpbWVvdXRzKSBp biBkcmFmdC1pZXRmLWNsdWUtcHJvdG9jb2w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkhlbGxvIGFnYWluIFJvbmksPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5I aSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbiBpbXBvcnRhbnQgaXNz dWUgdGhhdCB3YXMgbWFkZSBieSBBZGFtIGR1cmluZyBoaXMgQUQgcmV2aWV3IGhhcyB0byBkbyB3 aXRoIHRpbWVvdXQgYW5kIHJldHJ5IHRocmVzaG9sZHMsIHBsZWFzZSBwcm92aWRlIGZlZWRiYWNr PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlRoaXMgaXMgdGhlIGNvbW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJMT0NLRVI6IEdlbmVyYWw6IFRoZXJlIGFy ZSBzZXZlcmFsIG1lbnRpb25zIG9mIHRpbWVvdXRzIGFuZCByZXRyeSB0aHJlc2hvbGRzIGluIHRo ZSB0ZXh0IGFuZCBpdHMgY29ycmVzcG9uZGluZyBzdGF0ZSBtYWNoaW5lczsgaG93ZXZlciwgdGhl IGRvY3VtZW50IG5laXRoZXIgZGVmaW5lcyBub3IgY2l0ZXMgYQ0KIGRvY3VtZW50IGFzIGRlZmlu aW5nIHdoYXQgdGhlc2UgdGltZW91dCBhbmQgcmV0cnkgdmFsdWVzIGFyZS4gVGhlc2UgbmVlZCB0 byBiZSBkZWZpbmVkIGFuZCBkZXNjcmliZWQuIElmIHRoZSB0aW1lciBhbmQgcmV0cnkgc2NoZW1l IGFsbG93cyB0aGUgdHdvIGVuZHMgb2YgdGhlIGNvbm5lY3Rpb24gdG8gaGF2ZSBkaWZmZXJlbnQg dmFsdWVzIGZvciB0aW1lb3V0cyBhbmQgbnVtYmVyIG9mIHJldHJpZXMsIHRoZW4gdGhlcmUgbmVl ZCB0byBiZSBhZGRpdGlvbmFsDQogZXJyb3IgcHJvY2VkdXJlcyB0aGF0IGFsbG93IHRoZSBNQyBh bmQgTVAgc3RhdGUgbWFjaGluZXMgdG8gc3RheSBpbiBzeW5jIChpZiB0aGUgdGltZXIvcmV0cnkg dmFsdWVzIGNhbiBiZSBkaWZmZXJlbnQsIGl0J3MgcG9zc2libGUgZm9yIG9uZSBzdGF0ZSBtYWNo aW5lIHRvIHRyYW5zaXRpb24gdG8gJnF1b3Q7dGVybWluYXRlZCwmcXVvdDsgd2hpbGUgdGhlIG90 aGVyIGlzIHN0aWxsIGFjdGl2ZSwgYW5kIHlvdSBuZWVkIG1lc3NhZ2luZyB0byBjbGVhbiB0aGlz IHVwKS4NCiBUaGUgcmVtYWluZGVyIG9mIHRoaXMgY29tbWVudCBpcyBub24tYmxvY2tpbmc6IFJl bGF0ZWQgdG8gdGhpcywgdGhlIGRvY3VtZW50IGZyZXF1ZW50bHkgcmVmZXJzIHRvIHJldHJpZXMg YXMgJnF1b3Q7ZXhwaXJpbmcmcXVvdDsgKGUuZy4sICZxdW90O3JldHJ5IGV4cGlyZWQmcXVvdDsg b24gdGhlIHN0YXRlIGRpYWdyYW1zKS4gVGhhdCBkb2Vzbid0IHJlYWxseSBtYWtlIHNlbnNlIHVu bGVzcyAmcXVvdDtyZXRyeSZxdW90OyBpcyB0aGUgbmFtZSBvZiBhIHRpbWVyIHJhdGhlciB0aGFu IGEgY291bnRlcjsNCiBJIHRoaW5rIHlvdSBtZWFuIHRvIHNheSAmcXVvdDtleGhhdXN0ZWQmcXVv dDsgb3Igc29tZXRoaW5nIHNpbWlsYXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPk15IHZpZXcgYXMgaW5kaXZpZHVhbDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhlIENMVUUgcHJvdG9jb2wgaXMgZGVsaXZlcmVkIHVzaW5nIFNDVFAg4oCcQ0xVRSBlbnRpdGll cyBhcmUgcmVxdWlyZWQgdG8gdXNlIG9yZGVyZWQgU0NUUCBtZXNzYWdlIGRlbGl2ZXJ5LCB3aXRo IGZ1bGwgcmVsaWFiaWxpdHnigJ0gc28gdGhlcmUgaXMgbm8gcHJvYmxlbSB3aXRoIHRpbWVvdXQg Zm9yDQogcmV0cnkgZm9yIHRoZSBkYXRhIGNoYW5uZWwgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwtMTQjc2VjdGlvbi0zLjMu MiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY2x1ZS1kYXRhY2hhbm5lbC0xNCNzZWN0aW9uLTMuMy4yPC9zcGFuPjwvYT48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TbyB0aGUgcmV0cnkgYW5kIHRpbWVvdXQgYXJlIGZvciB0aGUgYXBwbGljYXRpb24gbGV2 ZWwgYW5kIG5vdCBmb3IgdGhlIHNjdHAgdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tIHRoZSBk aXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QgZHVyaW5nIHRoZSBXR0xDPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3Jv dW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGlu aXRpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCcPHNwYW4gc3R5bGU9ImNvbG9y OiMzMzMzMzMiPlRoZSBpZGVhIGhlcmUgaXMgdGhhdCB0aGUgTUMgYXZvaWRzIGVudGVyaW5nIGEg bG9vcCB3aGVyZSB0aGUgTVAga2VlcHMgb24gc2VuZGluZyBhbiBlcnJvbmVvdXMgQURWIGhlbmNl IGZvcmNpbmcgdGhlIE1DIHRvIHJlc3BvbmQgd2l0aCBhIE5BQ0suIElmIHRoaXMgc2l0dWF0aW9u IGl0ZXJhdGVzIGZvciBhIHdoaWxlICgjIG9mIHJldHJpZXMpLCB0aGUgTUMgdGVybWluYXRlcyB0 aGUgb25nb2luZyBDTFVFIOKAnHNlc3Npb27igJ0uIDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7YmFja2dyb3VuZDp3aGl0ZTti YWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0 aWFsIGluaXRpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzMzIj5J IG5vdGljZWQgdGhhdCB0aGUgZGlzY3Vzc2lvbiBzdGFydGVkIGV2ZW4gZWFybGllciBhbmQgdGhl IGNvbmNsdXNpb24gd2FzIHRoYXQgcmV0cnkgYW5kIHRpbWVvdXQgYXJlIG5lZWRlZCBidXQgd2Ug YWxzbyBuZWVkIGRlZmF1bHQgdmFsdWVzIHdoaWNoIHdlcmUgbmV2ZXIgbGlzdGVkPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91 bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1y ZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzMzMyI+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHdoZW4gYSByZWNlaXZlciBvZiBhIHBy b3RvY29sIG1lc3NhZ2Ugc2VuZHMgYSBuZWdhdGl2ZSBhY2sgYXMgcmVzcG9uc2UgaGUgYWxsb3dz IGZvciByZXRpZXMgb2YgZml4ZWQgbWVzc2FnZSBhbmQgd2lsbCBhbGxvdyBpdCBuIHRpbWVzIG9y IHF1aXQgYWZ0ZXIgeCB0aW1lIGlmIG5vIG5ldyBtZXNzYWdlIGFycml2ZXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6 d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBl YXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz MzMzMyI+SSB0aGluayB0aGF0IGZvciByZXRyaWVzIGFueSBudW1iZXIgaXMgZ29vZCBidXQgSSB0 aGluayB0aGF0IDIgaXMgT0sgc2luY2UgaXMgdGhlIG1lc3NhZ2Ugc2VuZGVyIGNhbm5vdCBzZW5k IGEgdmFsaWQgbWVzc2FnZSB3ZSBzaG91bGQgYWJhbmRvbiB0aGUgY2FsbC4gQXMgZm9yIHRpbWVv dXQgdGhpcyBjYW4gYmUgYSBzaG9ydCBvbmUgdGhhdCB3aWxsIHN0aWxsIGFsbG93IGZvciBhIHJv dW5kIHRyaXAgc28gbXkgdmlldyB0aGF0IDEgc2Vjb25kIGlzIGVub3VnaDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndo aXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0 OmluaXRpYWwgaW5pdGlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMz MzMiPk90aGVyIHRob3VnaHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgaW5kZWVkIEFkYW3igJlz IGFuc3dlciB0byBteSBhbnN3ZXIsIHRoYXQgSeKAmW0gY29weS9wYXN0aW5nIGJlbG93IGZvciB0 aGUgYmVuZWZpdCBvZiB0aGUgcmVhZGVyczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpbmtpbmcgdGhyb3VnaCB3aGF0 IHRoaXMgc2NoZW1lIHNob3VsZCBsb29rIGxpa2UsIGl0IG9jY3VycyB0byBtZSB0aGF0IHRoZSBD TFVFIG1lc3NhZ2VzIGFyZSBkZWZpbmVkIHRvIGJlIHNlbnQgb3ZlciBhIHJlbGlhYmxlIHRyYW5z cG9ydCAoU0NUUCksIHdoaWNoIGhhcyBpdHMgb3duIHJldHJhbnNtaXNzaW9uIHRpbWVycyBhbmQg ZXZlbnR1YWwgdGltZW91dHMuIEltcGxlbWVudGluZyBhIHJldHJhbnNtaXNzaW9uDQogc2NoZW1l IG9uIHRvcCBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCAtLSBlc3BlY2lhbGx5IG9uZSBhcyBhZ2dy ZXNzaXZlIGFzIHlvdSBzdWdnZXN0IGFib3ZlIC0tIHdpbGwgcHV0IG1vcmUgdHJhZmZpYyBvbiB0 aGUgbmV0d29yayB3aGVuIGNvbmdlc3Rpb24gb2NjdXJzIHJhdGhlciB0aGFuIGxlc3MuPGJyPg0K PGJyPg0KU28sIGluIHRoZSBmaW5hbCBhbmFseXNpcywgSSB0aGluayB0aGUgYWN0aW9uIGhlcmUg aXMgdG8gcmVtb3ZlIHJldHJhbnNtaXNzaW9uIHRpbWVycyBhbmQgcmV0cnkgY291bnRzIGFsdG9n ZXRoZXIuIElmIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCB0YWtlcyBsb25nZXIgdG8gZGV0ZWN0 IGEgZmFpbHVyZSB0aGFuIGlzIHNlbnNpYmxlIGZvciBDTFVFIChhbmQgaXQgbGlrZWx5IGRvZXMp LCB0aGVuIGEgc3VwZXJ2aXNvcnkgdGltZXIgdGhhdCBkZWNsYXJlcw0KIHRoZSBzZXNzaW9uIGZh aWxlZCBtaWdodCBtYWtlIHNlbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYmUgcGVyc29uYWxs eSBpbmNsaW5lZCB0byB0YWtlIEFkYW3igJlzIHN1Z2dlc3Rpb24gYW5kIGdldCByaWQgb2YgdGhv c2UgdGltZXJzIGFuZCByZXRyeSBjb3VudHMgYWx0b2dldGhlci4gV2hhdCBpcyB5b3VyIGZlZWxp bmcgYWJvdXQgdGhhdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TaW1vbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbmJzcDsgX1xcfC8vXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyggTy1PICk8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyB+fn5+fn5+fn5+fn5+fn5+fn5+fn5+bzAwfn4oXyl+fjAwb35+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+U2ltb24gUGlldHJvJm5ic3A7Um9tYW5vPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4mbmJzcDtVbml2ZXJzaXRhJyBkaSBOYXBvbGkmbmJzcDtG ZWRlcmljbyBJSTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ Jm5ic3A7ICZuYnNwOyAmbmJzcDtDb21wdXRlciBFbmdpbmVlcmluZyZuYnNwO0RlcGFydG1lbnQm bmJzcDs8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGhvbmU6ICYj NDM7MzkgMDgxIDc2ODM4MjMgLS0gRmF4OiAmIzQzOzM5Jm5ic3A7MDgxIDc2ODM4MTY8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlLW1haWw6Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOnNwcm9tYW5vQHVuaW5hLml0Ij5zcHJvbWFub0B1bmluYS5pdDwvYT48YnI+DQo8 YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbHQ7Jmx0O01vbHRpIG1pIGRpY29ubyBjaGUgbG8mbmJz cDtzY29yYWdnaWFtZW50byDDqCBsJ2FsaWJpIGRlZ2xpJm5ic3A7PGJyPg0KPHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZuYnNwOyAm bmJzcDsgaWRpb3RpLiBDaSByaWZsZXR0byB1biBpc3RhbnRlOyBlIG1pJm5ic3A7c2NvcmFnZ2lv Jmd0OyZndDsuIE1hZ3JpdHRlLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b29vTzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO35+fn5+fn5+fn5+fn5+fn5+fn5+fn5+KCAmbmJzcDsg KX5+fiZuYnNwO09vb29+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+PGJyPg0KPHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgKCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyggJm5ic3A7ICk8YnI+DQo8c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBcXykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOykgLzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KF8vPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRl O2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0Omlu aXRpYWwgaW5pdGlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMzMzMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzMzMyI+T25lIHNpZGUgY29tbWVudCBpbiBzZWN0aW9uIDYuMiB0 aGVyZSBhcmUgdHdvIGluc3RhbmNlcyBvZiDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5udW1iZXIgb2YgdGltZW91dHM8L3NwYW4+4oCdID88bzpwPjwvbzpwPjwvcHJlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Um9uaSBFdmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DbHVlIGNvLWNoYWlyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCmNsdWUgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpjbHVlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OnB1cnBsZSI+Y2x1ZUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2x1ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZTwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD871B66DGGEMM506MBXchina_-- From nobody Wed Apr 11 10:31:06 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6898127873; Wed, 11 Apr 2018 10:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152346785862.2343.10243294104716219012@ietfa.amsl.com> Date: Wed, 11 Apr 2018 10:30:58 -0700 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-protocol-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:30:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF. Title : Protocol for Controlling Multiple Streams for Telepresence (CLUE) Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-15.txt Pages : 60 Date : 2018-04-11 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-15 https://datatracker.ietf.org/doc/html/draft-ietf-clue-protocol-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-15 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 Apr 11 10:32:21 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FB61289B0 for ; Wed, 11 Apr 2018 10:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qgmRhtKcCHck for ; Wed, 11 Apr 2018 10:32:00 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E911B12D87C for ; Wed, 11 Apr 2018 10:31:59 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id w3BHVvLf010432-w3BHVvLh010432 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2018 19:31:57 +0200 Received: from [100.102.10.37] ([143.225.83.119]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id w3BHVuTK005276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2018 19:31:56 +0200 From: Simon Pietro Romano Message-Id: <216405E3-5A89-4FF2-9C89-CEDA03BF6A04@unina.it> Content-Type: multipart/alternative; boundary="Apple-Mail=_966EC39E-DDBD-40A1-9CC2-9BA11DEF96DF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 11 Apr 2018 19:31:55 +0200 In-Reply-To: Cc: clue@ietf.org, Roberta Presta To: Adam Roach References: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:32:19 -0000 --Apple-Mail=_966EC39E-DDBD-40A1-9CC2-9BA11DEF96DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Adam! We finally managed to get our review done. Please find our answers = in-line, [SPR]-prefixed, as usual. _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > Thanks for your thorough response! I've removed those issues that = you've addressed, and included responses to the remaining issues below. >=20 > IMPORTANT NOTE TO CLUE WORKING GROUP: There is a discussion regarding = retransmission timers that you need to have. See the comments below for = details. >=20 >=20 > On 10/6/17 1:37 PM, Simon Pietro Romano wrote: >>=20 >>> Title: The rule of thumb is that all but a small handful of = well-known acronyms need to be expanded in titles and abstracts. I = recognize that "CLUE" is a bit tortured, as acronyms go, but the title = of this document is, broadly speaking, opaque. Please change it to = something meaningful, such as "Protocol for Controlling Multiple Streams = for Telepresence (CLUE)=E2=80=9D >>>=20 >> [SPR] Done. >=20 > I think this got missed. The header of the current version still = reads: >=20 > CLUE Working Group R. Presta > Internet-Draft S. P. Romano > Intended status: Standards Track University of Napoli > Expires: April 9, 2018 October 6, 2017 >=20 > CLUE protocol > draft-ietf-clue-protocol-14 [SPR] I hope we really fixed it now. Thanks for spotting this out. >=20 >>=20 >>> General: There are three instances of excessively long lines in the = document. >>>=20 >> [SPR] ??? >=20 > The reformatting of XML in -14 has fixed this issue. [SPR] Good to know. >=20 >> BLOCKER: General: There are several mentions of timeouts and retry = thresholds in the text and its corresponding state machines; however, = the document neither defines nor cites a document as defining what these = timeout and retry values are. These need to be defined and described. If = the timer and retry scheme allows the two ends of the connection to have = different values for timeouts and number of retries, then there need to = be additional error procedures that allow the MC and MP state machines = to stay in sync (if the timer/retry values can be different, it's = possible for one state machine to transition to "terminated," while the = other is still active, and you need messaging to clean this up). >>=20 >> [SPR] Our idea was to rely on a single, fixed, application-level = (i.e., CLUE-level) timeout value, rather than leveraging a number of = them (T1, T2, T4, plus Timer A through Timer K) as in SIP. The value of = the one and only timer would be the usual RTT estimate (~500ms). = Differently from protocols like SIP, we are also leveraging retransmit = counts to get out of a timeout-driven retransmission loop. We=E2=80=99re = not adding such information to the revised version of the draft, because = we=E2=80=99d first like to get your feedback on the approach. If you = (and the rest of the group) believe this is a feasible approach, we can = expand on that in a further version of the document. >=20 > In thinking through what this scheme should look like, it occurs to me = that the CLUE messages are defined to be sent over a reliable transport = (SCTP), which has its own retransmission timers and eventual timeouts. = Implementing a retransmission scheme on top of a reliable transport -- = especially one as aggressive as you suggest above -- will put more = traffic on the network when congestion occurs rather than less. >=20 > So, in the final analysis, I think the action here is to remove = retransmission timers and retry counts altogether. If the underlying = transport takes longer to detect a failure than is sensible for CLUE = (and it likely does), then a supervisory timer that declares the session = failed might make sense. [SPR] We took your advice and got rid of timers and retransmissions. = You=E2=80=99ll find the updated state machines in the new version of the = draft (-15). >=20 >>=20 >>> Section 5: The XML definition allows zero or more elements = to appear in a message. If more than one is allowed, the document should = explain how multiple IDs are handled. If they are not, then the schema = and/or text needs to prohibit having more than one. >>>=20 >> [SPR] Actually, the schema states: >>=20 >> >>=20 >> This should indicate that clueId can appear either 0 or 1 times in a = valid XML document. The default value for maxOccurs is in fact 1. = Don=E2=80=99t you agree on that? >=20 > Ah, you're correct. I=E2=80=99m not used to seeing minOccurs without = maxOccurs, but this is entirely fine as it's currently written. [SPR] Good. >=20 >>> BLOCKER: Section 5.1: The description of = describes a scheme in which multiple supported versions can be listed; = and, if the list is omitted, it implies that only the version described = in is supported. This text does not define (nor does any other text = that I can find) what should be set to when is = used. Intuitively, it seems that should be set to the largest minor = version of the smallest major version advertised in , = but that (or whatever the correct answer is) needs to be clearly spelled = out. >>>=20 >> [SPR] I believe we were giving for granted that =E2=80=9Cv=E2=80=9D = should be, in such case, the highest supported version (i.e., largest = major and larger minor numbers). Now that you make me think around that, = I would simply say that the =E2=80=9Cv=E2=80=9D attribute MUST be set to = one of the versions that the entity in question supports, as per the = list. I can, e.g., decide that I send an = =E2=80=98options=E2=80=99 with =E2=80=9Cv=3D12.23=E2=80=9D if the = list is like in the following: >>=20 >> 33.44 >> 27.0 >> 12.345 >> 1.44 >=20 > I think this formulation is a problem. I assume the intention behind = the "v" field is that some implementation that receives a version number = in the "v" field with a major number higher than it understands is = supposed to close the connection, since it runs a risk of = misinterpreting the contents of messages. So, in your example, if you = sent "v=3D12.23" to my implementation that only spoke major version 1, I = would reject it, even though you also support major version 1. That=E2=80=99= s why I was thinking it should contain the smallest major version being = advertised. [SPR] You convinced us. The new version of the draft now =E2=80=9Creflects= your reflections=E2=80=9D. We even borrowed your own words in the = descriptive part. >=20 > The minor version is obviously less useful in this context, since = they're defined to be backwards and forwards compatible, but it's more = useful to know the highest minor version supported than some random = minor version, as it indicates the full feature set that is supported. = The reason it=E2=80=99s less useful is that the value can be parsed out = of the list. [SPR] Agreed. And inserted into the document. >=20 >>> BLOCKING: The state machines in section 6 and its subsections don't = have transitions for all possible messages that could arrive in a state. = This can cause interop issues. Please add text that clearly indicates = whether such messages do or do not cause a transition. (This might be as = simple as "messages not shown for a state do not cause the state to = change," but only if you carefully check that this is true -- for = example, what should an MP state machine do do if it gets a "CONF + ACK" = in the state "WAIT FOR CONF"?) >>>=20 >> [SPR] In the specific case you mention, I would expect that a 302 is = generated (Invalid Parameter), since the incoming CONF should not = contain the element. This said, I see your point related to the = potential lack of some edges in the state machine graph. This point is = obviously also related to the =E2=80=9Ctimeout=E2=80=9D issue you raised = before. Different ways of managing timeouts will definitely have = different impacts on the current state machines. >> We will defer the modification of the diagrams in question to the = next revision round. In the meanwhile, we=E2=80=99ll give a thought to = potential further unexpected transactions to be taken into account. >=20 > Based on my analysis above, I think the state machines will get a bit = simpler, as they won=E2=80=99t have retransmission counts any longer. [SPR] See my answer above. >=20 >>=20 >>> Section 6.2 describes a state machine that starts in a state called = "WAIT FOR ADV." This state does not appear to be timer-supervised, = meaning that implementations of this state machine can stay in this = state literally forever. Is that the intention? >>>=20 >> [SPR] The idea would be to open a socket and start listening for = incoming advertisements. Isn=E2=80=99t that OK? >=20 > At some point, I think you're going to want to conclude that the CLUE = data channel isn't going to get set up correctly, and signal that to the = application in some way. This is probably on the order of a minute or = so. [SPR] We have not yet added this consideration to the draft. I = personally believe this makes sense. Do you think we should add this as = a general consideration when introducing the overall state machines? >=20 >>> Section 8 indicates that extensions need to indicate "the standard = version of the protocol the extension refers to." Given that there is = compatibility within a major version of a protocol, I think this means = to say "the major standard version of the protocol that the extension = refers to.=E2=80=9D >>>=20 >> [SPR] My extension might be associated with version 3.6 of the = protocol. This means that it will need to be supported by all versions = higher than that (3.7 onwards). Though, this does not entail that = versions 3.5 and lower should understand it. Right? >=20 > I'm a bit confused. Is the notion here that extensions, once = introduced, always become a mandatory-to-implement part of the protocol? = If that's the case, it's not clear why you would need to advertise them = explicitly, since support would be implied by the version number itself. = (This isn't unheard of: it's how NFS has historically handled version = numbers, for example.) However, I didn't get the impression that CLUE = protocol extensions were handled in such a way. If this is the = intention, there needs to be a lot more text that makes this MTI aspect = of extensions clear, and a reconsideration of why you=E2=80=99re = signaling them individually rather than inferring them from the version = number. [SPR] You=E2=80=99re right. We were mixing things up. We now make a = reference to the *major* standard version. >=20 >>> Section 8 contains schema that contains a element. It = should be clarified that this is the *protocol* version, not the = *extension* version (or, if it's the extension version, that needs to be = spelled out too, but I think you'll need a new namespace for that...?) >>>=20 >> [SPR] I thought this was clear from the third bullet point in the = list: >>=20 >> - the standard version of the protocol the extension refers to. >>=20 >> Isn=E2=80=99t this enough? In such a case, what would you suggest to = add? >=20 > Ah, I see. It wasn't clear that these three bullets corresponded to = the elements in the XML. Perhaps make this clearer with something like = =E2=80=9CThe values of the fields of the element take the = following values:" (and maybe move it closer to the actual XML). [SPR] The paragraph in question has been properly reformatted and should = now leave no space to misinterpretations. >=20 >>=20 >>> The remainder of this comment is non-blocking: I also find the = "SHOULD" in this section to be highly perplexing. Can you explain the = rationale behind requiring schema, but not requiring any description of = what the schema *means?) >>>=20 >> [SPR] It is like coding without adding comments/documentation. = Documentation is most welcome, but not mandatory. Don=E2=80=99t you = agree? >=20 > I don't. It seems more like committing a header file without the = corresponding implementation file. Just because people know what things = are called doesn't mean that they can handle them. For interop, you=E2=80=99= re going to need some description of what the fields mean and how the = messages are handled. [SPR] Got it! SHOULD has been replaced with a MUST. >=20 >>>=20 >>> The schema in section 9 contains: >>>=20 >>> >> schemaLocation=3D"data-model-schema-17.xsd"/> >>>=20 >>> If you do not intend to bake this "-17" into the document (and I = can't imagine you do), please add an RFC editor note to change it to = something else upon publication. >>>=20 >> [SPR] Done. I am not very familiar with RFC editor notes, indeed. = Here is what we added at the beginning of section 9: >>=20 >> "NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd" = with the right schema location for the CLUE data model schema document = (which is still to be defined at the time of this writing) in this = section prior to publication as an RFC.=E2=80=9D >>=20 >> Does this work for you? >=20 > That's perfect. Thanks! [SPR] Good. >=20 >>> Section 10 in general: While it does consume a lot of space, I don't = think that defining six rather different message types and then showing = only *one* type in the examples is very illustrative of the protocol. I = would *STRONGLY* suggest adding at least a response message, and ideally = the example section should contain at least one example for each of the = six message types. >>>=20 >> [SPR] Will do in the (hopefully final) revision of the document. = Let=E2=80=99s first double check that the proposed modifications are OK. >=20 > Sounds good. [SPR] We will keep this as an Action Point for us, to be fulfilled = before submitting the very last version of the draft. >=20 >>=20 >>> Section 12.1 has a strange double-double quote around the URN name, = and section 12.3 repeats this for the MIME type. >>>=20 >> [SPR] I don=E2=80=99t understand this. Can you please clarify? >>=20 >=20 > Replace >=20 > ""urn:ietf:params:xml:ns:clue-protocol"". >=20 > with >=20 > "urn:ietf:params:xml:ns:clue-protocol". >=20 >=20 > And then replace >=20 > This section registers the ""application/clue+xml"" MIME type. >=20 > with >=20 > This section registers the =E2=80=9Capplication/clue+xml=E2=80=9D = MIME type. [SPR] I think this is OK now. Thanks! Simon & Roberta >=20 >=20 > Thanks! >=20 > /a >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_966EC39E-DDBD-40A1-9CC2-9BA11DEF96DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hello Adam!

We finally managed to get our review done. Please find our = answers in-line, [SPR]-prefixed, as usual.

= =    =    _\\|//_
= = =    ( O-O )
= ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=    Simon Pietro Romano
= Universita' di Napoli Federico II
=    = Computer Engineering Department
= Phone: +39 081 = 7683823 -- Fax: +39 081 7683816
= = = e-mail: spromano@unina.it

= <<Molti mi dicono che lo scoraggiamento = =C3=A8 l'alibi degli
idioti. Ci = rifletto un istante; e mi scoraggio>>. Magritte.
= = oooO
= ~~~~~~~~~~~~~~~~~~~~~~~( = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
= = \ ( ( )
= = \_) = ) /
= = = = (_/

Thanks for your thorough response! I've removed those issues = that you've addressed, and included responses to the remaining issues = below.

IMPORTANT = NOTE TO CLUE WORKING GROUP: There is a discussion regarding = retransmission timers that you need to have. See the comments below for = details.

On 10/6/17 1:37 PM, = Simon Pietro Romano wrote:

Title: = The rule of thumb is that all but a small handful of well-known acronyms = need to be expanded in titles and abstracts. I recognize that "CLUE" is = a bit tortured, as acronyms go, but the title of this document is, = broadly speaking, opaque. Please change it to something meaningful, such = as "Protocol for Controlling Multiple Streams for Telepresence = (CLUE)=E2=80=9D

[SPR] Done.

I think this got missed. The = header of the current version still reads:

CLUE Working Group R. Presta
Internet-Draft S. = P. Romano
Intended status: Standards Track University of = Napoli
Expires: April 9, 2018 October 6, 2017

&nb= sp; = ; CLUE protocol
&nb= sp; = draft-ietf-clue-protocol-14

[SPR] I = hope we really fixed it now. Thanks for spotting this out.

General: There are three = instances of excessively long lines in the document.

[SPR] ???

The reformatting of XML in -14 has fixed this issue.

[SPR] Good = to know.

BLOCKER: General: There are several mentions of = timeouts and retry thresholds in the text and its corresponding state = machines; however, the document neither defines nor cites a document as = defining what these timeout and retry values are. These need to be = defined and described. If the timer and retry scheme allows the two ends = of the connection to have different values for timeouts and number of = retries, then there need to be additional error procedures that allow = the MC and MP state machines to stay in sync (if the timer/retry values = can be different, it's possible for one state machine to transition to = "terminated," while the other is still active, and you need messaging to = clean this up).

[SPR] Our idea was to rely = on a single, fixed, application-level (i.e., CLUE-level) timeout value, = rather than leveraging a number of them (T1, T2, T4, plus Timer A = through Timer K) as in SIP. The value of the one and only timer would be = the usual RTT estimate (~500ms). Differently from protocols like SIP, we = are also leveraging retransmit counts to get out of a timeout-driven = retransmission loop. We=E2=80=99re not adding such information to the = revised version of the draft, because we=E2=80=99d first like to get = your feedback on the approach. If you (and the rest of the group) = believe this is a feasible approach, we can expand on that in a further = version of the document.

In = thinking through what this scheme should look like, it occurs to me that = the CLUE messages are defined to be sent over a reliable transport = (SCTP), which has its own retransmission timers and eventual timeouts. = Implementing a retransmission scheme on top of a reliable transport -- = especially one as aggressive as you suggest above -- will put more = traffic on the network when congestion occurs rather than less.

So, in the final analysis, I think the action = here is to remove retransmission timers and retry counts altogether. If = the underlying transport takes longer to detect a failure than is = sensible for CLUE (and it likely does), then a supervisory timer that = declares the session failed might make sense.

[SPR] We took your advice and got rid of timers = and retransmissions. You=E2=80=99ll find the updated state machines in = the new version of the draft (-15).

Section 5: The XML definition allows zero or = more <clueId> elements to appear in a message. If more than one is = allowed, the document should explain how multiple IDs are handled. If = they are not, then the schema and/or text needs to prohibit having more = than one.

[SPR] Actually, the = schema states:

<xs:element name=3D"clueId"= type=3D"xs:string" minOccurs=3D"0=E2=80=9D/>

This should indicate that clueId can appear either 0 or 1 = times in a valid XML document. The default value for maxOccurs is in = fact 1. Don=E2=80=99t you agree on that?

Ah, you're correct. I=E2=80=99m not used to seeing minOccurs = without maxOccurs, but this is entirely fine as it's currently = written.

[SPR] Good.

BLOCKER: Section 5.1: = The description of <supportedVersions> describes a scheme in which = multiple supported versions can be listed; and, if the list is omitted, = it implies that only the version described in <v> is supported. = This text does not define (nor does any other text that I can find) what = <v> should be set to when <supportedVersions> is used. = Intuitively, it seems that <v> should be set to the largest minor = version of the smallest major version advertised in = <supportedVersions>, but that (or whatever the correct answer is) = needs to be clearly spelled out.

[SPR] I believe we were giving for granted that = =E2=80=9Cv=E2=80=9D should be, in such case, the highest supported = version (i.e., largest major and larger minor numbers). Now that you = make me think around that, I would simply say that the =E2=80=9Cv=E2=80=9D= attribute MUST be set to one of the versions that the entity in = question supports, as per the <supportedVersions> list. I can, = e.g., decide that I send an =E2=80=98options=E2=80=99 with =E2=80=9Cv=3D12= .23=E2=80=9D if the <supportedVersions> list is like in the = following:

<version>33.44</version>
<version>27.0</version>
<version>12.345</version>
<version>1.44</version>

I think this formulation is a = problem. I assume the intention behind the "v" field is that some = implementation that receives a version number in the "v" field with a = major number higher than it understands is supposed to close the = connection, since it runs a risk of misinterpreting the contents of = messages. So, in your example, if you sent "v=3D12.23" to my = implementation that only spoke major version 1, I would reject it, even = though you also support major version 1. That=E2=80=99s why I was = thinking it should contain the smallest major version being = advertised.

[SPR] You convinced us. The new version of the draft = now =E2=80=9Creflects your reflections=E2=80=9D. We even borrowed your = own words in the descriptive part.

The minor version is obviously less useful in this context, = since they're defined to be backwards and forwards compatible, but it's = more useful to know the highest minor version supported than some random = minor version, as it indicates the full feature set that is supported. = The reason it=E2=80=99s less useful is that the value can be parsed out = of the <version> list.

[SPR] = Agreed. And inserted into the document.

BLOCKING: The state machines in section 6 and = its subsections don't have transitions for all possible messages that = could arrive in a state. This can cause interop issues. Please add text = that clearly indicates whether such messages do or do not cause a = transition. (This might be as simple as "messages not shown for a state = do not cause the state to change," but only if you carefully check that = this is true -- for example, what should an MP state machine do do if it = gets a "CONF + ACK" in the state "WAIT FOR CONF"?)

[SPR] In the specific case you mention, I would = expect that a 302 is generated (Invalid Parameter), since the incoming = CONF should not contain the <ack> element. This said, I see your = point related to the potential lack of some edges in the state machine = graph. This point is obviously also related to the =E2=80=9Ctimeout=E2=80=9D= issue you raised before. Different ways of managing timeouts will = definitely have different impacts on the current state machines.
We will defer the modification of the diagrams in question to = the next revision round. In the meanwhile, we=E2=80=99ll give a thought = to potential further unexpected transactions to be taken into = account.

Based on my analysis = above, I think the state machines will get a bit simpler, as they = won=E2=80=99t have retransmission counts any longer.

[SPR] = See my answer above.

Section 6.2 describes a = state machine that starts in a state called "WAIT FOR ADV." This state = does not appear to be timer-supervised, meaning that implementations of = this state machine can stay in this state literally forever. Is that the = intention?

[SPR] The idea = would be to open a socket and start listening for incoming = advertisements. Isn=E2=80=99t that OK?

At some point, I think you're going to want to conclude that = the CLUE data channel isn't going to get set up correctly, and signal = that to the application in some way. This is probably on the order of a = minute or so.

[SPR] We have not yet added this consideration to = the draft. I personally believe this makes sense. Do you think we should = add this as a general consideration when introducing the overall state = machines?

Section 8 indicates that = extensions need to indicate "the standard version of the protocol the = extension refers to." Given that there is compatibility within a major = version of a protocol, I think this means to say "the major standard = version of the protocol that the extension refers to.=E2=80=9D

[SPR] My extension might be = associated with version 3.6 of the protocol. This means that it will = need to be supported by all versions higher than that (3.7 onwards). = Though, this does not entail that versions 3.5 and lower should = understand it. Right?

I'm a = bit confused. Is the notion here that extensions, once introduced, = always become a mandatory-to-implement part of the protocol? If that's = the case, it's not clear why you would need to advertise them = explicitly, since support would be implied by the version number itself. = (This isn't unheard of: it's how NFS has historically handled version = numbers, for example.) However, I didn't get the impression that CLUE = protocol extensions were handled in such a way. If this is the = intention, there needs to be a lot more text that makes this MTI aspect = of extensions clear, and a reconsideration of why you=E2=80=99re = signaling them individually rather than inferring them from the version = number.

[SPR] You=E2=80=99re right. We were mixing things up. = We now make a reference to the *major* standard version.

Section 8 contains schema that contains a = <version> element. It should be clarified that this is the = *protocol* version, not the *extension* version (or, if it's the = extension version, that needs to be spelled out too, but I think you'll = need a new namespace for that...?)

[SPR] I thought this was clear from the third = bullet point in the list:

- the = standard version of the protocol the extension refers to.

Isn=E2=80=99t this enough? In such a case, = what would you suggest to add?

Ah, I see. It wasn't clear that these three bullets = corresponded to the elements in the XML. Perhaps make this clearer with = something like =E2=80=9CThe values of the fields of the = <extension> element take the following values:" (and maybe move it = closer to the actual XML).

[SPR] The paragraph in question has been properly = reformatted and should now leave no space to = misinterpretations.

The remainder of this comment is non-blocking: I also find = the "SHOULD" in this section to be highly perplexing. Can you explain = the rationale behind requiring schema, but not requiring any description = of what the schema *means?)

[SPR] It is like coding without adding = comments/documentation. Documentation is most welcome, but not = mandatory. Don=E2=80=99t you agree?

I don't. It seems more like committing a header file without = the corresponding implementation file. Just because people know what = things are called doesn't mean that they can handle them. For interop, = you=E2=80=99re going to need some description of what the fields mean = and how the messages are handled.

[SPR] Got = it! SHOULD has been replaced with a MUST.

The schema in section 9 contains:

<xs:import namespace=3D"urn:ietf:params:xml:ns:clue-info"schemaLocation=3D"data-model-schema-17.xsd"/>

If you do not intend to bake this "-17" into = the document (and I can't imagine you do), please add an RFC editor note = to change it to something else upon publication.

[SPR] Done. I am not very familiar with RFC = editor notes, indeed. Here is what we added at the beginning of section = 9:

"NOTE TO THE RFC-Editor: Please replace = "data-model-schema-17.xsd" with the right schema location for the CLUE = data model schema document (which is still to be defined at the time of = this writing) in this section prior to publication as an RFC.=E2=80=9D

Does this work for you?

That's perfect. Thanks!

[SPR] = Good.

Section 10 in general: = While it does consume a lot of space, I don't think that defining six = rather different message types and then showing only *one* type in the = examples is very illustrative of the protocol. I would *STRONGLY* = suggest adding at least a response message, and ideally the example = section should contain at least one example for each of the six message = types.

[SPR] Will do in the = (hopefully final) revision of the document. Let=E2=80=99s first double = check that the proposed modifications are OK.

Sounds good.

[SPR] We will keep this as an Action Point for us, to = be fulfilled before submitting the very last version of the = draft.

Section = 12.1 has a strange double-double quote around the URN name, and section = 12.3 repeats this for the MIME type.

[SPR] I don=E2=80=99t understand this. Can you = please clarify?

Replace

=   ""urn:ietf:params:xml:ns:clue-protocol"".

with

=   "urn:ietf:params:xml:ns:clue-protocol".

And then replace

=   This section registers the ""application/clue+xml"" MIME = type.

with

=   This section registers the =E2=80=9Capplication/clue+xml=E2=80= =9D MIME type.

[SPR] I = think this is OK now.

Thanks!

Simon = & Roberta

Thanks!

/a

= --Apple-Mail=_966EC39E-DDBD-40A1-9CC2-9BA11DEF96DF--