From denglingli@chinamobile.com Tue Jul 2 22:46:47 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D5E21F9C61 for ; Tue, 2 Jul 2013 22:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIdDRxDVXi2v for ; Tue, 2 Jul 2013 22:46:43 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 3233321F92A5 for ; Tue, 2 Jul 2013 22:46:40 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251d3ba80711-c3711; Wed, 03 Jul 2013 13:45:36 +0800 (CST) X-RM-TRANSID: 2ee251d3ba80711-c3711 Received: from cmccPC (unknown[10.2.43.200]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251d3ba8032c-ae20b; Wed, 03 Jul 2013 13:45:36 +0800 (CST) X-RM-TRANSID: 2ee251d3ba8032c-ae20b From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'ppsp'" Date: Wed, 3 Jul 2013 13:46:30 +0800 Message-ID: <007601ce77b0$aae81910$00b84b30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac53ovWlHvdzdymjTROWhBQwN1+k8AAAK6Bw Content-Language: zh-cn Subject: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ppsp-bfbitmap-00=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:46:47 -0000 Hi all, We have just submitted a new draft proposing to use bloom filters to = compress the chunk bitmap information exchanged between peers and the = tracker.=20 http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/=20 Besides the basic algorithms and high level message flow, it also = provides an initial discussion on how to integrate with the current = tracker and peer protocol. Your comments would be highly appreciated. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=883=E6=97=A5 = 11:55 =E6=94=B6=E4=BB=B6=E4=BA=BA: Deng Lingli; Yunfei Zhang; Jin Peng; Lingli = Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-deng-ppsp-bfbitmap-00.txt A new version of I-D, draft-deng-ppsp-bfbitmap-00.txt has been successfully submitted by Lingli Deng and posted to the IETF repository. Filename: draft-deng-ppsp-bfbitmap Revision: 00 Title: Efficient Chunk Availability Compression for PPSP Creation date: 2013-07-03 Group: Individual Submission Number of pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-00.txt Status: = http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap Htmlized: http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-00 Abstract: This document proposes to employ bloom filter algorithms in compressing chunk availability information in exchange between peers and the tracker through the PPSP-TP protocol and PPSPP protocol. = =20 The IETF Secretariat From hishigh@gmail.com Wed Jul 3 19:03:26 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF721F9D24 for ; Wed, 3 Jul 2013 19:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QKtL3r1hDev for ; Wed, 3 Jul 2013 19:03:26 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AA3B821F9D23 for ; Wed, 3 Jul 2013 19:03:25 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so994123obb.18 for ; Wed, 03 Jul 2013 19:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4pQz1O5fYQ9XdO8g//RdoXAnzzCN64G65q2DWp1NUR8=; b=v2PeOtyxrR7y6Su26hKuyrmPMSB4xhHWKRLXXKpv3aX4M0UWHAffkLyiWIf/HuNZgs 9LRlDDJjn53+0FzHcqLqc/fgQSUB+edmCbKUfjSllszE/nemdqgmBRxibtM9eEifEuNq vCStLgf7gqBUv4oioQ19x+nkD/sMwbsdKBkGsZ1tinYe3kpApNm0t+QSGfYmm0YDBmXZ 9BrkvxMDIIFqVFvvuGBuAwPZoBTTYrJbw6D1Y9PD3llhmdq8OI5w8CCk5EBk2DRKN9H3 AX9hvflK6LrkUcoxe5xLKCVh5bJ81IvJdOq139H1Bj55pyUwnRqf2lmu5JtPtutQ7gcJ nHJA== MIME-Version: 1.0 X-Received: by 10.60.173.169 with SMTP id bl9mr3830979oec.51.1372903395582; Wed, 03 Jul 2013 19:03:15 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Wed, 3 Jul 2013 19:03:15 -0700 (PDT) Date: Thu, 4 Jul 2013 10:03:15 +0800 Message-ID: From: yunfei zhang To: "ppsp@ietf.org" Content-Type: multipart/alternative; boundary=089e011761c934684504e0a5fbe1 Subject: [ppsp] PPSP session in IETF 87 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 02:03:27 -0000 --089e011761c934684504e0a5fbe1 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The PPSP session has been scheduled for two hours in IETF 87 with the following information( Two time slots): WEDNESDAY, July 31, 2013 1510-1610 CEST Wednesday Afternoon Session II Schoeneberg 1/2 1620-1720 CEST Wednesday, Afternoon Session III Schoeneberg 1/2 Note that the agenda is subject to change, up to and during the meeting. Please submit your request of time slot to Stefano and me before July 15 if you would like to present the drafts in this meeting. Thanks and looking forward to meeting with you in Berlin. BR Stefano&Yunfei --089e011761c934684504e0a5fbe1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0 =A0 The PPSP session has been scheduled fo= r two hours in IETF 87 with the following information( Two time slots):

WEDNESDAY, July 31, 2013


1510-1610=A0CEST =A0=A0Wednesday Afternoon Session II =A0Schoenebe= rg 1/2
1620-1720 CEST =A0=A0Wednesday, Afternoon Session III=A0=A0Schoeneb= erg 1/2

Note that =A0the agenda is=A0subject to change,= up to and during the meeting.
Please submit your request of time slot = to Stefano and me before July 15 if you would like to present the drafts in this meeting= . Thanks and looking forward to meeting with you in Berlin.


BR
Stefano&Yunfei
<= /font>


--089e011761c934684504e0a5fbe1-- From rui.cruz@ieee-pt.org Wed Jul 10 05:13:01 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ACB21F9F25 for ; Wed, 10 Jul 2013 05:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly8WSZ5yWWQu for ; Wed, 10 Jul 2013 05:12:56 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id DD93E21F9D8E for ; Wed, 10 Jul 2013 05:12:54 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so10872670wgg.4 for ; Wed, 10 Jul 2013 05:12:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=iRCyViCtEYaCicie2TFuwNdLcBQeo7o8Gori5m5tal4=; b=Cu0ea3dB1B8W5RR60yB+Rw4lW/XeOxGKPIowiEf4dwIK8zg+O0Ge8mCBhMpnp9Q1O6 3N/Q97gJjjok4aCWkGcDfGfzeyIoSV+3NnD7rJRIPl2KclXcuweJ6EF1+9cv4wnDFOF5 UeGGUhzt/PgHe8vnlSeTVv9iOOldpn/EcEh2bXeobOxqJFVxV1vfNsp58pYhSwMHmNPe XXlgmOnr72nuaVYz19dg5fx+UvXUwFMCBPiOhmzKj0UsORmoBwUHynu2ogZ7X50A9/CS MKLANhoS1V2dFmQQKmdLCnHv0DSzt+hBcRZPeMf3jfJiYTL4A4/UZa6BrX4MHcT+u0+T cUhg== X-Received: by 10.180.38.45 with SMTP id d13mr16870507wik.62.1373458366031; Wed, 10 Jul 2013 05:12:46 -0700 (PDT) Received: from airia.lan ([89.180.136.35]) by mx.google.com with ESMTPSA id eu1sm66856218wib.8.2013.07.10.05.12.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 05:12:44 -0700 (PDT) Sender: Rui Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_FD73A2E7-7DE8-49E5-A55C-68C60D36A16A" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Rui Cruz In-Reply-To: Date: Wed, 10 Jul 2013 13:12:41 +0100 Message-Id: <2D881B75-7000-4760-A193-1B231F30F25D@ieee.org> References: To: yunfei zhang X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmtj78dgax3AOV5W0AtAKeHW63yQgyin4dHTGInKmMAybF/igUfQjIeZd8OcEMG2IB3QtZD Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] Reviewing the tracker protocol X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 12:13:01 -0000 --Apple-Mail=_FD73A2E7-7DE8-49E5-A55C-68C60D36A16A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Yunfei, Many Thanks for your review. On your comments, they were really helpful, and provided a good guidance = for the changes. The new version of the draft will be published this week, after review = by all authors, but before the cutoff date. Please read inline answers to your comments. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 10/06/2013, at 10:50, yunfei zhang wrote: > Hi All, > I have reviewed the tracker protocol draft and here is my comments: >=20 > Overall: I think this draft is on the right way of a RFC. Implementors = can write most of the codes on the communication bw peers and trackers = according to the draft. There are clear examples on the syntax and = semantics for reference. RSC: Those are good news indeed. >=20 > Comments: > 1.Abstrct: Since the main body doesn't invlove in different messages = in either adaptive multi-rate, layered (scalable) or multi-view (3D) = videos scenarios and this is mainly on different metadata out of scope = of this draft, it's better to remove the related description in the = abstract (See more in comment #16). RSC: The last sentence just highlights that PPSP (tracker) protocol = enables peers to form content streaming overlay networks supporting near = real-time media content delivery, whichever the "encoding structure" = these contents might have, and then lists examples. Appendix C, is just = tutorial, clarifying the different video "encoding structures" = supported. However, I agree that a draft should be issued with = descriptions of use cases, but detailed, and I intend to do so. > 2.Terminology: > a)Adaptive Streaming: "...for the same streaming session" is a = little bit confusing. Do you mean in a same viewing or just the same = streaming content? RSC: corrected and moved to Appendix C > b)Chunk: The definition in the Problem statement has been updated = according to the review.=20 RSC: Updated > c)Definition related to presentation: Since the discussion of = adaptive multi-rate, layered (scalable) > and multi-view (3D) videos scenarios is in the appendix, it seems = better to move them in the appendix. RSC: moved to Appendix C > d) Media component: It seems not so clear on the definition. RSC: moved to Appendix C > e)peer-ID: There is a missing ","after IP address. RSC: Corrected > f) PPSP:The definition in the Problem statement has been updated = according to the review.=20 RSC: Updated > g) Scalable Streaming: MVC is not explained clearly like SVC and = MDC. RSC: MVC description enhanced and the term "Scalable Streaming" was = moved to Appendix C.=20 > h) Segment: Is it same as Chunk? Do we need the definition of = Segement-ID? RSC: Definition of SEGMENT clarified. A new term, "SEGMENT CHUNK" was = added to Terminology.=20 > i) Tracker:The conception of "channel" is not explained. RSC: Definition of Tracker modified to follow Problem Statement = definition. > 3.Enrollment and Bootstrap: > 1)Since more roles like player and portal are introduced, it's = better to move the description on these roles,e.g., the relationship bw = client media player and the peer, currently in appendix, into this part. RSC: Descriptions of CLIENT MEDIA PLAYER and SERVICE PORTAL were added = in section 2.1 > 2) It's better to clarify that Portal+ MPD file is not the only = means to locate the tracker. RSC: The first paragraph of section 2.1 was modified to clarify that the = exemplified methods are "not exhaustive". > 4.section 2.3, PPSP-TP should be present in the terminology. RSC: A new term "PPSP-TP" added to Terminology > 5.Section 2.3.2, in the CONNECT part: > a) When a peer registers in the tracker, it may not ask any swarm;=20= RSC: The base tracker protocol requires the presence of SWARM ID in the = connect message, meaning that a swarm action is mandatory. if the = connect message does not ask swarm actions of join and/or leave and the = peer is not yet registered, it is an error condition, as described in = section 4.1. > b) Peer IP addresses is not sufficient to locate a peer; RSC: The CONNECT message contains PEER ID, peer (ip) addresses and other = associate information as described in TABLE 3. What is the other = information that is still required to locate a peer? can you give an = example?=20 Anyway, some text was added to the description of CONNECT to stress that = peer location information is also handled by the tracker. > c) Doesn't the peer registers the Peer mode type informationl? RSC: description of CONNECT was complemented with that information. > 6. P13, Para2,"each Peer-ID is modeled" or "each peer is modeled"? RSC: OK, leaving just "peer" is better. > 7.Section 2.4.1,4)When Tracking, is there a need to send again a = "CONNECT"? RSC: In the base tracker protocol there is only one "ACTION SIGNAL" = message, the CONNECT. The other message is not for actions but for = information exchange. While a peer is beeing tracked (in TRACKING STATE), to LEAVE a swarm or = JOIN a swarm it is required to send a CONNECT message. > 8. How to convey the SM state information to the tracker? RSC: The state machine and flow diagram is inner implementation of the = tracker. >=20 > 9.Section 3.1, transaction-ID is not explained in terminology part. RSC: Definition of TRANSACTION ID added to Terminology. > 10. Table 2, it's suggested to add the attribute "battery power"for = mobile peers. RSC: "battery power" is a mobile specific attribute, not generic. = Attributes considered of interest can be added by a "request-response = extension" of the protocol as described in section 7.1 >=20 > 11.Section 4.1, it's better to limit the maximum number of the peers = in the peerlist to avoild DoS attack or maliciously getting the whole = picture of the active peers in short time for profit. RSC: A limit of 30 entries was introduced. This limit allows a PEER LIST = to fit a single datagram, when using binary encoding. > 12. P29,Are PEER REGISTERED and TRACKING states in the tracker or = peers? RSC: The state machine is of the Tracker >=20 > 13. Section 6.4, it's not clear about pro-incentive parameter.Needs = more descrption. RSC: Complementary information was added in section 6.4. > 14.In the security part, the maclious action of asking peer-list with = large amount of peers should be noted. RSC: PEER LIST requests and PEER LIST sizes returned by the Tracker are = limited to a maximum of 30 entries (30 peers)=20 > 15.Appedix B1, the Authorization header field is not present in the = example. And this mechanism should be highlighted. RSC: The example in Appendix B contains the field Authorization: / HTTP/1.1 Host: Content-Lenght: Content-Type: Authorization: [Request_Body] =20 > 16. It's better to have sperate drafts to discuss Appedix C. RSC: Agreed. Appendix C is given as a simple example. Separate drafts = can describe in detail the Use Scenarios. > 17. Does OAth 2.0 well suit the authentication bw tracker and peers? I = understand that oAuth is best suited in 3rd-party application = authorization,not authentication. Am I right? RSC: An HTTP Basic authentication scheme, as defined in [RFC2617] can be = used, or any other suitable/supported authentication method, as = described in [RFC6749]. >=20 > BR > Yunfei >=20 --Apple-Mail=_FD73A2E7-7DE8-49E5-A55C-68C60D36A16A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Yunfei,

Many Thanks for your = review.

On your comments, they were really = helpful, and provided a good guidance for the changes.
The new = version of the draft will be published this week, after review by all = authors, but before the cutoff date.

Please = read inline answers to your comments.

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 10/06/2013, at 10:50, yunfei zhang <hishigh@gmail.com> = wrote:

Hi All,
   I have reviewed = the tracker protocol draft and here is my = comments:

Overall: I think this draft is = on the right way of a RFC. Implementors can write most of the codes on = the communication bw peers and trackers according to the draft. There = are clear examples on the syntax and semantics for = reference.

RSC: Those are good = news indeed.

Comments:
1.Abstrct: Since = the main body doesn't invlove in different messages in either adaptive = multi-rate, layered (scalable) or multi-view (3D) videos scenarios and = this is mainly on different metadata out of scope of this draft, it's = better to remove the related description in the abstract (See more in = comment #16).
RSC: The last sentence = just highlights that PPSP (tracker) protocol enables peers to form = content streaming overlay networks supporting near real-time media = content delivery, whichever the "encoding structure" these contents = might have, and then lists examples. Appendix C, is just tutorial, = clarifying the different  video "encoding = structures" supported. However, I agree that a draft should be = issued with descriptions of use cases, but detailed, and I intend to do = so.

2.Terminology:
  a)Adaptive Streaming: = "...for the same streaming session" is a little bit confusing. Do you = mean in a same viewing or just the same streaming = content?
RSC: corrected and moved to Appendix = C
  b)Chunk: The = definition in the Problem statement has been updated according to the = review. 
RSC: Updated
  c)Definition related to presentation: Since the discussion = of adaptive multi-rate, layered (scalable)
   and = multi-view (3D) videos scenarios is in the appendix, it seems better to = move them in the appendix.
RSC: moved to = Appendix C
  d) Media component: It seems not so clear on the = definition.
RSC: moved to Appendix = C
  e)peer-ID: = There is a missing ","after IP address.
RSC: = Corrected
  f) = PPSP:The definition in the Problem statement has been updated according = to the review. 
RSC: Updated
  g) Scalable Streaming: MVC is not explained clearly like SVC = and MDC.
RSC: MVC description enhanced and the = term "Scalable Streaming" was moved to Appendix C. 
  h) Segment: Is it same as = Chunk? Do we need the definition of = Segement-ID?
RSC: Definition of SEGMENT = clarified. A new term, "SEGMENT CHUNK" was added to = Terminology. 
  i) Tracker:The conception of "channel" is not = explained.
RSC: Definition of Tracker = modified to follow Problem Statement definition.
3.Enrollment and Bootstrap:
   1)Since = more roles like player and portal are introduced, it's better to move = the description on these roles,e.g., the relationship bw client media = player and the peer, currently in appendix, into this = part.
RSC: Descriptions of CLIENT MEDIA PLAYER = and SERVICE PORTAL were added in section 2.1
   2) It's better to clarify that Portal+ MPD file is not = the only means to locate the tracker.
RSC: The = first paragraph of section 2.1 was modified to clarify that the = exemplified methods are "not exhaustive".
4.section 2.3, PPSP-TP should be = present in the terminology.
RSC: A new term = "PPSP-TP" added to Terminology
5.Section 2.3.2, in the CONNECT part:
   a) When a peer registers in the tracker, it may not = ask any swarm; 
RSC: The base tracker = protocol requires the presence of SWARM ID in the connect message, = meaning that a swarm action is mandatory. if the connect message = does not ask swarm actions of join and/or leave and the peer is not yet = registered, it is an error condition, as described in section = 4.1.
   b) = Peer IP addresses is not sufficient to locate a = peer;
RSC: The CONNECT message contains PEER ID, = peer (ip) addresses and other associate information as described in = TABLE 3. What is the other information that is still required to = locate a peer? can you give an example? 
Anyway, some = text was added to the description of CONNECT to stress that peer = location information is also handled by the tracker.
   c) Doesn't the peer = registers the Peer mode type = informationl?
RSC: description = of CONNECT was complemented with that information.
6. P13, Para2,"each Peer-ID is modeled" or "each peer is = modeled"?
RSC: OK, leaving just "peer" is = better.
7.Section = 2.4.1,4)When Tracking, is there a need to send again a = "CONNECT"?
RSC:  In the base tracker = protocol there is only one "ACTION SIGNAL" message, = the CONNECT. The other message is not for actions but for = information exchange.
While a peer is beeing tracked (in TRACKING = STATE), to LEAVE a swarm or JOIN a swarm it is required to send = a CONNECT message.
8. How to convey the SM state information to the = tracker?
RSC: The state machine and flow diagram = is inner implementation of the tracker.
9.Section 3.1, transaction-ID is not explained in = terminology part.
RSC: Definition = of TRANSACTION ID added to Terminology.
10. Table 2, it's suggested to add = the attribute "battery power"for mobile = peers.
RSC: "battery power" is a mobile specific = attribute, not generic. Attributes considered of interest can be added = by a "request-response extension" of the protocol as described in = section 7.1
11.Section = 4.1, it's better to limit the maximum number of the peers in the = peerlist to avoild DoS attack or maliciously getting the whole picture = of the active peers in short time for = profit.
RSC: A limit of 30 entries was = introduced. This limit allows a PEER LIST to fit a single datagram, = when using binary encoding.
=
12. P29,Are PEER REGISTERED and TRACKING states in the tracker or = peers?
RSC: The state machine is of = the Tracker
13. Section = 6.4, it's not clear about pro-incentive parameter.Needs more = descrption.
RSC: Complementary information = was added in section 6.4.
14.In the security part, the maclious action of asking = peer-list with large amount of peers should be = noted.
RSC: PEER LIST requests and = PEER LIST sizes returned by the Tracker are limited to a maximum of = 30 entries (30 peers) 
=
15.Appedix B1, the Authorization header field is not present in the = example. And this mechanism should be = highlighted.
RSC: The example in Appendix B = contains the field Authorization:

  =  <Method> /<Resource> HTTP/1.1
  =  Host: <Host>
   Content-Lenght: = <ContentLenght>
   Content-Type: = <ContentType>
   Authorization: = <AuthToken>

   [Request_Body] =  

16. It's better to have sperate drafts to discuss = Appedix C.
RSC: Agreed. Appendix C is given = as a simple example. Separate drafts can describe in detail the Use = Scenarios.
17. Does = OAth 2.0 well suit the authentication bw tracker and peers? I understand = that oAuth is best suited in 3rd-party application authorization,not = authentication. Am I right?
RSC: An HTTP = Basic authentication scheme, as defined in [RFC2617] can be used, or any = other suitable/supported authentication method, as described in =  [RFC6749].

BR
Yunfei


= --Apple-Mail=_FD73A2E7-7DE8-49E5-A55C-68C60D36A16A-- From hishigh@gmail.com Wed Jul 10 07:39:57 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ED311E8177 for ; Wed, 10 Jul 2013 07:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HteDRHRmKBq0 for ; Wed, 10 Jul 2013 07:39:52 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id A941111E8194 for ; Wed, 10 Jul 2013 07:39:48 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so9841576oag.12 for ; Wed, 10 Jul 2013 07:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dcoikBHtsZqP4ssTXJ7/Q+9bP1YW7oJgfbS/1xZw23g=; b=beqE3YXryPjxVTalBVD3cpacos1hUXcib43q/WDfYqfUssv83i1lXhG89DvC79GtEQ djrdJqcGEl4q05hR1MyHgfwyUnsxf1q6kZB/QQ3s9oo7Fr4CE13HBRCpoGVow/GaD7cj LLjRycX478+B4BuL4a3LYH/Q71zK9ZsKktnumLK6MjWvV4lJSu716cvz6lgeY1rLeHOk nY9ndkOTrfjrTRZ4uhNtI4AiKE/OCoSgThtc4l3a4+K4FbLgOa+qm7upe9+4n3mN2R0D 8HZjJ0cUwKxwVyTJqCuOoPUte+ACuDbUVBSoWWEiLhEp3UM7perWEsMDZA9fiwR71YqL uCVg== MIME-Version: 1.0 X-Received: by 10.182.79.106 with SMTP id i10mr27664428obx.59.1373467187148; Wed, 10 Jul 2013 07:39:47 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Wed, 10 Jul 2013 07:39:46 -0700 (PDT) In-Reply-To: <2D881B75-7000-4760-A193-1B231F30F25D@ieee.org> References: <2D881B75-7000-4760-A193-1B231F30F25D@ieee.org> Date: Wed, 10 Jul 2013 22:39:46 +0800 Message-ID: From: yunfei zhang To: Rui Cruz Content-Type: multipart/alternative; boundary=047d7b2e3e10ccfdc404e1293f78 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Reviewing the tracker protocol X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:39:57 -0000 --047d7b2e3e10ccfdc404e1293f78 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Rui, Please see inline. BR Yunfei 2013/7/10 Rui Cruz > Hi Yunfei, > > Many Thanks for your review. > > On your comments, they were really helpful, and provided a good guidance > for the changes. > The new version of the draft will be published this week, after review by > all authors, but before the cutoff date. > > Please read inline answers to your comments. > > Regards, > > Rui Cruz > rui.cruz@ieee.org > > IST/INESC-ID/INOV - Lisbon, Portugal > __________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > On 10/06/2013, at 10:50, yunfei zhang wrote: > > Hi All, > I have reviewed the tracker protocol draft and here is my comments: > > *Overall:* I think this draft is on the right way of a RFC. Implementors > can write most of the codes on the communication bw peers and trackers > according to the draft. There are clear examples on the syntax and > semantics for reference. > > > RSC: Those are good news indeed. > > > *Comments:* > *1.Abstrct:* Since the main body doesn't invlove in different messages in > either adaptive multi-rate, layered (scalable) or multi-view (3D) videos > scenarios and this is mainly on different metadata out of scope of this > draft, it's better to remove the related description in the abstract (See > more in comment #16). > > RSC: The last sentence just highlights that PPSP (tracker) protocol > enables peers to form content streaming overlay networks supporting near > real-time media content delivery, whichever the "encoding structure" thes= e > contents might have, and then lists examples. Appendix C, is just tutoria= l, > clarifying the different video "encoding structures" supported. However,= I > agree that a draft should be issued with descriptions of use cases, but > detailed, and I intend to do so. > > *2.Terminology:* > a)Adaptive Streaming: "...for the same streaming session" is a little > bit confusing. Do you mean in a same viewing or just the same streaming > content? > > RSC: corrected and moved to Appendix C > > b)Chunk: The definition in the Problem statement has been updated > according to the review. > > RSC: Updated > > c)Definition related to presentation: Since the discussion of adaptive > multi-rate, layered (scalable) > and multi-view (3D) videos scenarios is in the appendix, it seems > better to move them in the appendix. > > RSC: moved to Appendix C > > d) Media component: It seems not so clear on the definition. > > RSC: moved to Appendix C > > e)peer-ID: There is a missing ","after IP address. > > RSC: Corrected > > f) PPSP:The definition in the Problem statement has been updated > according to the review. > > RSC: Updated > > g) Scalable Streaming: MVC is not explained clearly like SVC and MDC. > > RSC: MVC description enhanced and the term "Scalable Streaming" was moved > to Appendix C. > > h) Segment: Is it same as Chunk? Do we need the definition of > Segement-ID? > > RSC: Definition of SEGMENT clarified. A new term, "SEGMENT CHUNK" was > added to Terminology. > > i) Tracker:The conception of "channel" is not explained. > > RSC: Definition of Tracker modified to follow Problem Statement definitio= n. > > *3.Enrollment and Bootstrap:* > 1)Since more roles like player and portal are introduced, it's better > to move the description on these roles,e.g., the relationship bw client > media player and the peer, currently in appendix, into this part. > > RSC: Descriptions of CLIENT MEDIA PLAYER and SERVICE PORTAL were added in > section 2.1 > > 2) It's better to clarify that Portal+ MPD file is not the only means > to locate the tracker. > > RSC: The first paragraph of section 2.1 was modified to clarify that the > exemplified methods are "not exhaustive". > > 4.section 2.3, PPSP-TP should be present in the terminology. > > RSC: A new term "PPSP-TP" added to Terminology > > 5.Section 2.3.2, in the CONNECT part: > a) When a peer registers in the tracker, it may not ask any swarm; > > RSC: The base tracker protocol requires the presence of SWARM ID in the > connect message, meaning that a *swarm action is mandatory*. if the > connect message does not ask swarm actions of join and/or leave and the > peer is not yet registered, it is an error condition, as described in > section 4.1. > > b) Peer IP addresses is not sufficient to locate a peer; > > RSC: The CONNECT message contains PEER ID, peer (ip) addresses and other > associate information as described in TABLE 3. What is the other > information that is still required to locate a peer? can you give an > example? > Anyway, some text was added to the description of CONNECT to stress that > peer location information is also handled by the tracker. > =A1=BEYunfei=A1=BF That would be fine. > > c) Doesn't the peer registers the Peer mode type informationl? > > RSC: description of CONNECT was complemented with that information. > > 6. P13, Para2,"each Peer-ID is modeled" or "each peer is modeled"? > > RSC: OK, leaving just "peer" is better. > > 7.Section 2.4.1,4)When Tracking, is there a need to send again a "CONNECT= "? > > RSC: In the base tracker protocol there is only one "ACTION SIGNAL" > message, the CONNECT. The other message is not for actions but for > information exchange. > While a peer is beeing tracked (in TRACKING STATE), to LEAVE a swarm or > JOIN a swarm it is required to send a CONNECT message. > > 8. How to convey the SM state information to the tracker? > > RSC: The state machine and flow diagram is inner implementation of the > tracker. > > 9.Section 3.1, transaction-ID is not explained in terminology part. > > RSC: Definition of TRANSACTION ID added to Terminology. > > 10. Table 2, it's suggested to add the attribute "battery power"for mobil= e > peers. > > RSC: "battery power" is a mobile specific attribute, not generic. > Attributes considered of interest can be added by a "request-response > extension" of the protocol as described in section 7.1 > > 11.Section 4.1, it's better to limit the maximum number of the peers in > the peerlist to avoild DoS attack or maliciously getting the whole pictur= e > of the active peers in short time for profit. > > RSC: A limit of 30 entries was introduced. This limit allows a PEER > LIST to fit a single datagram, when using binary encoding. > > 12. P29,Are PEER REGISTERED and TRACKING states in the tracker or peers? > > RSC: The state machine is of the Tracker > > 13. Section 6.4, it's not clear about pro-incentive parameter.Needs more > descrption. > > RSC: Complementary information was added in section 6.4. > > 14.In the security part, the maclious action of asking peer-list with > large amount of peers should be noted. > > RSC: PEER LIST requests and PEER LIST sizes returned by the Tracker are > limited to a maximum of 30 entries (30 peers) > > 15.Appedix B1, the Authorization header field is not present in the > example. And this mechanism should be highlighted. > > RSC: The example in Appendix B contains the field Authorization: > > / HTTP/1.1 > Host: > Content-Lenght: > Content-Type: > Authorization: > > [Request_Body] > > 16. It's better to have sperate drafts to discuss Appedix C. > > RSC: Agreed. Appendix C is given as a simple example. Separate drafts can > describe in detail the Use Scenarios. > > 17. Does OAth 2.0 well suit the authentication bw tracker and peers? I > understand that oAuth is best suited in 3rd-party application > authorization,not authentication. Am I right? > > RSC: An HTTP Basic authentication scheme, as defined in [RFC2617] can be > used, or any other suitable/supported authentication method, as described > in [RFC6749]. > > > BR > Yunfei > > > --047d7b2e3e10ccfdc404e1293f78 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Rui,
   Please see inline.
&n= bsp;
BR
Yun= fei

2013/7/10 Rui Cruz <rui.cruz@ieee.org>
Hi Yunfei,

Many Thanks for your review.
=

On your comments, they were really helpful, and provide= d a good guidance for the changes.
The new version of the draft w= ill be published this week, after review by all authors, but before the cut= off date.

Please read inline answers to your comments.

Regards,

Rui Cruz

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list

On 10/06/2013, at 10:50, yunfei zhang <<= a href=3D"mailto:hishigh@gmail.com" target=3D"_blank">hishigh@gmail.com= > wrote:

Hi All,   I have reviewed the tracker protocol draft and here is my com= ments:

Overall: I think this draft is on the right way = of a RFC. Implementors can write most of the codes on the communication bw = peers and trackers according to the draft. There are clear examples on the = syntax and semantics for reference.

RSC: Those are good news indeed.

Comments:
1.Abstrct: Since the = main body doesn't invlove in different messages in either adaptive mult= i-rate, layered (scalable) or multi-view (3D) videos scenarios and this is = mainly on different metadata out of scope of this draft, it's better to= remove the related description in the abstract (See more in comment #16).<= /div>
RSC: The last sentence just highlights t= hat PPSP (tracker) protocol enables peers to form content streaming overlay= networks supporting near real-time media content delivery, whichever the &= quot;encoding structure" these contents might have, and then lists exa= mples. Appendix C, is just tutorial, clarifying the different  vi= deo "encoding structures" supported. However, I agree t= hat a draft should be issued with descriptions of use cases, but detailed, = and I intend to do so.

2.Terminology:
  a)Adaptive Streaming: "...= for the same streaming session" is a little bit confusing. Do you mean= in a same viewing or just the same streaming content?
RSC: corrected and moved to Appendix C

  b)Chunk: The definition in th= e Problem statement has been updated according to the review. 
RSC: Updated

  c)Definition related to presentation: Since the discussion of a= daptive multi-rate, layered (scalable)
   and multi-vie= w (3D) videos scenarios is in the appendix, it seems better to move them in= the appendix.
RSC: moved to Appendix C

  d) Media component: It seems not so clear on the definition.
RSC: moved to Appendix C

<= blockquote type=3D"cite">
  e)peer-ID: There is a= missing ","after IP address.
RSC: Corrected

  f) PPSP:The definition in the Prob= lem statement has been updated according to the review. 
RSC: Updated

  g) Scalable Streaming: MVC is not explained clearly like SVC an= d MDC.
RSC: MVC description enhanced and the = term "Scalable Streaming" was moved to Appendix C. 

  h) Segment: Is i= t same as Chunk? Do we need the definition of Segement-ID?
RSC: Definition of SEGMENT clarified. A new term, "SEGME= NT CHUNK" was added to Terminology. 

  i) Tracker:The c= onception of "channel" is not explained.
=
RSC: Definition of Tracker modified to follow Problem Statement = definition.

3.Enrollment and Bootstrap:
   1)Since more= roles like player and portal are introduced, it's better to move the d= escription on these roles,e.g., the relationship bw client media player and= the peer, currently in appendix, into this part.
RSC: Descriptions of CLIENT MEDIA PLAYER and SERVI= CE PORTAL were added in section 2.1

   2) It's better to clarify that Portal+ MPD file is no= t the only means to locate the tracker.
RSC: = The first paragraph of section 2.1 was modified to clarify that the exempli= fied methods are "not exhaustive".

4.section 2.3, PPSP-TP = should be present in the terminology.
RSC: A = new term "PPSP-TP" added to Terminology

5.Section 2.3.2, in the CONNECT part:
   a) When a peer registers in the tracker, it may not ask a= ny swarm; 
RSC: The base tracker pr= otocol requires the presence of SWARM ID in the connect message, meaning th= at a swarm action is mandatory. if the connect message does not ask = swarm actions of join and/or leave and the peer is not yet registered, it i= s an error condition, as described in section 4.1.

   b) Peer IP= addresses is not sufficient to locate a peer;
RSC: The CONNECT message contains PEER ID, peer (ip) addresses and other = associate information as described in TABLE 3. What is the other infor= mation that is still required to locate a peer? can you give an example?&nb= sp;
Anyway, some text was added to the description of CONNECT to stress th= at peer location information is also handled by the tracker.
=A1=BEYunfei=A1=BF That would be fine. 

   c) Doesn't the peer registers the Peer mod= e type informationl?
RSC: description of=  CONNECT was complemented with that information.

6. P13, Para2,"each Peer-ID is modeled" or "each peer i= s modeled"?
RSC: OK, leaving just &= quot;peer" is better.

<= div dir=3D"ltr">
7.Section 2.4.1,4)When Tracking, is there a need to send again a "= ;CONNECT"?
RSC:  In the base t= racker protocol there is only one "ACTION SIGNAL" message, t= he CONNECT. The other message is not for actions but for information e= xchange.
While a peer is beeing tracked (in TRACKING STATE), to LEAVE a swarm or JOI= N a swarm it is required to send a CONNECT message.
8. How to convey the S= M state information to the tracker?
RSC: The state machine and flow diagram is inner i= mplementation of the tracker.
9.Section 3.1, transaction-ID is not explained in termi= nology part.
RSC: Definition of TRANSACTION ID added to Te= rminology.

=
10. Table 2, it's suggested to add the attribute "battery pow= er"for mobile peers.
RSC: "battery power" is a mobile specifi= c attribute, not generic. Attributes considered of interest can be added by= a "request-response extension" of the protocol as described in s= ection 7.1
11.Section 4.1, it's be= tter to limit the maximum number of the peers in the peerlist to avoild DoS= attack or maliciously getting the whole picture of the active peers in sho= rt time for profit.
RSC: A limit of 30 entries was introduced. Th= is limit allows a PEER LIST to fit a single datagram, when using binar= y encoding.

12. P29,Are PEER REGISTERED and TRACKING states in the tracker or peer= s?
RSC: The state machine is of the= Tracker
1= 3. Section 6.4, it's not clear about pro-incentive parameter.Needs more= descrption.
RSC: Complementary information was added in s= ection 6.4.

14.In the security part, the maclious action of asking peer-list with= large amount of peers should be noted.
RSC: PEER LIST requests and PEER LIST&nb= sp;sizes returned by the Tracker are limited to a maximum of 30 entries (30= peers) 

15.Appedix B1, the Authorization header field is not present in the ex= ample. And this mechanism should be highlighted.
RSC: The example in Appendix B contains the field Authorization:

   <Method> /<Resource> HTTP/1.1<= /div>
   Host: <Host>
   Content-Le= nght: <ContentLenght>
   Content-Type: <Conten= tType>
   Authorization: <AuthToken>

   [Request_Body]  

16. It= 9;s better to have sperate drafts to discuss Appedix C.
RSC: Agreed. Appendix C is given as a simple example. Separ= ate drafts can describe in detail the Use Scenarios.

17. Does OAth 2.0 well = suit the authentication bw tracker and peers? I understand that oAuth is be= st suited in 3rd-party application authorization,not authentication. Am I r= ight?
RSC: An HTTP Basic authentication scheme, as = defined in [RFC2617] can be used, or any other suitable/supported authentic= ation method, as described in  [RFC6749].

BR
Yunfei



--047d7b2e3e10ccfdc404e1293f78-- From rachel.huang@huawei.com Wed Jul 10 18:45:54 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3497921F871D for ; Wed, 10 Jul 2013 18:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCmX0zn96IEo for ; Wed, 10 Jul 2013 18:45:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C96A21F8C11 for ; Wed, 10 Jul 2013 18:45:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX10835; Thu, 11 Jul 2013 01:45:45 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 02:45:09 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 02:45:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 09:45:40 +0800 From: "Huangyihong (Rachel)" To: "ppsp@ietf.org" Thread-Topic: [ppsp]FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt Thread-Index: AQHOfdhYHbNxoGWVpUSfb1NT/ggTLg== Date: Thu, 11 Jul 2013 01:45:39 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 01:45:54 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFm dC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wuIFRoaXMgdXBkYXRlIGlzIGp1 c3Qgc29tZSBlZGl0b3JpYWwgY2hhbmdlcy4gTm8gc2lnbmlmaWNhbnQgbW9kaWZpY2F0aW9uLiBD b21tZW50cyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVkLiANCg0KQmVzdCByZWdhcmRzLA0KUmFjaGVs DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2Rh eSwgSnVseSAxMSwgMjAxMyA5OjI5IEFNDQpUbzogTWFyaW8gU2VyYWZpbSBOdW5lczsgUnVpIFNh bnRvcyBDcnV6OyBSdWkgU2FudCBDcnV6OyBab25nbmluZzsgTWFyaW8gU2VyYSBOdW5lczsgSHVh bmd5aWhvbmcgKFJhY2hlbCk7IEpvYW8gUC4gVGF2ZWlyYQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9j b2wtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1YW5nLXBwc3AtZXh0 ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgUmFjaGVsIEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtaHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29s DQpSZXZpc2lvbjoJIDAzDQpUaXRsZToJCSBQUFNQIFRyYWNrZXIgUHJvdG9jb2wtLUV4dGVuZGVk IFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMQ0KR3JvdXA6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDI2DQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQt dHJhY2tlci1wcm90b2NvbC0wMy50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9j b2wNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVh bmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sLTAzDQpEaWZmOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQt dHJhY2tlci1wcm90b2NvbC0wMw0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IGFuIGV4dGVuZGVkIFBlZXItdG8tUGVlciBTdHJlYW1pbmcgUHJvdG9jb2wgLQ0KVHJhY2tlciBQ cm90b2NvbCwgd2hpY2ggaXMgYSBuZXcgZXh0ZW5zaW9uIHByb3RvY29sIGNvbXBsZW1lbnRpbmcg dGhlDQpiYXNpYyBjb3JlIG1lc3NhZ2VzIGFuZCB1c2FnZXMgc3BlY2lmaWVkIGluIHRoZSBiYXNl IHRyYWNrZXIgcHJvdG9jb2wNCmZvciB0aGUgZXhjaGFuZ2Ugb2YgbWV0YSBpbmZvcm1hdGlvbiBi ZXR3ZWVuIHRyYWNrZXJzIGFuZCBwZWVycywgc3VjaCBhcw0KaW5pdGlhbCBvZmZlci9yZXF1ZXN0 IG9mIHBhcnRpY2lwYXRpb24gaW4gbXVsdGltZWRpYSBjb250ZW50IHN0cmVhbWluZywNCmNvbnRl bnQgaW5mb3JtYXRpb24sIHBlZXIgbGlzdHMgYW5kIHJlcG9ydHMgb2YgYWN0aXZpdHkgYW5kIHN0 YXR1cy4gSXQNCmV4dGVuZHMgdGhlIGJhc2UgdHJhY2tlciBwcm90b2NvbCB0byBpbmNsdWRlIG5l dyBvcHRpb25hbCBtZXNzYWdlcw0KcHJvdmlkaW5nIG5ldyB1c2FnZXMgaW4gdGhlIGNvbW11bmlj YXRpb25zIGJldHdlZW4gcGVlciBhbmQgdHJhY2tlci4gVGhlDQpleHRlbnNpb24gcHJvdG9jb2wg aXMgcmV0cm8tY29tcGF0aWJsZSB3aXRoIHRoZSBiYXNlIHRyYWNrZXIgcHJvdG9jb2wuDQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From denglingli@chinamobile.com Thu Jul 11 03:05:07 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D00121F9FCF for ; Thu, 11 Jul 2013 03:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.193 X-Spam-Level: **** X-Spam-Status: No, score=4.193 tagged_above=-999 required=5 tests=[AWL=-3.064, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hUr5d43ddGO for ; Thu, 11 Jul 2013 03:05:03 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id C930621F9F9B for ; Thu, 11 Jul 2013 03:05:02 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251de830e023-84023; Thu, 11 Jul 2013 18:03:59 +0800 (CST) X-RM-TRANSID: 2ee251de830e023-84023 Received: from cmccPC (unknown[10.2.43.200]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351de830e8f8-8c8c8; Thu, 11 Jul 2013 18:03:59 +0800 (CST) X-RM-TRANSID: 2ee351de830e8f8-8c8c8 From: =?gb2312?B?tcvB6cDyL0xpbmdsaSBEZW5n?= To: "'Huangyihong \(Rachel\)'" , References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> Date: Thu, 11 Jul 2013 18:04:55 +0800 Message-ID: <016001ce7e1e$18291fb0$487b5f10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOfdhYHbNxoGWVpUSfb1NT/ggTLplfLNBw Content-Language: zh-cn Subject: [ppsp] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tl?= =?gb2312?b?ci1wcm90b2NvbC0wMy50eHQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:05:07 -0000 Hi Rachel, I found some inconsistencies in the new revision as follows for you to consider:=20 1, There are inconsistent description about DISCONNECT messages: On Page = 5, in Section 4.1.2, paragraph #2, it is stated that "The DISCONNECT = Request message is used when the peer intends to no longer participate in *all* warms." However, On page 6, in Section 4.2, paragraph #1, it goes "the = peer DISCONNECTs from the corresponding swarm (swarm_b) while still sharing = the first content (swarm_a)". Subsequent relevant texts all seem to be = comply with the first one. 2, There are inconsistent description about the exemplified session in Section 4.2 between the text and the Figure 1. For the figure does not = catch the status of ""the peer DISCONNECTs from the corresponding swarm = (swarm_b) while still sharing the first content (swarm_a)". 3, Mino typo: on page 9, paragraph labeled with "7)", the last sentence should be "..., and transitions to TERMINATE s*t*ate for that Peer-ID." A few questions about the protocol design: 1, What's the objective behind the "init-timer" scheme? 2, How would a peer be "joining the swarm with invalid Swarm_Id"? 3, In section 4.5, since there are extended messages with newly = introduced fields (e.g. contentgroup), you may also need to handle cases with = "Unknown fields" as well as "Unknown Messages". 4, In case a peer specifies the peergroup S (a subset of all the = segments) it's currently interested in with a FIND message, does it make sense for = a tracker to return a peer with only a subset S' of S to the requestor? Lastly, as for the arrangement of contentgroup, it could be rather bit-consuming if a peer is FINDing a scattered group of segments. I have been proposing to use compression method to mitigate this matter. http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/=20 I would like to hear any feedback or comments from you TR guys about = it:-) BR Lingli -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Huangyihong (Rachel) =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C211=C8=D5 9:46 =CA=D5=BC=FE=C8=CB: ppsp@ietf.org =D6=F7=CC=E2: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt Dear all, We have just submitted a new version of draft-huang-ppsp-extended-tracker-protocol. This update is just some editorial changes. No significant modification. Comments are highly appreciated.=20 Best regards, Rachel -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, July 11, 2013 9:29 AM To: Mario Serafim Nunes; Rui Santos Cruz; Rui Sant Cruz; Zongning; Mario Sera Nunes; Huangyihong (Rachel); Joao P. Taveira Subject: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt A new version of I-D, draft-huang-ppsp-extended-tracker-protocol-03.txt has been successfully submitted by Rachel Huang and posted to the IETF repository. Filename: draft-huang-ppsp-extended-tracker-protocol Revision: 03 Title: PPSP Tracker Protocol--Extended Protocol Creation date: 2013-07-11 Group: Individual Submission Number of pages: 26 URL: http://www.ietf.org/internet-drafts/draft-huang-ppsp-extended-tracker-pro= toc ol-03.txt Status: http://datatracker.ietf.org/doc/draft-huang-ppsp-extended-tracker-protoco= l Htmlized: http://tools.ietf.org/html/draft-huang-ppsp-extended-tracker-protocol-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-huang-ppsp-extended-tracker-prot= ocol- 03 Abstract: This document specifies an extended Peer-to-Peer Streaming Protocol - Tracker Protocol, which is a new extension protocol complementing the basic core messages and usages specified in the base tracker protocol for the exchange of meta information between trackers and peers, such as initial offer/request of participation in multimedia content streaming, content information, peer lists and reports of activity and status. It extends the base tracker protocol to include new optional messages providing new usages in the communications between peer and tracker. The extension protocol is retro-compatible with the base tracker protocol. =20 The IETF Secretariat _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp From rachel.huang@huawei.com Thu Jul 11 18:55:40 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3C721F9F17 for ; Thu, 11 Jul 2013 18:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9Rqq1Q6vGQ2 for ; Thu, 11 Jul 2013 18:55:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 446E321F9EC2 for ; Thu, 11 Jul 2013 18:55:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY03988; Fri, 12 Jul 2013 01:55:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 02:55:07 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 02:55:30 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 09:55:23 +0800 From: "Huangyihong (Rachel)" To: =?gb2312?B?tcvB6cDyL0xpbmdsaSBEZW5n?= , "ppsp@ietf.org" Thread-Topic: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt Thread-Index: AQHOfh4bDtsUZalPb06dD4Omw8RdkplgOurw Date: Fri, 12 Jul 2013 01:55:22 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4584126D@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <016001ce7e1e$18291fb0$487b5f10$@com> In-Reply-To: <016001ce7e1e$18291fb0$487b5f10$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 01:55:40 -0000 SGkgbGluZ2xpLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgbXkgcmVw bHkgaW5saW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQpSYWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206ILXLwenA8i9MaW5nbGkgRGVuZyBbbWFpbHRvOmRlbmdsaW5nbGlAY2hp bmFtb2JpbGUuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKdWx5IDExLCAyMDEzIDY6MDUgUE0NClRv OiBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgcHBzcEBpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogW3Bw c3BdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0 ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMy50eHQNCg0KSGkgUmFjaGVsLA0KDQpJIGZvdW5kIHNv bWUgaW5jb25zaXN0ZW5jaWVzIGluIHRoZSBuZXcgcmV2aXNpb24gYXMgZm9sbG93cyBmb3IgeW91 IHRvDQpjb25zaWRlcjogDQoNCjEsIFRoZXJlIGFyZSBpbmNvbnNpc3RlbnQgZGVzY3JpcHRpb24g YWJvdXQgRElTQ09OTkVDVCBtZXNzYWdlczogT24gUGFnZSA1LA0KaW4gU2VjdGlvbiA0LjEuMiwg cGFyYWdyYXBoICMyLCBpdCBpcyBzdGF0ZWQgdGhhdCAiVGhlIERJU0NPTk5FQ1QgUmVxdWVzdA0K bWVzc2FnZSBpcyB1c2VkIHdoZW4gdGhlIHBlZXIgaW50ZW5kcyB0byBubyBsb25nZXIgcGFydGlj aXBhdGUgaW4gKmFsbCoNCndhcm1zLiIgSG93ZXZlciwgT24gcGFnZSA2LCBpbiBTZWN0aW9uIDQu MiwgcGFyYWdyYXBoICMxLCBpdCBnb2VzICJ0aGUgcGVlcg0KRElTQ09OTkVDVHMgZnJvbSB0aGUg Y29ycmVzcG9uZGluZyBzd2FybSAoc3dhcm1fYikgd2hpbGUgc3RpbGwgc2hhcmluZyB0aGUNCmZp cnN0IGNvbnRlbnQgKHN3YXJtX2EpIi4gU3Vic2VxdWVudCByZWxldmFudCB0ZXh0cyBhbGwgc2Vl bSB0byBiZSBjb21wbHkNCndpdGggdGhlIGZpcnN0IG9uZS4NCg0KW1JhY2hlbF06IFllcywgdGhh dCdzIGFuIGVycm9yIGRlc2NyaXB0aW9uIG9mIHNlY3Rpb24gNC4yLiBESVNDT05ORUNUIG1lc3Nh Z2Ugb25seSBoYXMgdGhlIGFiaWxpdHkgdG8gbGVhdmUgYWxsIHRoZSBzd2FybXMgdGhlIHBlZXIg am9pbmVkLiBJIGRvbid0IHRoaW5rIERJU0NPTk5FQ1Qgc2hvdWxkIGhhdmUgYSBzYW1lIG1lYW5p bmcgb2YgQ09OTkVDVCAoTEVBVkUpLiBTbyB0aGlzIGlzIG9uZSBwbGFjZSB0aGF0IEkgb21pdHRl ZCB0byBtb2RpZnkuIFRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgb3V0Lg0KDQoyLCBUaGVyZSBhcmUg aW5jb25zaXN0ZW50IGRlc2NyaXB0aW9uIGFib3V0IHRoZSBleGVtcGxpZmllZCBzZXNzaW9uIGlu DQpTZWN0aW9uIDQuMiBiZXR3ZWVuIHRoZSB0ZXh0IGFuZCB0aGUgRmlndXJlIDEuIEZvciB0aGUg ZmlndXJlIGRvZXMgbm90IGNhdGNoDQp0aGUgc3RhdHVzIG9mICIidGhlIHBlZXIgRElTQ09OTkVD VHMgZnJvbSB0aGUgY29ycmVzcG9uZGluZyBzd2FybSAoc3dhcm1fYikNCndoaWxlIHN0aWxsIHNo YXJpbmcgdGhlIGZpcnN0IGNvbnRlbnQgKHN3YXJtX2EpIi4NCg0KW1JhY2hlbF06IFNlZSBhYm92 ZS4gRmlndXJlIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGVzY3JpcHRpb24gb2Ygc2VjdGlvbiA0 LjEuMi4NCg0KMywgTWlubyB0eXBvOiBvbiBwYWdlIDksIHBhcmFncmFwaCBsYWJlbGVkIHdpdGgg IjcpIiwgdGhlIGxhc3Qgc2VudGVuY2UNCnNob3VsZCBiZSAiLi4uLCBhbmQgdHJhbnNpdGlvbnMg dG8gVEVSTUlOQVRFIHMqdCphdGUgZm9yIHRoYXQgUGVlci1JRC4iDQoNCltSYWNoZWxdOiBPa2F5 Lg0KDQpBIGZldyBxdWVzdGlvbnMgYWJvdXQgdGhlIHByb3RvY29sIGRlc2lnbjoNCg0KMSwgV2hh dCdzIHRoZSBvYmplY3RpdmUgYmVoaW5kIHRoZSAiaW5pdC10aW1lciIgc2NoZW1lPw0KDQpbUmFj aGVsXTogUHJldmlvdXNseSwgaW5pdC10aW1lciB3YXMgdXNlZCB0byB3YWl0IGZvciBvdGhlciBt ZXNzYWdlcyBhZnRlciBhIHBlZXIgaGFzIHNlbnQgYSAiUkVHSVNURVIiIG1lc3NhZ2UgdG8gdGhl IHRyYWNrZXIuIEFuZCB0aGUgIlBFRVIgUkVHSVNURVJFRCIgc3RhdGUgd2FzIG5vdCB0cmFuc2ll bnQgYXQgdGhhdCB0aW1lLiBCdXQgbm93LCB3ZSBoYXZlIGFiYW5kb25lZCB0aGUgIlJFR0lTVEVS IiBtZXNzYWdlIGFuZCAgIlBFRVIgUkVHSVNURVJFRCIgc3RhdGUgaXMgdHJhbnNpZW50LCBzbyBJ IHRoaW5rIHdlIGRvbid0IG5lZWQgaW5pdC10aW1lciBhbnltb3JlLiANCg0KMiwgSG93IHdvdWxk IGEgcGVlciBiZSAiam9pbmluZyB0aGUgc3dhcm0gd2l0aCBpbnZhbGlkIFN3YXJtX0lkIj8NCg0K W1JhY2hlbF06IE15IGZhdWx0LiBJdCdzIGEgd3JvbmcgZGVzY3JpcHRpb24uICBJIHRoaW5rIG15 IGludGVuc2lvbiBpcyB0byBzYXkgcmVjZWl2aW5nIGEgRklORCBtZXNzYWdlIHdpdGggYSBpbnZh bGlkIFN3YXJtX0lkIGlzIGNvbnNpZGVyZWQgYSBlcnJvciBjb25kaXRpb24uDQoNCjMsIEluIHNl Y3Rpb24gNC41LCBzaW5jZSB0aGVyZSBhcmUgZXh0ZW5kZWQgbWVzc2FnZXMgd2l0aCBuZXdseSBp bnRyb2R1Y2VkDQpmaWVsZHMgKGUuZy4gY29udGVudGdyb3VwKSwgeW91IG1heSBhbHNvIG5lZWQg dG8gaGFuZGxlIGNhc2VzIHdpdGggIlVua25vd24NCmZpZWxkcyIgYXMgd2VsbCBhcyAiVW5rbm93 biBNZXNzYWdlcyIuDQoNCltSYWNoZWxdOiBHb29kIHBvaW50LiBUaGFua3MuDQoNCjQsIEluIGNh c2UgYSBwZWVyIHNwZWNpZmllcyB0aGUgcGVlcmdyb3VwIFMgKGEgc3Vic2V0IG9mIGFsbCB0aGUg c2VnbWVudHMpDQppdCdzIGN1cnJlbnRseSBpbnRlcmVzdGVkIGluIHdpdGggYSBGSU5EIG1lc3Nh Z2UsIGRvZXMgaXQgbWFrZSBzZW5zZSBmb3IgYQ0KdHJhY2tlciB0byByZXR1cm4gYSBwZWVyIHdp dGggb25seSBhIHN1YnNldCBTJyBvZiBTIHRvIHRoZSByZXF1ZXN0b3I/DQoNCltSYWNoZWxdOiBJ IHRoaW5rIHllcy4gd2h5IG5vdD8NCg0KTGFzdGx5LCBhcyBmb3IgdGhlIGFycmFuZ2VtZW50IG9m IGNvbnRlbnRncm91cCwgaXQgY291bGQgYmUgcmF0aGVyDQpiaXQtY29uc3VtaW5nIGlmIGEgcGVl ciBpcyBGSU5EaW5nIGEgc2NhdHRlcmVkIGdyb3VwIG9mIHNlZ21lbnRzLiBJIGhhdmUNCmJlZW4g cHJvcG9zaW5nIHRvIHVzZSBjb21wcmVzc2lvbiBtZXRob2QgdG8gbWl0aWdhdGUgdGhpcyBtYXR0 ZXIuDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlbmctcHBzcC1iZmJp dG1hcC8gDQpJIHdvdWxkIGxpa2UgdG8gaGVhciBhbnkgZmVlZGJhY2sgb3IgY29tbWVudHMgZnJv bSB5b3UgVFIgZ3V5cyBhYm91dCBpdDotKQ0KDQpbUmFjaGVsXTogWWVzLiBJJ20gYXdhcmUgb2Yg aXQuIEknbSB3b3JraW5nIG9uIHNvbWUgaWV0ZiBkb2N1bWVudHMgdGhlc2UgZGF5cy4gSSdsbCBn ZXQgeW91IHNvbWUgcmVzcG9uc2VzIGluIGEgZmV3IGRheXMuDQoNCkJSDQpMaW5nbGkNCg0KLS0t LS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBw c3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KSHVhbmd5aWhvbmcgKFJhY2hlbCkNCreiy83Ksbzk OiAyMDEzxOo31MIxMcjVIDk6NDYNCsrVvP7IyzogcHBzcEBpZXRmLm9yZw0K1vfM4jogW3Bwc3Bd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFmdC1odWFuZy1wcHNwLWV4dGVu ZGVkLXRyYWNrZXItcHJvdG9jb2wtMDMudHh0DQoNCkRlYXIgYWxsLA0KDQpXZSBoYXZlIGp1c3Qg c3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YNCmRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJh Y2tlci1wcm90b2NvbC4gVGhpcyB1cGRhdGUgaXMganVzdCBzb21lDQplZGl0b3JpYWwgY2hhbmdl cy4gTm8gc2lnbmlmaWNhbnQgbW9kaWZpY2F0aW9uLiBDb21tZW50cyBhcmUgaGlnaGx5DQphcHBy ZWNpYXRlZC4gDQoNCkJlc3QgcmVnYXJkcywNClJhY2hlbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEp1bHkgMTEsIDIwMTMgOToyOSBB TQ0KVG86IE1hcmlvIFNlcmFmaW0gTnVuZXM7IFJ1aSBTYW50b3MgQ3J1ejsgUnVpIFNhbnQgQ3J1 ejsgWm9uZ25pbmc7IE1hcmlvDQpTZXJhIE51bmVzOyBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgSm9h byBQLiBUYXZlaXJhDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFm dC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wtMDMudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2Nv bC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFjaGVsIEh1YW5n IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt aHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sDQpSZXZpc2lvbjoJIDAzDQpUaXRs ZToJCSBQUFNQIFRyYWNrZXIgUHJvdG9jb2wtLUV4dGVuZGVkIFByb3RvY29sDQpDcmVhdGlvbiBk YXRlOgkgMjAxMy0wNy0xMQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDI2DQpVUkw6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jDQpvbC0wMy50eHQNClN0YXR1 czoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVhbmctcHBzcC1leHRl bmRlZC10cmFja2VyLXByb3RvY29sDQpIdG1saXplZDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMw0KRGlmZjoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5k ZWQtdHJhY2tlci1wcm90b2NvbC0NCjAzDQoNCkFic3RyYWN0Og0KVGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgYW4gZXh0ZW5kZWQgUGVlci10by1QZWVyIFN0cmVhbWluZyBQcm90b2NvbCAtDQpUcmFj a2VyIFByb3RvY29sLCB3aGljaCBpcyBhIG5ldyBleHRlbnNpb24gcHJvdG9jb2wgY29tcGxlbWVu dGluZyB0aGUNCmJhc2ljIGNvcmUgbWVzc2FnZXMgYW5kIHVzYWdlcyBzcGVjaWZpZWQgaW4gdGhl IGJhc2UgdHJhY2tlciBwcm90b2NvbA0KZm9yIHRoZSBleGNoYW5nZSBvZiBtZXRhIGluZm9ybWF0 aW9uIGJldHdlZW4gdHJhY2tlcnMgYW5kIHBlZXJzLCBzdWNoIGFzDQppbml0aWFsIG9mZmVyL3Jl cXVlc3Qgb2YgcGFydGljaXBhdGlvbiBpbiBtdWx0aW1lZGlhIGNvbnRlbnQgc3RyZWFtaW5nLA0K Y29udGVudCBpbmZvcm1hdGlvbiwgcGVlciBsaXN0cyBhbmQgcmVwb3J0cyBvZiBhY3Rpdml0eSBh bmQgc3RhdHVzLiBJdA0KZXh0ZW5kcyB0aGUgYmFzZSB0cmFja2VyIHByb3RvY29sIHRvIGluY2x1 ZGUgbmV3IG9wdGlvbmFsIG1lc3NhZ2VzDQpwcm92aWRpbmcgbmV3IHVzYWdlcyBpbiB0aGUgY29t bXVuaWNhdGlvbnMgYmV0d2VlbiBwZWVyIGFuZCB0cmFja2VyLiBUaGUNCmV4dGVuc2lvbiBwcm90 b2NvbCBpcyByZXRyby1jb21wYXRpYmxlIHdpdGggdGhlIGJhc2UgdHJhY2tlciBwcm90b2NvbC4N Cg0KDQogDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCg0K From internet-drafts@ietf.org Thu Jul 11 08:40:00 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E275321F9E6D; Thu, 11 Jul 2013 08:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.393 X-Spam-Level: X-Spam-Status: No, score=-101.393 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_00=-2.599, MANGLED_LOAN=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXSpj7YKkcC4; Thu, 11 Jul 2013 08:40:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A44421F9E89; Thu, 11 Jul 2013 08:39:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711153958.21463.84549.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 08:39:58 -0700 X-Mailman-Approved-At: Fri, 12 Jul 2013 06:25:29 -0700 Cc: ppsp@ietf.org Subject: [ppsp] I-D Action: draft-ietf-ppsp-base-tracker-protocol-01.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:40:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer to Peer Streaming Protocol Working G= roup of the IETF. Title : PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0) Author(s) : Rui Santos Cruz Mario Serafim Nunes Gu Yingjie Jinwei Xia Joao P. Taveira Deng Lingli Filename : draft-ietf-ppsp-base-tracker-protocol-01.txt Pages : 55 Date : 2013-07-11 Abstract: This document specifies the base Peer-to-Peer Streaming Protocol- Tracker Protocol (PPSP-TP/1.0), an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality, and describes message flows, message processing instructions, message formats, formal syntax and semantics. The PPSP Tracker Protocol enables cooperating peers to form content streaming overlay networks to support near real-time Structured Media content delivery (audio, video, associated timed text and metadata), such as adaptive multi-rate, layered (scalable) and multi-view (3D) videos, in live, time-shifted and on-demand modes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ppsp-base-tracker-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ppsp-base-tracker-protocol-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-base-tracker-protocol-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jul 11 18:23:58 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E5711E8218; Thu, 11 Jul 2013 18:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E75gTu6pODC; Thu, 11 Jul 2013 18:23:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD17111E81F0; Thu, 11 Jul 2013 18:23:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712012357.32055.17059.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 18:23:57 -0700 X-Mailman-Approved-At: Fri, 12 Jul 2013 06:25:29 -0700 Cc: ppsp@ietf.org Subject: [ppsp] I-D Action: draft-ietf-ppsp-survey-05.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 01:23:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer to Peer Streaming Protocol Working G= roup of the IETF. Title : Survey of P2P Streaming Applications Author(s) : Gu Yingjie Zong Ning Zhang Yunfei Francesca Lo Piccolo Duan Shihui Filename : draft-ietf-ppsp-survey-05.txt Pages : 21 Date : 2013-07-11 Abstract: This document presents a survey of some of the most popular Peer-to- Peer (P2P) streaming applications on the Internet. Main selection criteria have been popularity and availability of information on operation details at writing time. In doing this, selected applications are not reviewed as a whole, but they are reviewed with main focus on the signaling and control protocol used to establish and maintain overlay connections among peers and to advertise and download streaming content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ppsp-survey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ppsp-survey-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-survey-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rachel.huang@huawei.com Mon Jul 15 00:28:26 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4F421F9EDC for ; Mon, 15 Jul 2013 00:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uclKL3g8KsHy for ; Mon, 15 Jul 2013 00:28:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6417A21F8415 for ; Mon, 15 Jul 2013 00:24:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVA21047; Mon, 15 Jul 2013 07:24:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 08:23:59 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 08:24:45 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 15:24:41 +0800 From: "Huangyihong (Rachel)" To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= , "'ppsp'" Thread-Topic: =?utf-8?B?W3Bwc3BdIOi9rOWPkTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?utf-8?Q?raft-deng-ppsp-bfbitmap-00.txt?= Thread-Index: Ac53ovWlHvdzdymjTROWhBQwN1+k8AAAK6BwAljTrCA= Date: Mon, 15 Jul 2013 07:24:40 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4584F0F1@nkgeml501-mbs.china.huawei.com> References: <007601ce77b0$aae81910$00b84b30$@com> In-Reply-To: <007601ce77b0$aae81910$00b84b30$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ppsp-bfbitmap-00=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:28:26 -0000 SGkgTGluZ2xpLA0KDQpJdCdzIGEgdmVyeSBpbnRlcmVzdGluZyB0b3BpYy4gSXQncyB2ZXJ5IHVz ZWZ1bCBmb3IgbWVzc2FnZXMgd2l0aCBDb250ZW50TWFwIGV4Y2hhbmdlcy4gVGhhbmtzIGZvciBi cmluZyB0aGlzLiAgSSBoYXZlIGZvbGxvd2luZyBjb21tZW50cyB3aGVuIEkgcmV2aWV3IGl0Og0K DQoxLiBJbiBzZWN0aW9uIDMuMSwgdGhlIGRlc2NyaXB0aW9uIGZvbGxvd2luZyB0aGUgZmlndXJl IDIgZG9lc24ndCBxdWl0ZSBjb3JyZXNwb25kIHRvIHRoZSBmaWd1cmUuIEZvciBleGFtcGxlLCB0 aGUgaXRlbSAzIGFuZCA0IGNvdWxkbid0IGJlIGZvdW5kIGluIHRoZSBmaWd1cmUuIEFuZCBJIHRo aW5rIGl0J3MgYmV0dGVyIHRvIHNob3cgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBsZWVjaCBtb2Rl IGFuZCBzZWVkZXIgbW9kZSBpbiB0aGUgZmlndXJlLiANCg0KMi4gSSB0aGluayBzZWN0aW9uIDQg c2hvdWxkIGJlIHBsYWNlZCBpbiB0aGUgc2VjdGlvbiAzLiBPdGhlcndpc2UsIHBlb3BsZSB3aWxs IGhhdmUgdGhlIHF1ZXN0aW9uIHdoeSBCRiBjb25mIGNvdWxkIGJlIG9idGFpbmVkIGZyb20gYm90 aCB0aGUgcG9ydGFsIGFuZCB0aGUgdHJhY2tlci4gDQoNCjMuIEluIHNlY3Rpb24gMy4yLCBjbGF1 c2UgYSwgSSBkb24ndCB0aGluayB0aGUgYmFzZSBUUCBwcm90b2NvbCBoYXMgSk9JTiByZXF1ZXN0 IG1lc3NhZ2UuDQoNCjQuIEluIHNlY3Rpb24gMy4yLCBjbGF1c2UgYiAiSW50ZWdyYXRpb24gdG8g dGhlIGV4dGVuZGVkIFRQIHByb3RvY29sIiwgdGhlcmUncyBubyBjb3JyZXNwb25kaW5nIG1lc3Nh Z2UgKGxpa2UgRklORCkgZm91bmQgaW4gdGhlIGZpZ3VyZSAzLg0KDQo1LiBJbiBzZWN0aW9uIDMu MiwgY2xhdXNlIGIsICIgUGVlcnMgdXNlIHRoZSBCRihTLG0sSCkgYWxnb3JpdGhtIGZvciBpbmRp Y2F0aW5nIGl0cyBxdWVyeSIsIHNob3VsZCB0aGUgIlMiIGJlIHJlcGxhY2VkIHdpdGggIlMnIj8g QW5kIHdoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIEYoUykgYW5kIEJGKFMpLiBTb3JyeSwg SSBjYW4ndCB1bmRlcnN0YW5kIHRoZSBvcGVyYXRpb24gIkYoUykgZXF1YWxzIChCRihTKSBiaXR3 aXNlIE9SIChCRihTKSBiaXR3aXNlIFhPUiBCRihTJykpIi4gSSB0aGluayBpZiBCRihTJykgZXF1 YWxzIChCRihTKSBiaXR3aXNlIFhPUiBCRihTJyksIHRoZSBwZWVyIHNob3VsZCBiZSBpbmNsdWRl ZCBpbiB0aGUgcGVlciBsaXN0IG9mIHRoZSBGSU5EIHJlc3BvbnNlLiBTbyB3b3VsZCB5b3UgY2xh cmlmeSBtb3JlIGFib3V0IGl0Pw0KDQo2LiBJbiBzZWN0aW9uIDQuMSBvcHRpb24gMSwgdGhlcmUg YXJlIHNvbWUgc2VudGVuY2VzIGhhdmUgYmVlbiBkdXBsaWNhdGVkLiBJdCdzIGFuIGVkaXRvcmlh bCBlcnJvci4NCg0KQmVzdCByZWdhcmRzLA0KUmFjaGVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiDpgpPngbXojokvTGluZ2xpIERlbmcNClNlbnQ6IFdlZG5l c2RheSwgSnVseSAwMywgMjAxMyAxOjQ3IFBNDQpUbzogJ3Bwc3AnDQpTdWJqZWN0OiBbcHBzcF0g 6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRlbmctcHBzcC1iZmJp dG1hcC0wMC50eHQNCg0KSGkgYWxsLA0KDQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRy YWZ0IHByb3Bvc2luZyB0byB1c2UgYmxvb20gZmlsdGVycyB0byBjb21wcmVzcyB0aGUgY2h1bmsg Yml0bWFwIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIHBlZXJzIGFuZCB0aGUgdHJhY2tl ci4gDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlbmctcHBzcC1iZmJp dG1hcC8gDQoNCkJlc2lkZXMgdGhlIGJhc2ljIGFsZ29yaXRobXMgYW5kIGhpZ2ggbGV2ZWwgbWVz c2FnZSBmbG93LCBpdCBhbHNvIHByb3ZpZGVzIGFuIGluaXRpYWwgZGlzY3Vzc2lvbiBvbiBob3cg dG8gaW50ZWdyYXRlIHdpdGggdGhlIGN1cnJlbnQgdHJhY2tlciBhbmQgcGVlciBwcm90b2NvbC4N Cg0KWW91ciBjb21tZW50cyB3b3VsZCBiZSBoaWdobHkgYXBwcmVjaWF0ZWQuDQoNCkJSDQpMaW5n bGkNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0 OiAyMDEz5bm0N+aciDPml6UgMTE6NTUNCuaUtuS7tuS6ujogRGVuZyBMaW5nbGk7IFl1bmZlaSBa aGFuZzsgSmluIFBlbmc7IExpbmdsaSBEZW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtZGVuZy1wcHNwLWJmYml0bWFwLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAtMDAudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpbmdsaSBEZW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZGVuZy1wcHNwLWJmYml0bWFwDQpSZXZp c2lvbjoJIDAwDQpUaXRsZToJCSBFZmZpY2llbnQgQ2h1bmsgQXZhaWxhYmlsaXR5IENvbXByZXNz aW9uIGZvciBQUFNQDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0wMw0KR3JvdXA6CQkgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRlbmctcHBzcC1iZmJpdG1h cC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXANCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZGVuZy1wcHNwLWJmYml0bWFwLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRvIGVtcGxveSBibG9vbSBmaWx0ZXIgYWxnb3Jp dGhtcyBpbg0KICAgY29tcHJlc3NpbmcgY2h1bmsgYXZhaWxhYmlsaXR5IGluZm9ybWF0aW9uIGlu IGV4Y2hhbmdlIGJldHdlZW4gcGVlcnMNCiAgIGFuZCB0aGUgdHJhY2tlciB0aHJvdWdoIHRoZSBQ UFNQLVRQIHByb3RvY29sIGFuZCBQUFNQUCBwcm90b2NvbC4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBz cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNwDQo= From denglingli@chinamobile.com Mon Jul 15 01:05:29 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D0221F9E3D for ; Mon, 15 Jul 2013 01:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.339 X-Spam-Level: * X-Spam-Status: No, score=1.339 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSNR+B66mJ8d for ; Mon, 15 Jul 2013 01:05:24 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 5F4CE21F8AA1 for ; Mon, 15 Jul 2013 01:05:20 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151e3ad04de7-dbde7; Mon, 15 Jul 2013 16:04:21 +0800 (CST) X-RM-TRANSID: 2ee151e3ad04de7-dbde7 Received: from cmccPC (unknown[10.2.43.200]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251e3ad032d7-393f2; Mon, 15 Jul 2013 16:04:21 +0800 (CST) X-RM-TRANSID: 2ee251e3ad032d7-393f2 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'Huangyihong \(Rachel\)'" , "'ppsp'" References: <007601ce77b0$aae81910$00b84b30$@com> <51E6A56BD6A85142B9D172C87FC3ABBB4584F0F1@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4584F0F1@nkgeml501-mbs.china.huawei.com> Date: Mon, 15 Jul 2013 16:05:17 +0800 Message-ID: <006a01ce8132$0b373b40$21a5b1c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac53ovWlHvdzdymjTROWhBQwN1+k8AAAK6BwAljTrCAACkUo8A== Content-Language: zh-cn Subject: [ppsp] =?utf-8?b?562U5aSNOiAg6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmlj?= =?utf-8?q?ation_for_draft-deng-ppsp-bfbitmap-00=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 08:05:29 -0000 Hi Rachel, Thanks a lot for your comments. Plz see my remarks inline below. I have uploaded a revision for the draft this morning. = http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-01.txt=20 Luckily, some of the issues you raised are fixed in this revision, some = are still await amendments^^ BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Huangyihong (Rachel) = [mailto:rachel.huang@huawei.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8815=E6=97=A5 = 15:25 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng; = 'ppsp' =E4=B8=BB=E9=A2=98: RE: [ppsp] =E8=BD=AC=E5=8F=91: New Version = Notification for draft-deng-ppsp-bfbitmap-00.txt Hi Lingli, It's a very interesting topic. It's very useful for messages with = ContentMap exchanges. Thanks for bring this. I have following comments = when I review it: 1. In section 3.1, the description following the figure 2 doesn't quite = correspond to the figure. For example, the item 3 and 4 couldn't be = found in the figure. And I think it's better to show the difference = between leech mode and seeder mode in the figure.=20 [dll] Both the figure and text description are updated and coordinated = in the 01 version. 2. I think section 4 should be placed in the section 3. Otherwise, = people will have the question why BF conf could be obtained from both = the portal and the tracker.=20 [dll] I modified the description to explain that the two are = alternatives to one question. 3. In section 3.2, clause a, I don't think the base TP protocol has JOIN = request message. [dll] You are right, I have corrected this in the 01 version. Thank you. 4. In section 3.2, clause b "Integration to the extended TP protocol", = there's no corresponding message (like FIND) found in the figure 3. [dll] FIND related messages are included in the revision. 5. In section 3.2, clause b, " Peers use the BF(S,m,H) algorithm for = indicating its query", should the "S" be replaced with "S'"? And what's = the difference between F(S) and BF(S). Sorry, I can't understand the = operation "F(S) equals (BF(S) bitwise OR (BF(S) bitwise XOR BF(S'))". I = think if BF(S') equals (BF(S) bitwise XOR BF(S'), the peer should be = included in the peer list of the FIND response. So would you clarify = more about it? [dll] You are right. There are typos around here. What I mean by "BF(S) = equals (BF(S) bitwise OR (BF(S) bitwise XOR BF(S'))", is the condition = that every marked bit in the array BF(S') is also marked in the array = BF(S), where BF(S) stands for the BF-bitmap stored at the tracker for = the peer in question "whether to be included in the returned peer list = for the FIND message or not". I shall try to add more clarification = about this point. 6. In section 4.1 option 1, there are some sentences have been = duplicated. It's an editorial error. [dll] Thanks for pointing it out. The duplication are removed. Best regards, Rachel -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of = =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng Sent: Wednesday, July 03, 2013 1:47 PM To: 'ppsp' Subject: [ppsp] =E8=BD=AC=E5=8F=91: New Version Notification for = draft-deng-ppsp-bfbitmap-00.txt Hi all, We have just submitted a new draft proposing to use bloom filters to = compress the chunk bitmap information exchanged between peers and the = tracker.=20 http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/=20 Besides the basic algorithms and high level message flow, it also = provides an initial discussion on how to integrate with the current = tracker and peer protocol. Your comments would be highly appreciated. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=883=E6=97=A5 = 11:55 =E6=94=B6=E4=BB=B6=E4=BA=BA: Deng Lingli; Yunfei Zhang; Jin Peng; Lingli = Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-deng-ppsp-bfbitmap-00.txt A new version of I-D, draft-deng-ppsp-bfbitmap-00.txt has been successfully submitted by Lingli Deng and posted to the IETF repository. Filename: draft-deng-ppsp-bfbitmap Revision: 00 Title: Efficient Chunk Availability Compression for PPSP Creation date: 2013-07-03 Group: Individual Submission Number of pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-deng-ppsp-bfbitmap-00.txt Status: = http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap Htmlized: http://tools.ietf.org/html/draft-deng-ppsp-bfbitmap-00 Abstract: This document proposes to employ bloom filter algorithms in compressing chunk availability information in exchange between peers and the tracker through the PPSP-TP protocol and PPSPP protocol. = =20 The IETF Secretariat _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp From rachel.huang@huawei.com Mon Jul 15 02:08:41 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A0121F99D2 for ; Mon, 15 Jul 2013 02:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLzGI9cSKBzk for ; Mon, 15 Jul 2013 02:08:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A167221F9EEE for ; Mon, 15 Jul 2013 02:05:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATL28561; Mon, 15 Jul 2013 09:05:06 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 10:04:18 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 10:05:05 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 17:05:02 +0800 From: "Huangyihong (Rachel)" To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= , "'ppsp'" Thread-Topic: =?utf-8?B?W3Bwc3BdIOi9rOWPkTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?utf-8?Q?raft-deng-ppsp-bfbitmap-00.txt?= Thread-Index: Ac53ovWlHvdzdymjTROWhBQwN1+k8AAAK6BwAljTrCAACkUo8AAChXOA Date: Mon, 15 Jul 2013 09:05:01 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4584F34B@nkgeml501-mbs.china.huawei.com> References: <007601ce77b0$aae81910$00b84b30$@com> <51E6A56BD6A85142B9D172C87FC3ABBB4584F0F1@nkgeml501-mbs.china.huawei.com> <006a01ce8132$0b373b40$21a5b1c0$@com> In-Reply-To: <006a01ce8132$0b373b40$21a5b1c0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ppsp-bfbitmap-00=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:08:41 -0000 SGkgbGluZ2xpLA0KDQpUaGUgY2hhbmdlcyB5b3UgbWFkZSBtYWtlIHNlbnNlIHRvIG1lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpSYWNoZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTog6YKT54G16I6JL0xpbmdsaSBEZW5nIFttYWlsdG86ZGVuZ2xpbmdsaUBjaGluYW1vYmlsZS5j b21dIA0KU2VudDogTW9uZGF5LCBKdWx5IDE1LCAyMDEzIDQ6MDUgUE0NClRvOiBIdWFuZ3lpaG9u ZyAoUmFjaGVsKTsgJ3Bwc3AnDQpTdWJqZWN0OiDnrZTlpI06IFtwcHNwXSDovazlj5E6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGVuZy1wcHNwLWJmYml0bWFwLTAwLnR4dA0K DQpIaSBSYWNoZWwsDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciBjb21tZW50cy4gUGx6IHNlZSBt eSByZW1hcmtzIGlubGluZSBiZWxvdy4NCkkgaGF2ZSB1cGxvYWRlZCBhIHJldmlzaW9uIGZvciB0 aGUgZHJhZnQgdGhpcyBtb3JuaW5nLiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAtMDEudHh0IA0KTHVja2lseSwgc29tZSBvZiB0aGUg aXNzdWVzIHlvdSByYWlzZWQgYXJlIGZpeGVkIGluIHRoaXMgcmV2aXNpb24sIHNvbWUgYXJlIHN0 aWxsIGF3YWl0IGFtZW5kbWVudHNeXg0KDQpCUg0KTGluZ2xpDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogSHVhbmd5aWhvbmcgKFJhY2hlbCkgW21haWx0bzpyYWNoZWwuaHVh bmdAaHVhd2VpLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMTXml6UgMTU6MjUNCuaU tuS7tuS6ujog6YKT54G16I6JL0xpbmdsaSBEZW5nOyAncHBzcCcNCuS4u+mimDogUkU6IFtwcHNw XSDovazlj5E6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGVuZy1wcHNwLWJm Yml0bWFwLTAwLnR4dA0KDQpIaSBMaW5nbGksDQoNCkl0J3MgYSB2ZXJ5IGludGVyZXN0aW5nIHRv cGljLiBJdCdzIHZlcnkgdXNlZnVsIGZvciBtZXNzYWdlcyB3aXRoIENvbnRlbnRNYXAgZXhjaGFu Z2VzLiBUaGFua3MgZm9yIGJyaW5nIHRoaXMuICBJIGhhdmUgZm9sbG93aW5nIGNvbW1lbnRzIHdo ZW4gSSByZXZpZXcgaXQ6DQoNCjEuIEluIHNlY3Rpb24gMy4xLCB0aGUgZGVzY3JpcHRpb24gZm9s bG93aW5nIHRoZSBmaWd1cmUgMiBkb2Vzbid0IHF1aXRlIGNvcnJlc3BvbmQgdG8gdGhlIGZpZ3Vy ZS4gRm9yIGV4YW1wbGUsIHRoZSBpdGVtIDMgYW5kIDQgY291bGRuJ3QgYmUgZm91bmQgaW4gdGhl IGZpZ3VyZS4gQW5kIEkgdGhpbmsgaXQncyBiZXR0ZXIgdG8gc2hvdyB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIGxlZWNoIG1vZGUgYW5kIHNlZWRlciBtb2RlIGluIHRoZSBmaWd1cmUuIA0KW2RsbF0g Qm90aCB0aGUgZmlndXJlIGFuZCB0ZXh0IGRlc2NyaXB0aW9uIGFyZSB1cGRhdGVkIGFuZCBjb29y ZGluYXRlZCBpbiB0aGUgMDEgdmVyc2lvbi4NCg0KMi4gSSB0aGluayBzZWN0aW9uIDQgc2hvdWxk IGJlIHBsYWNlZCBpbiB0aGUgc2VjdGlvbiAzLiBPdGhlcndpc2UsIHBlb3BsZSB3aWxsIGhhdmUg dGhlIHF1ZXN0aW9uIHdoeSBCRiBjb25mIGNvdWxkIGJlIG9idGFpbmVkIGZyb20gYm90aCB0aGUg cG9ydGFsIGFuZCB0aGUgdHJhY2tlci4gDQpbZGxsXSBJIG1vZGlmaWVkIHRoZSBkZXNjcmlwdGlv biB0byBleHBsYWluIHRoYXQgdGhlIHR3byBhcmUgYWx0ZXJuYXRpdmVzIHRvIG9uZSBxdWVzdGlv bi4NCg0KMy4gSW4gc2VjdGlvbiAzLjIsIGNsYXVzZSBhLCBJIGRvbid0IHRoaW5rIHRoZSBiYXNl IFRQIHByb3RvY29sIGhhcyBKT0lOIHJlcXVlc3QgbWVzc2FnZS4NCltkbGxdIFlvdSBhcmUgcmln aHQsIEkgaGF2ZSBjb3JyZWN0ZWQgdGhpcyBpbiB0aGUgMDEgdmVyc2lvbi4gVGhhbmsgeW91Lg0K DQo0LiBJbiBzZWN0aW9uIDMuMiwgY2xhdXNlIGIgIkludGVncmF0aW9uIHRvIHRoZSBleHRlbmRl ZCBUUCBwcm90b2NvbCIsIHRoZXJlJ3Mgbm8gY29ycmVzcG9uZGluZyBtZXNzYWdlIChsaWtlIEZJ TkQpIGZvdW5kIGluIHRoZSBmaWd1cmUgMy4NCltkbGxdIEZJTkQgcmVsYXRlZCBtZXNzYWdlcyBh cmUgaW5jbHVkZWQgaW4gdGhlIHJldmlzaW9uLg0KDQo1LiBJbiBzZWN0aW9uIDMuMiwgY2xhdXNl IGIsICIgUGVlcnMgdXNlIHRoZSBCRihTLG0sSCkgYWxnb3JpdGhtIGZvciBpbmRpY2F0aW5nIGl0 cyBxdWVyeSIsIHNob3VsZCB0aGUgIlMiIGJlIHJlcGxhY2VkIHdpdGggIlMnIj8gQW5kIHdoYXQn cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIEYoUykgYW5kIEJGKFMpLiBTb3JyeSwgSSBjYW4ndCB1 bmRlcnN0YW5kIHRoZSBvcGVyYXRpb24gIkYoUykgZXF1YWxzIChCRihTKSBiaXR3aXNlIE9SIChC RihTKSBiaXR3aXNlIFhPUiBCRihTJykpIi4gSSB0aGluayBpZiBCRihTJykgZXF1YWxzIChCRihT KSBiaXR3aXNlIFhPUiBCRihTJyksIHRoZSBwZWVyIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUg cGVlciBsaXN0IG9mIHRoZSBGSU5EIHJlc3BvbnNlLiBTbyB3b3VsZCB5b3UgY2xhcmlmeSBtb3Jl IGFib3V0IGl0Pw0KW2RsbF0gWW91IGFyZSByaWdodC4gVGhlcmUgYXJlIHR5cG9zIGFyb3VuZCBo ZXJlLiBXaGF0IEkgbWVhbiBieSAiQkYoUykgZXF1YWxzIChCRihTKSBiaXR3aXNlIE9SIChCRihT KSBiaXR3aXNlIFhPUiBCRihTJykpIiwgaXMgdGhlIGNvbmRpdGlvbiB0aGF0IGV2ZXJ5IG1hcmtl ZCBiaXQgaW4gdGhlIGFycmF5IEJGKFMnKSBpcyBhbHNvIG1hcmtlZCBpbiB0aGUgYXJyYXkgQkYo UyksIHdoZXJlIEJGKFMpIHN0YW5kcyBmb3IgdGhlIEJGLWJpdG1hcCBzdG9yZWQgYXQgdGhlIHRy YWNrZXIgZm9yIHRoZSBwZWVyIGluIHF1ZXN0aW9uICJ3aGV0aGVyIHRvIGJlIGluY2x1ZGVkIGlu IHRoZSByZXR1cm5lZCBwZWVyIGxpc3QgZm9yIHRoZSBGSU5EIG1lc3NhZ2Ugb3Igbm90Ii4gSSBz aGFsbCB0cnkgdG8gYWRkIG1vcmUgY2xhcmlmaWNhdGlvbiBhYm91dCB0aGlzIHBvaW50Lg0KDQo2 LiBJbiBzZWN0aW9uIDQuMSBvcHRpb24gMSwgdGhlcmUgYXJlIHNvbWUgc2VudGVuY2VzIGhhdmUg YmVlbiBkdXBsaWNhdGVkLiBJdCdzIGFuIGVkaXRvcmlhbCBlcnJvci4NCltkbGxdIFRoYW5rcyBm b3IgcG9pbnRpbmcgaXQgb3V0LiBUaGUgZHVwbGljYXRpb24gYXJlIHJlbW92ZWQuDQoNCkJlc3Qg cmVnYXJkcywNClJhY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcHBz cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2Yg6YKT54G16I6JL0xpbmdsaSBEZW5nDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDMsIDIw MTMgMTo0NyBQTQ0KVG86ICdwcHNwJw0KU3ViamVjdDogW3Bwc3BdIOi9rOWPkTogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAtMDAudHh0DQoNCkhp IGFsbCwNCg0KV2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBwcm9wb3NpbmcgdG8g dXNlIGJsb29tIGZpbHRlcnMgdG8gY29tcHJlc3MgdGhlIGNodW5rIGJpdG1hcCBpbmZvcm1hdGlv biBleGNoYW5nZWQgYmV0d2VlbiBwZWVycyBhbmQgdGhlIHRyYWNrZXIuIA0KaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAvIA0KDQpCZXNpZGVz IHRoZSBiYXNpYyBhbGdvcml0aG1zIGFuZCBoaWdoIGxldmVsIG1lc3NhZ2UgZmxvdywgaXQgYWxz byBwcm92aWRlcyBhbiBpbml0aWFsIGRpc2N1c3Npb24gb24gaG93IHRvIGludGVncmF0ZSB3aXRo IHRoZSBjdXJyZW50IHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2wuDQoNCllvdXIgY29tbWVudHMg d291bGQgYmUgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQpCUg0KTGluZ2xpDQoNCi0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxM+W5tDfmnIgz5pel IDExOjU1DQrmlLbku7bkuro6IERlbmcgTGluZ2xpOyBZdW5mZWkgWmhhbmc7IEppbiBQZW5nOyBM aW5nbGkgRGVuZw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRl bmctcHBzcC1iZmJpdG1hcC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt ZGVuZy1wcHNwLWJmYml0bWFwLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBMaW5nbGkgRGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpG aWxlbmFtZToJIGRyYWZ0LWRlbmctcHBzcC1iZmJpdG1hcA0KUmV2aXNpb246CSAwMA0KVGl0bGU6 CQkgRWZmaWNpZW50IENodW5rIEF2YWlsYWJpbGl0eSBDb21wcmVzc2lvbiBmb3IgUFBTUA0KQ3Jl YXRpb24gZGF0ZToJIDIwMTMtMDctMDMNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiAxMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAtMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGVuZy1wcHNw LWJmYml0bWFwDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWRlbmctcHBzcC1iZmJpdG1hcC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBwcm9wb3NlcyB0byBlbXBsb3kgYmxvb20gZmlsdGVyIGFsZ29yaXRobXMgaW4NCiAgIGNvbXBy ZXNzaW5nIGNodW5rIGF2YWlsYWJpbGl0eSBpbmZvcm1hdGlvbiBpbiBleGNoYW5nZSBiZXR3ZWVu IHBlZXJzDQogICBhbmQgdGhlIHRyYWNrZXIgdGhyb3VnaCB0aGUgUFBTUC1UUCBwcm90b2NvbCBh bmQgUFBTUFAgcHJvdG9jb2wuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCg0K From r.petrocco@gmail.com Mon Jul 15 10:21:00 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E611E8138 for ; Mon, 15 Jul 2013 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_LIST=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gsa7itvFvoR for ; Mon, 15 Jul 2013 10:20:57 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id CC53011E80AD for ; Mon, 15 Jul 2013 10:20:55 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so10260115wgh.3 for ; Mon, 15 Jul 2013 10:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EUo4OJp3dt/G2u+TmLZxMCyO//Nufze2+YnnSLvLjGQ=; b=JjXKL6bg3j4JPwLaDnv/g95nLTkmHcWEN+NaIVURpSbeeCg7jSRsx4MkxCM4o9aH9N +wg5AZsbgRUfyl66ZGT3EOzWdcT/ObYF3h8q8cbU5wU8wCTzK1egkQls0iTJnmZ1SVwX l36qgY3lQhOf1Ddg6jDQPnivDTFhh9vhQrHdRXgSOuM7na1hHAOgQoPHq1CDaXF4++Dw 0tgO8FGC/vDpdeUFE3LJ0wHa31z1MXQxli2jBUe3RaQjVweeQXoIbR5SIr+jpGpmT20F rzBPyxF+1t/t28hYN/IQ6CogUSdOMrR1H2yCGbg8ciG5EMOvwRWnf6TQ+eD1ME2q8QuU wdNw== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr9536815wie.46.1373908854891; Mon, 15 Jul 2013 10:20:54 -0700 (PDT) Received: by 10.194.236.38 with HTTP; Mon, 15 Jul 2013 10:20:54 -0700 (PDT) In-Reply-To: <20130715165826.16712.69876.idtracker@ietfa.amsl.com> References: <20130715165826.16712.69876.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 19:20:54 +0200 Message-ID: From: Riccardo Petrocco To: ppsp Content-Type: multipart/alternative; boundary=bcaec53f2e313fed1404e190158b Subject: [ppsp] Fwd: New Version Notification for draft-ietf-ppsp-peer-protocol-07.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:21:00 -0000 --bcaec53f2e313fed1404e190158b Content-Type: text/plain; charset=ISO-8859-1 Hi all, I just uploaded an updated version of the peer protocol draft. We mostly focused on the issues presented in the recent AD review. Unfortunately due to the lack of time, and the extensive review, some points still need to be addressed. See you in Berlin, ciao, Riccardo ========================= -07 2013-06-19 Revision following AD Review Quoting the AD review by Martin Stiemerling: ***High-level issues: 1) Merkle Hash Trees I have found the document very confusing on whether Merkle Hash Trees (MHTs) and the for the MHT required bin numbering scheme are now optional or mandatory. Parts of the draft make the impression that either of them or both or optional (mainly in the beginning of the document), while Section 5 and later Sections are relying heavily on MHTs. My naive reading of the current draft is that you could rely on start-end ranges for chunk addressing and MHTs for content protection. However, I do know that this combination is not working. If MHTs are really optional, including the bin numbering, the document should really state this and make clear what the operations of the protocol are with the mandatory to implement (MTI) mechanisms. The MHT, bins, and all the protocol handling should go in an appendix. There is a call to make for the WG: I do know that MHTs were considered by some as burden and they have called for a leaner way, i.e., the start-end ranges. The call for the leaner way has been implemented in the document but not fully. + The text now states that MHTs SHOULD be used unless in benign environments and are mandatory-to-implement. It also states that only start-end chunk range is mandatory- to-implement, and bins are optional. 2) LEDBAT as congestion control vs. PPSPP The PPSP peer protocol is intended for the Standards Track and relies in a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an **experimental** delay-based congestion control algorithm. A Standards Track protocol cannot normatively rely on an Experimental congestion control mechanism (or RFC in general). There are ways out of this situation: i) Do not use ledbat: this would call for another congestion control mechanism to be described in the PPSPP draft. ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track: Possible, but a very long way. iii) Agree on having PPSPP also as Experimental protocol. I'm currently leaning towards option iii), but this is my pure personal opinion as an individual in the IETF. + A new paragraph has been added to Section 8.16 describing the feasibility of LEDBAT in P2P systems. 3) No formal protocol message definition Section 7 and more specific Section 8 describe the protocol syntax of the protocol options and the messages, though Section 8 is talking about UDP encapsulation. Section 7 is hard to digest if someone should implement the options, see also later, but Section 8 is almost impossible to understand by somebody who has not been involved in the PPSP working group. See also further down for a more detailed review of the sections. To give an example out of Section 8.4: This section describes the HANDSHAKE message and gives examples how such a HANDSHAKE message could look like. But no formal definition of the message is given leaving a number of thins unclear, such as what the local channel number and what's the remote channel number is. This is implicitly defined, but that is not a good way of writing Standards Track drafts. 4) Implicit use of default values There are a number of places all over the draft where default values are defined. Many of those default values are used when there are no values explicitly signaled, e.g., the default chunk size of 1 Kbyte in Section 8.4 or Section Section 7.5. with the default for the Content Integrity Protection Method. I have the feeling that the protocol and the surroundings (e.g., what comes in via the 'tracker') are over-optimized, e.g., always providing the Content Integrity Protection Method as part of the Protocol options will not waste more than 2 bytes in a HANDSHAKE message. Further, I do not see the need to define a default chunk size in the base protocol specification, as this default can look very different, depending on who is deploying the protocol and in what context. This calls for a more dynamic way of handling the system chunk size, either as part of an external mechanisms (e.g. via the tracker) or in the HANDSHAKE message. + Removed implicit defaults from protocol options. Chunk size is part of the content's metadata and thus configurable. The default 1KiB has been turned into a recommendation. 5) Concept of channels The concept of channels is good but it is introduced too late in the draft, namely in Section 8.3, and it is introduced with very few words. Why isn't this introduced as part of Section 2 or Section 3, also in the relationship to the used transport protocol? I.e., the intention is to keep only one transport 'connection' between two distinct peers and to allow to run multiple swarm instances at the same time over the same transport. And how do swarms and channels correlate? + Concept now introduced in Section 3 with a figure. ***Technicals: - Section 2.1, 2nd paragraph, about the tracker: I haven't seen a single place where the interaction with a tracker is discussed or where the tracker less operation is discussed in contrast. It is further unclear what type of information is really required from a tracker. A tracker (or a resource directory) would need to provide more then IP address & port, e.g., the used transport protocol for the protocol exchange (given that other transports are allowed), used chunk size, chunk addressing scheme, etc - Section 2.3, the 1st paragraph, 'close-channel': This has been the first time where I stumbled over the channel without knowing the concept. + Rephrased. - Section 3.1: ordering of messages The 1st sentence implies that ordering of messages in a datagram matters a lot. This is outlined later in the document, but I would add this as part of 3., i.e., the messages are processed in the strict order or something along this line. - Section 3.1, 1st paragraph, options to include I would not say anything about 'SHOULD include options' here, as this is anyhow described in Section 8. + Phrase removed. - Section 3.1, 2nd paragraph: "Datagrams exchanged MAY also contain some minor payload, e.g. HAVE messages to indicate the current progress of a peer or a REQUEST (see Section 3.7)." to be added, just to make it clear IMHO: ", but MUST NOT include any DATA message". + Added. - Section 3.2, 2nd paragraph: "In particular, whenever a receiving peer has successfully checked the integrity of a chunk or interval of chunks it MUST send a HAVE message to all peers it wants to interact with in the near future." This looks like a place where a lot of traffic can be send out of a peer, i.e., whenever a chunk arrives a HAVE message must be sent. I don't believe that this should be mandated by the protocol specification, but there should guidance on when to send this, e.g., peers might be also able to wait for a short period of time to gather more chunks to be reported in HAVE. Or should in this case a single UDP datagram contain multiple HAVEs? + Clarified. - Section 3.4 on ACKs This section looks pretty weak, as ACKs may be sent but on the other hand MUST be sent if ledbat is used. I would simply say: - ACK MUST be sent if an unreliable transport protocol is used - ACK MAY be sent if a reliable transport protocol is used - keep clarification about ledbat. + DONE. - Section 3.5: Give text where INTEGERITY is described at least for the MTI scheme. + DONE. - Section 3.7, 2nd paragraph - all 'MAY' are actually not right here. Please remove or replace them with lower letters if appropriate. - It is not clear what the 'sequentially' means exactly. Is it in the received order? + First point TODO. "Sequentially" replaced with "received order". - Section 3.8: Please replace 'MAY' by can, as those are not normative behaviors but more the fact that peers can, for instance, request urgent data. + DONE. - Section 3.9 Same comment as for the Section 3.8 just above this comment. + DONE. - Section 3.9 waiting for responses OLD " When peer B receives a CHOKE message from A it MUST NOT send new REQUEST messages and SHOULD NOT expect answers to any outstanding ones." NEW " When peer B receives a CHOKE message from A it MUST NOT send new REQUEST messages and it cannot expect answers to any outstanding ones, as the transfer of chunks is choked." + DONE. - Section 3.10.2 This whole section about PEX hole punching reads very, very experimental. The STUN method is ok, but PEX isn't. First of all, the safe behavior for a peer when it receives unsolicited PEX messages, is to discard those messages. Second, this unsolicited PEX messages trigger some behavior which may open an attack vector. The best way, but this needs more discussion, is to include to some token in the messages that are exchanged in order to make avoid any blind attacks here. However, this will need more and detailed discussions of the purpose of this. + TODO: hole punching comment. + We moved parts of the security analysis of PEX up, such that all mechanisms are explained in the main text, and the analysis of what attacks there are and how these mechanisms prevent them is in the Sec. Considerations section. - Section 3.11 I don't see the 'MUST send keep-alive' as a mandatory requirement, as peers might have good reasons not to send any keep alive. Why not saying 'A peer can send a keep-alive' and it 'MUST use the simple datagram...' as already described. Though there is also no really need to say MUST. + Now Section 3.12. Rephrased and clarified the reason and consequences of sending keep-alive msgs. - Section 4 The syntax definition for each of the chunk addressing schemes is missing. This is not suitable for any specification that aims at interoperable implementations. - Section 4.3.2 PPSPP peers MUST use the ACK message if an unreliable transport protocol is used. + DONE. - Section 4.4 Has been tested in an implementation? I would like to understand the need for such a section, as in my understanding a peer implementation should chose one scheme and support this and there shouldn't be the need to convert between the different schemes. - Section 5 This reads that MHTs are mandatory to implement while the document makes the impression that MHTs are optional. + Rephrased, see High-level issues. - Section 5.3 " so each datagram SHOULD be processed separately and a loss of one datagram MUST NOT disrupt the flow" The MUST NOT is not a protocol specification requirement, but more an informative part saying that a lost message shouldn't impact the protocol machinery, but it can impact the overall operation. What is the flow here in that sentence? + Rephrased. - Section 5.6.2. An illustrative example explaining how the automatic size detection works is required here. + Added a paragraph with an example that follows the figure used during the explanation. A state diagram could also be added, but bight be a bit redundant. - Section 6.1, 4th paragraph: Where do I find the 1 byte algorithm field in the swarm ID? The swarm ID is not really defined in a single place. + Expanded. TODO: Formal spec of swarm ID. - Section 7.3 The described min/max versioning relies on the fact that there are major and minor version numbers. I cannot find any major and minor version number scheme in the draft. + Actually, it does not. - Section 7.4, Length field It is not clear what the 'Length' field is referring to. Further, it is not clear of the swam IDs are concatenated in one swarm ID option, of each swarm ID must be placed in a separate swam ID option. - Section 7.6 MHTs are mandatory to support though MHTs are optional? + Clarified. - Section 7.7 'key size ... derived from the swarm ID'. This relates to my high level comment no 4. on the use of implicit information. Either it is clearly specified how this information is derived or there is a protocol field/ information about the size. + Key size derivation procedure added to description of SIGNED_INTEGRITY in UDP encapsulation. - Section 7.8 I would recommend to say that the default MUST be supported, but the peer must always signal what method it is supporting or at least using. + Corrected, see High-level issues 4.) - Section 7.10 I have not understood how the 'Lenght' field relates to the message bitmap and how long the message bitmap can grow. The figure looks like a maximum of 16 bits? + Clarified. - Section 8 I do not see the value of the text in the preface of Section 8. I would say that this text should say what is mandatory and what's not, i.e., MUST use UDP and MUST use LEDBAT. Potentially saying that future protocol versions can also run over other transport protocols. + Adjusted. - Section 8.1 about Maximum Transfer Unit (MTU) The text is discussing that a Ethernet can carry 1500 bytes. This is true, but the Ethernet payload is not the normative MTU across all of the Internet. For IPv6 the min MTU is 1280 bytes and for IPv4 it is 576 bytes, though for IPv4 it can be theoretically much lower at 64 bytes. It would move the definition of the default chunk size to a recommendation with text saying that this size has a high likelihood to travel end-to-end in the Internet without any fragmentation. Fragmentation might increase the loss of complete chunks, as one lost fragment will cause the loss of a complete chunk. One way of getting an informed decision on whether chunks can travel in their size is to use the Don't Fragment (DF) bit in IPv4 and also to watch for ICMP error messages. However, ICMP error messages are not a reliable indication, but they can be some indication. + 1 KiB chunk size has been made a recommendation. - Section 8.1 Definition of the default chunk size There is no need to define a default chunk size, if the chunk size would be always signaled per swarm. This is another default/ implicit value places that is unnecessary. + The chunk size is always part of the content's metadata. - Section 8.3: see also my comment no 3. The concept of channels is introduced very late and with few words. A figure to explain the concept will help a lot and also more formal text on what a channel is and how they are identified. Also what the init channel is. + Concept now introduced in Section 3.11. TODO init channel. - Section 8 in general: There is no formal definition of the messages, just bit pattern examples. - Section 8.4 (as example for the other Sections in 8.x): i) What is the '(CHANNEL' paramter? Is it actually a parameter? ii) it is implicit that the first channel no (0000000) is the remote peer's channel and that the second channel no (00000011) is the local peer's channel, right? This isn't clear from the text, but my guess. - Section 8.5 Can HAVE messages multiple bin specs in one message or do I have to make a HAVE message for each bin? + Clarified. - Section 8.6 What is the formal defintion of a DATA message? That's completely missing or I have not understood it. - Section 8.7 looks just underspecified, especially as this is the link to LEDBAT. - Section 8.11 How are the chunks specified here? The formal syntax definition or reference to one is missing. - Section 8.13 I'm lost on this section, as I haven't fully understood the concept of the PEX in this document. Especially not why there is the PEX_REScert. + We moved parts of the security analysis of PEX up into 3.10, such that all mechanisms are explained in the main text, and the analysis of what attacks there are and how these mechanisms prevent them is in the Sec. Considerations section. - Section 11 The RFC required for protocol extensions of a standards track protocol looks odd. This must be at least IETF Review or Standards Action. ***Editorials: - Abstract (and probably also other places), 1st sentence of, PPSPP is not a transport protocol, just a protocol + DONE - Section 1.1, 4th paragraph: I would remove the reference to rmcat, as it is not yet clear what the outcome of the rmcat wg will be + DONE - Section 1.3, on page 8, about seeding/leeching: I would break it in to sub-bullets. + DONE - Section 2.1 and following: These are examples, isn'it? If so, this should be mentioned or clarified. + DONE. All subsections now labeled "Example:". - Section 2.1: What is the PPSP Url? - Section 2.3, the 1st paragraph, detection of dead peers: It would be good to say where this detection is described in the remainder of the draft. Just for completeness. + DONE. Dead peer detection is now a separate section and referenced here. - Section 2.2, the very last paragraph, 'Peer A MAY also': This 'MAY' is not useful here. I would just write 'Peer A can also', as there is nothing normative described here. + DONE - Section 3.2, last paragraph: What is the latter confinement? This is not clear to me. + Rephrased. - Section 3.9, last sentence I am not sure to what the reference to Section 3.7 is pointing in this respect. + Rephrased. - Section 3.10.1 about PEX messages The text says 'PPSPP optionally features...'. I have not understood if this optionally refers to mandatory to implement but optionally to use, or if the PEX messages are optionally to implement. + Made it clear that is OPTIONAL and not mandatory-to- implement. - Section 3.12 I'm not sure what this section is telling exactly. Isn't just saying that PPSPP as such does not care how chunks are stored locally, as this is implementation dependent? + Yes. Removed. - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer MAY support' NEW 'The support for this scheme is OPTIONAL' + DONE, for byte ranges as well. - Section 6.1.1 This section is not describing sign-all, but rather a justification why it may still work. This doesn't help at all. - Section 7, 1st paragraph Why is there a reference to RFC 2132? + Removed, just similarity in format. - Section 7 in general i) It is common to give bit positions in the figures where the syntax of options is described. This allows to count how many bits are used for a protocol field more easily and also way more reliable. ii) Please add also Figure labels to the syntax definitions of the options. This makes it easier to reference them later on if needed. - Section 8.1 1 kibibyte is 1 kbyte? + We follow ISO/IEC 80000-13 to avoid the kilo = 1000 or 1024 confusion. - Section 8.2, last paragraph i ) "All messages are idempotent" in what respect? ii) "or recognizable as duplicates" but how are the recognized as duplicates? + Idempotent means that processing a message twice does not lead to a different state than processing them once. Resent handshakes can be recognized as duplicates because a peer already recorded the first connection attempt in its state. Updated text. - Section 8.5, last sentence in brackets: What is this last sentence about? - Section 8.13 " If sender of the PEX_REQ message does not have a private or link-local address, then the PEX_RES* messages MUST NOT contain such addresses [RFC1918][RFC4291]." What is this text saying? Do not include what you do not have anyway? + Rephrased. It tries to say that internal addresses must not be leaked to external peers. - Section 8.14 There is no single place where all the constants are collected and also documented what the default values or the recommended values. For instance in this Section 8.14 where the dead peer time out is set to 3 minutes and also the number of datagrams that should have sent. I would make a section or subsection to discuss dead peers and how they are detected and just link to the keep-alive mechanism in Section 8.14. + A new section Section 12.1.1.1 "Summary of Default Values" was created for this in the Ops & Mgmt part. - Section 11 This section needs to be overhauled once the document is ready for the IESG. The section is not wrong but can be improved to help IANA. ---------- Forwarded message ---------- From: Date: 2013/7/15 Subject: New Version Notification for draft-ietf-ppsp-peer-protocol-07.txt To: Riccardo Petrocco , Arno Bakker , Victor Grishchenko A new version of I-D, draft-ietf-ppsp-peer-protocol-07.txt has been successfully submitted by Arno Bakker and posted to the IETF repository. Filename: draft-ietf-ppsp-peer-protocol Revision: 07 Title: Peer-to-Peer Streaming Peer Protocol (PPSPP) Creation date: 2013-07-15 Group: ppsp Number of pages: 84 URL: http://www.ietf.org/internet-drafts/draft-ietf-ppsp-peer-protocol-07.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol Htmlized: http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ppsp-peer-protocol-07 Abstract: The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both pre-recorded (on-demand) and live audio/video content. It is based on the peer- to-peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user, and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using LEDBAT for congestion control. The IETF Secretariat --bcaec53f2e313fed1404e190158b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I just uploaded a= n updated version of the peer protocol draft.

We mostly focuse= d on the issues presented in the recent AD review.
Unfortunately d= ue to the lack of time, and the extensive review, some points still need to= be addressed.

See you in Berlin,
ciao,
Riccardo


=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= =A0 -07=A0=A0=A0=A0=A0=A0=A0 2013-06-19 Revision following AD Review
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Quoting the AD review by Martin Stiemerling= : ***High-level
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 issues:

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 1) Merkle Hash Trees I have found the document very confusing
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 on whether Merkle Hash Trees (MHTs) and the for th= e MHT
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 required bin numbering scheme are n= ow optional or mandatory.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Parts of the draft make the impression that = either of them or
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 both or optional (mainl= y in the beginning of the document),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 whil= e Section 5 and later Sections are relying heavily on
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MHTs.=A0 My naive reading of the current dra= ft is that you
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 could rely on start-end ra= nges for chunk addressing and MHTs
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for co= ntent protection.=A0 However, I do know that this
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 combination is not working.=A0 If MHTs are really optional,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 including the bin numbering, the document sh= ould really state
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this and make clear wha= t the operations of the protocol are
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 with= the mandatory to implement (MTI) mechanisms.=A0 The MHT,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bins, and all the protocol handling should g= o in an appendix.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 There is a call to make= for the WG: I do know that MHTs were
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 con= sidered by some as burden and they have called for a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 leaner way, i.e., the start-end ranges.=A0 T= he call for the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 leaner way has been imple= mented in the document but not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fully.
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 The text now states that MHTs SH= OULD be used unless in
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 benign environments and are mand= atory-to-implement.=A0 It
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 als= o states that only start-end chunk range is mandatory-
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 to-implement, and bins are optional.

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 2) LEDBAT as congestion control vs. PPSPP The P= PSP peer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 protocol is intended for the Standards Track= and relies in a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 normative manner on LEDB= AT (RFC 6817).=A0 LEDBAT as such is an
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 **= experimental** delay-based congestion control algorithm.=A0 A
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Standards Track protocol cannot normatively = rely on an
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Experimental congestion contro= l mechanism (or RFC in
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 general).=A0 There= are ways out of this situation: i) Do not
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 use ledbat: this would call for another congestion control
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mechanism to be described in the PPSPP draft= . ii) Work on an
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 'upgrade' of the= LEDBAT specification to Standards Track:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Possible, but a very long way. iii) Agree on having PPSPP
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 also as Experimental protocol.=A0 I'm cu= rrently leaning towards
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 option iii), but = this is my pure personal opinion as an
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in= dividual in the IETF.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 A new p= aragraph has been added to Section 8.16 describing
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the feasibility of LEDBAT in P2P= systems.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3) No formal protocol messa= ge definition Section 7 and more
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 specific= Section 8 describe the protocol syntax of the
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 protocol options and the messages, though Section 8 is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 talking about UDP encapsulation.=A0 Section = 7 is hard to digest
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if someone should imp= lement the options, see also later, but
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 S= ection 8 is almost impossible to understand by somebody who
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 has not been involved in the PPSP working gr= oup.=A0 See also
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 further down for a more = detailed review of the sections.=A0 To
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 gi= ve an example out of Section 8.4: This section describes
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the HANDSHAKE message and gives examples how= such a HANDSHAKE
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 message could look like= .=A0 But no formal definition of the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mess= age is given leaving a number of thins unclear, such as
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 what the local channel number and what's= the remote channel
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 number is.=A0 This is= implicitly defined, but that is not a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 go= od way of writing Standards Track drafts.

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 4) Implicit use of default values There are a number of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 places all over the draft where default valu= es are defined.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Many of those default val= ues are used when there are no
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 values exp= licitly signaled, e.g., the default chunk size of 1
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Kbyte in Section 8.4 or Section Section 7.5. with the default<= br> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for the Content Integrity Protection Method.= =A0 I have the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 feeling that the protocol = and the surroundings (e.g., what
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 comes in= via the 'tracker') are over-optimized, e.g., always
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 providing the Content Integrity Protection M= ethod as part of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the Protocol options wil= l not waste more than 2 bytes in a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 HANDSH= AKE message.=A0 Further, I do not see the need to define
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a default chunk size in the base protocol sp= ecification, as
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this default can look ver= y different, depending on who is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 deployin= g the protocol and in what context.=A0 This calls for a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 more dynamic way of handling the system chun= k size, either as
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 part of an external mec= hanisms (e.g. via the tracker) or in
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the = HANDSHAKE message.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Removed im= plicit defaults from protocol options.=A0 Chunk
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 size is part of the content'= s metadata and thus
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 configura= ble.=A0 The default 1KiB has been turned into a
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 recommendation.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 5)= Concept of channels The concept of channels is good but it
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is introduced too late in the draft, namely = in Section 8.3,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and it is introduced with= very few words.=A0 Why isn't this
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in= troduced as part of Section 2 or Section 3, also in the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 relationship to the used transport protocol?= =A0 I.e., the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 intention is to keep only o= ne transport 'connection' between
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= two distinct peers and to allow to run multiple swarm
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 instances at the same time over the same tra= nsport.=A0 And how
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 do swarms and channels= correlate?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Concept now intro= duced in Section 3 with a figure.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ***= Technicals:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 2.1, 2nd paragraph, about the = tracker: I haven't
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 seen a single plac= e where the interaction with a tracker is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= discussed or where the tracker less operation is discussed in
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 contrast.=A0 It is further unclear what type= of information is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 really required from a= tracker.=A0 A tracker (or a resource
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 dir= ectory) would need to provide more then IP address & port,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 e.g., the used transport protocol for the pr= otocol exchange
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (given that other transpo= rts are allowed), used chunk size,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 chunk = addressing scheme, etc

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 2.3,= the 1st paragraph, 'close-channel': This has
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 been the first time where I stumbled over th= e channel without
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 knowing the concept.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Rephrased.

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 - Section 3.1: ordering of messages The 1st sentence imp= lies
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that ordering of messages in a datagram matt= ers a lot.=A0 This
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is outlined later in t= he document, but I would add this as
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 part= of 3., i.e., the messages are processed in the strict
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 order or something along this line.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.1, 1st paragraph, options to inc= lude I would not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 say anything about '= SHOULD include options' here, as this is
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 anyhow described in Section 8.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Phrase removed.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 - Section 3.1, 2nd paragraph: "Datagrams exchang= ed MAY also
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 contain some minor payload, e= .g.=A0 HAVE messages to indicate
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the curr= ent progress of a peer or a REQUEST (see Section
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3.7)." to be added, just to make it cle= ar IMHO: ", but MUST
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NOT include any= DATA message".

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Added.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.2, 2nd paragraph: "In= particular, whenever a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 receiving peer has successfully checked the = integrity of a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 chunk or interval of chunk= s it MUST send a HAVE message to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 all peer= s it wants to interact with in the near future."
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This looks like a place where a lot of traff= ic can be send
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 out of a peer, i.e., whene= ver a chunk arrives a HAVE message
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 must b= e sent.=A0 I don't believe that this should be mandated
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 by the protocol specification, but there sho= uld guidance on
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 when to send this, e.g., = peers might be also able to wait for
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a sh= ort period of time to gather more chunks to be reported
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in HAVE.=A0 Or should in this case a single = UDP datagram
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 contain multiple HAVEs?
<= br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Clarified.

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 - Section 3.4 on ACKs This section looks pretty weak, as AC= Ks
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 may be sent but on the other hand MUST= be sent if ledbat is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 used.=A0 I would simply say: - ACK MUST be s= ent if an
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 unreliable transport protocol i= s used - ACK MAY be sent if a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 reliable tr= ansport protocol is used - keep clarification
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 about ledbat.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 - Section 3.5: Give text where INTEGERITY is described at
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 least for the MTI scheme.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -= Section 3.7, 2nd paragraph - all 'MAY' are actually not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 right here.=A0 Please remove or replace them= with lower letters
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if appropriate. - It = is not clear what the 'sequentially'
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 means exactly.=A0 Is it in the received order?

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 +=A0=A0 First point TODO.=A0 "Sequentially" repla= ced with "received
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 order".

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 - Section 3.8: Please replace 'MAY' by can, as t= hose are not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 normative behaviors but more= the fact that peers can, for
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 instance, r= equest urgent data.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 - Section 3.9 Same comment as for the Section 3.8 just above=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this comment.

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 +=A0=A0 DONE.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.9= waiting for responses OLD " When peer B
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 receives a CHOKE message from A it MUST NOT = send new REQUEST
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 messages and SHOULD NOT = expect answers to any outstanding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ones.&q= uot;=A0 NEW " When peer B receives a CHOKE message from A it
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT send new REQUEST messages and it ca= nnot expect
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 answers to any outstanding on= es, as the transfer of chunks is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 choked.&= quot;

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 - Section 3.10.2 This whole section about PEX hole pu= nching
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 reads very, very experimental.=A0 The STUN m= ethod is ok, but
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PEX isn't.=A0 First = of all, the safe behavior for a peer when
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= it receives unsolicited PEX messages, is to discard those
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 messages.=A0 Second, this unsolicited PEX me= ssages trigger some
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 behavior which may op= en an attack vector.=A0 The best way, but
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= this needs more discussion, is to include to some token in
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the messages that are exchanged in order to = make avoid any
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 blind attacks here.=A0 How= ever, this will need more and
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 detailed di= scussions of the purpose of this.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 += =A0=A0 TODO: hole punching comment.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 We moved parts of the security a= nalysis of PEX up, such
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that = all mechanisms are explained in the main text, and
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 the analysis of what attacks there are and how these<= br> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mechanisms prevent them is in th= e Sec. Considerations
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 section= .

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.11 I don't see the = 'MUST send keep-alive' as a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 manda= tory requirement, as peers might have good reasons not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to send any keep alive.=A0 Why not saying &#= 39;A peer can send a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 keep-alive' and = it 'MUST use the simple datagram...' as
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 already described.=A0 Though there is also no really need to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 say MUST.

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 +=A0=A0 Now Section 3.12.=A0 Rephrased and clarified the reason and
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 consequences of sending keep-ali= ve msgs.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 4 The syntax defin= ition for each of the chunk
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 addressing schemes is missing.=A0 This is no= t suitable for any
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 specification that aim= s at interoperable implementations.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -= Section 4.3.2 PPSPP peers MUST use the ACK message if an
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 unreliable transport protocol is used.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 - Section 4.4 Has been tested in an implementation?=A0 I would=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 like to understand the need for such a sect= ion, as in my
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 understanding a peer implementation should c= hose one scheme
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and support this and ther= e shouldn't be the need to convert
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 be= tween the different schemes.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Sectio= n 5 This reads that MHTs are mandatory to implement
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 while the document makes the impression that= MHTs are
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 optional.

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 +=A0=A0 Rephrased, see High-level issues.

=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 - Section 5.3 " so each datagram SHOULD be pr= ocessed
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 separately and a loss of one datagram MUST N= OT disrupt the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 flow" The MUST NOT is= not a protocol specification
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 requirement= , but more an informative part saying that a lost
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 message shouldn't impact the protocol machinery, but it can =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 impact the overall operation.=A0 What is the= flow here in that
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sentence?

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Rephrased.

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 - Section 5.6.2.=A0 An illustrative example explaining how the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 automatic size detection works is required = here.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Added a paragraph with an exampl= e that follows the figure
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 use= d during the explanation.=A0 A state diagram could also
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 be added, but bight be a bit redundant.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 6.1, 4th paragraph: Where do I fin= d the 1 byte
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 algorithm field in the swarm ID?=A0 The swar= m ID is not really
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 defined in a single pl= ace.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Expanded.=A0 TODO: Forma= l spec of swarm ID.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7.3 The= described min/max versioning relies on the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fact that there are major and minor version = numbers.=A0 I
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cannot find any major and m= inor version number scheme in the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 draft.<= br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Actually, it does not.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7.4, Length field It is not clear= what the 'Length'
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 field is referring to.=A0 Further, it is not= clear of the swam
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IDs are concatenated i= n one swarm ID option, of each swarm ID
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 m= ust be placed in a separate swam ID option.

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 - Section 7.6 MHTs are mandatory to support though MHTs are
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 optional?

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 +=A0=A0 Clarified.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7.7 = 'key size ... derived from the swarm ID'.=A0 This
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 relates to my high level comment no 4. on the use of imp= licit
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 information.=A0 Either it is clearly specifi= ed how this
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 information is derived or the= re is a protocol field/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 information about= the size.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Key size derivatio= n procedure added to description of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SIGNED_INTEGRITY in UDP encapsul= ation.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7.8 I would recommen= d to say that the default MUST
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 be support= ed, but the peer must always signal what method it
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 is supporting or at least using.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Corrected, see High-level issues= 4.)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7.10 I have not unders= tood how the 'Lenght' field
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 relat= es to the message bitmap and how long the message bitmap
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 can grow.=A0 The figure looks like a maximum= of 16 bits?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Clarified.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8 I do not see the value of the = text in the preface
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of Section 8.=A0 I wo= uld say that this text should say what is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mandatory and what's not, i.e., MUST use= UDP and MUST use
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LEDBAT.=A0 Potentially = saying that future protocol versions can
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = also run over other transport protocols.

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 +=A0=A0 Adjusted.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.1 about Maximum Transfer Uni= t (MTU) The text is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 discussing that a Eth= ernet can carry 1500 bytes.=A0 This is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tr= ue, but the Ethernet payload is not the normative MTU
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 across all of the Internet.=A0 For IPv6 the min MTU is 1280 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bytes and for IPv4 it is 576 bytes, though f= or IPv4 it can be
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 theoretically much lowe= r at 64 bytes.=A0 It would move the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 defin= ition of the default chunk size to a recommendation with
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 text saying that this size has a high likeli= hood to travel
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 end-to-end in the Internet= without any fragmentation.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Fragmentation= might increase the loss of complete chunks, as
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 one lost fragment will cause the loss of a complete chunk.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 One way of getting an informed decision on w= hether chunks can
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 travel in their size is= to use the Don't Fragment (DF) bit in
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 IPv4 and also to watch for ICMP error messages.=A0 However,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ICMP error messages are not a reliable indic= ation, but they
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 can be some indication.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 1 KiB chunk size has been made= a recommendation.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.1 Defi= nition of the default chunk size There is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 no need to define a default chunk size, if t= he chunk size
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 would be always signaled pe= r swarm.=A0 This is another default/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 impl= icit value places that is unnecessary.

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 +=A0=A0 The chunk size is always part of the content's metadata.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.3: see also my comment no 3.= =A0 The concept of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 channels is introduced= very late and with few words.=A0 A
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 figur= e to explain the concept will help a lot and also more
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 formal text on what a channel is and how they are identifie= d.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Also what the init channel is.

=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Concept now introduced in Section 3.11.=A0= TODO init
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 channel.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8 in general: There is no formal d= efinition of the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 messages, just bit pattern examples.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.4 (as example for the other Sect= ions in 8.x): i)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 What is the '(CHANNE= L' paramter?=A0 Is it actually a parameter?
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 ii) it is implicit that the first channel no (0000000) is the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 remote peer's channel and that the secon= d channel no
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (00000011) is the local peer= 's channel, right?=A0 This isn't
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = clear from the text, but my guess.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - = Section 8.5 Can HAVE messages multiple bin specs in one
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 message or do I have to make a HAVE message = for each bin?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Clarified.
<= br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.6 What is the formal defintio= n of a DATA message?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 That's completel= y missing or I have not understood it.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.7 looks just underspecified,= especially as this
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is the link to LEDBAT= .

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.11 How are the chunks s= pecified here?=A0 The formal
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 syntax defin= ition or reference to one is missing.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.13 I'm lost on this sect= ion, as I haven't fully
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 understood th= e concept of the PEX in this document.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Es= pecially not why there is the PEX_REScert.

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 +=A0=A0 We moved parts of the security analysis of PEX up into
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3.10, such that all mechanisms a= re explained in the main
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 text= , and the analysis of what attacks there are and how
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 these mechanisms prevent them is in the Sec.
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Considerations section.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 11 The RFC required for protoc= ol extensions of a
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 standards track protoc= ol looks odd.=A0 This must be at least
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IE= TF Review or Standards Action.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ***Edi= torials:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Abstract (and probably also other plac= es), 1st sentence of,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PPSPP is not a tran= sport protocol, just a protocol

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0= =A0 DONE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 1.1, 4th paragraph= : I would remove the reference to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rmcat, as it is not yet clear what the outco= me of the rmcat
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 wg will be

=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= - Section 1.3, on page 8, about seeding/leeching: I would
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 break it in to sub-bullets.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 - Section 2.1 and following: These are examples, isn'it?= =A0 If
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 so, this should be mentioned or cl= arified.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.=A0 All subsect= ions now labeled "Example:".

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 2.1: What is the PPSP Url?
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 2.3, the 1st paragraph, detect= ion of dead peers: It
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 would be good to sa= y where this detection is described in the
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 remainder of the draft.=A0 Just for completeness.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE.=A0 Dead peer detection is = now a separate section and
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 re= ferenced here.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 2.2, the ver= y last paragraph, 'Peer A MAY also':
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 This 'MAY' is not useful here.=A0 I would just write 'Peer = A
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 can also', as there is nothing normative= described here.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.2, last paragraph: What is the l= atter
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 confinement?=A0 This is not clear t= o me.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Rephrased.

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 - Section 3.9, last sentence I am not sure to what the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 reference to Section 3.7 is pointing in th= is respect.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Rephrased.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.10.1 about PEX messages The tex= t says 'PPSPP
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 optionally features...'.=A0 I have not u= nderstood if this
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 optionally refers to ma= ndatory to implement but optionally to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 us= e, or if the PEX messages are optionally to implement.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Made it clear that is OPTIONAL a= nd not mandatory-to-
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 implemen= t.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 3.12 I'm not sure wh= at this section is telling
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exactly.=A0 Is= n't just saying that PPSPP as such does not care
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 how chunks are stored locally, as this is im= plementation
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 dependent?

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Yes. Removed.

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer MAY
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 support' NEW 'The support for this s= cheme is OPTIONAL'

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 DONE, for byte ranges as well.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 6.1.1 This section is not de= scribing sign-all, but
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rather a justifica= tion why it may still work.=A0 This doesn't
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 help at all.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7, 1st paragraph Why is there = a reference to RFC
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2132?

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Removed, just similarity in format.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 7 in general i) It is common to gi= ve bit positions
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in the figures where the syntax of options i= s described.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This allows to count how man= y bits are used for a protocol
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 field more= easily and also way more reliable. ii) Please add
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 also Figure labels to the syntax definitions of the options.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This makes it easier to reference them later= on if needed.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.1 1 kibiby= te is 1 kbyte?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 We follow ISO/= IEC 80000-13 to avoid the kilo =3D 1000 or
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 1024 confusion.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.2, last paragraph i ) "= All messages are
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 idempotent" in what= respect? ii) "or recognizable as
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 du= plicates" but how are the recognized as duplicates?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Idempotent means that processing= a message twice does not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lea= d to a different state than processing them once.
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Resent handshakes can be recognized as duplicates bec= ause
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a peer already recorded the firs= t connection attempt in
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 its s= tate.=A0 Updated text.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.5,= last sentence in brackets: What is this last
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 sentence about?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.13 " If sender of the P= EX_REQ message does not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 have a private or= link-local address, then the PEX_RES*
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 me= ssages MUST NOT contain such addresses [RFC1918][RFC4291]."
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 What is this text saying?=A0 Do not include = what you do not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 have anyway?

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 Rephrased.=A0 It tries to say that inte= rnal addresses must
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 not be le= aked to external peers.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Section 8.14 There is no single place = where all the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 constants are collected and= also documented what the default
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 values = or the recommended values.=A0 For instance in this
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Section 8.14 where the dead peer time out is set to 3 minutes
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and also the number of datagrams that should= have sent.=A0 I
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 would make a section or = subsection to discuss dead peers and
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 how = they are detected and just link to the keep-alive
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 mechanism in Section 8.14.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0=A0 A new section Section 12.1.1.1 &= quot;Summary of Default
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Value= s" was created for this in the Ops & Mgmt part.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 - Section 11 This section needs to be overhauled once= the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 document is ready for the IESG.=A0 The secti= on is not wrong but
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 can be improved to he= lp IANA.




= ---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2013/7/15
Subject: New Version Notification for draft-ietf-ppsp-pe= er-protocol-07.txt
To: Riccardo Petrocco <r.petrocc= o@gmail.com>, Arno Bakker <arno@= cs.vu.nl>, Victor Grishchenko <victor.grishchenko@gmail.com>



A new version of I-D, draft-ietf-ppsp-peer-protocol-07.txt
has been successfully submitted by Arno Bakker and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-ppsp-peer-protocol
Revision: =A0 =A0 =A0 =A007
Title: =A0 =A0 =A0 =A0 =A0 Peer-to-Peer Streaming Peer Protocol (PPSPP)
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 ppsp
Number of pages: 84
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-ietf-ppsp-peer-protocol-07.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-ietf-ppsp-peer-protocol
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ie= tf-ppsp-peer-protocol-07
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-ppsp-peer-protocol-07

Abstract:
=A0 =A0The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for =A0 =A0disseminating the same content to a group of interested parties in a=
=A0 =A0streaming fashion. =A0PPSPP supports streaming of both pre-recorded<= br> =A0 =A0(on-demand) and live audio/video content. =A0It is based on the peer= -
=A0 =A0to-peer paradigm, where clients consuming the content are put on
=A0 =A0equal footing with the servers initially providing the content, to =A0 =A0create a system where everyone can potentially provide upload
=A0 =A0bandwidth. =A0It has been designed to provide short time-till-playba= ck
=A0 =A0for the end user, and to prevent disruption of the streams by
=A0 =A0malicious peers. =A0PPSPP has also been designed to be flexible and<= br> =A0 =A0extensible. =A0It can use different mechanisms to optimize peer
=A0 =A0uploading, prevent freeriding, and work with different peer discover= y
=A0 =A0schemes (centralized trackers or Distributed Hash Tables). =A0It
=A0 =A0supports multiple methods for content integrity protection and chunk=
=A0 =A0addressing. =A0Designed as a generic protocol that can run on top of=
=A0 =A0various transport protocols, it currently runs on top of UDP using =A0 =A0LEDBAT for congestion control.




The IETF Secretariat


--bcaec53f2e313fed1404e190158b-- From hishigh@gmail.com Wed Jul 17 05:58:25 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D925C21F894E for ; Wed, 17 Jul 2013 05:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mIYLCBPPuPT for ; Wed, 17 Jul 2013 05:58:25 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 59E0621F99A0 for ; Wed, 17 Jul 2013 05:58:22 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so2439619oag.26 for ; Wed, 17 Jul 2013 05:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=3MxLG0xaNv1TEhOmMPeUY8NmSkgScwR2wXH3JdILKzw=; b=oKHGzoBPA5IGOq9DlXjYZ6Jh9/n0AENNG7cYiay7V0S3DqcGPncr/9RhaOeQvy8J4+ VUHGklmYIajqEi+hv4+9CiuFItvhQ7sFz2WcZ7bSXTDtp38XtZjmQSlqINV1b3DEsN6Y mMMmTbgy3rkJ0A+z4rzLmuyl5+C+oulybH9Vsuus/5gOhlBRdAgcroF8I617t7pAux0F V2ElCMlObc0NBryYTRNVdiWnRT3QDo6WE5piMfIa21GgjZf8KhiilcKxqgdH4mfaZRap xXAFVqdNFByJ0Khv3p+otm0DhUOXr77Q5AspHKCQvrdoPxY4uwR3ZzIoT0gvBKTgapIF 7grQ== MIME-Version: 1.0 X-Received: by 10.182.24.131 with SMTP id u3mr2362516obf.29.1374065901825; Wed, 17 Jul 2013 05:58:21 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Wed, 17 Jul 2013 05:58:21 -0700 (PDT) Date: Wed, 17 Jul 2013 20:58:21 +0800 Message-ID: From: yunfei zhang To: "ppsp@ietf.org" Content-Type: multipart/alternative; boundary=001a11c30252f9f8c104e1b4a58b Subject: [ppsp] Draft agenda in IETF87 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:58:26 -0000 --001a11c30252f9f8c104e1b4a58b Content-Type: text/plain; charset=ISO-8859-1 Hi all, The draft agenda of PPSP session in IETF 87 has been uploaded. You can find the detail in . Please let Stefano and me know if you have any suggestions/update on the draft before July 21. Thanks and see you in Berlin. BR Stefano&Yunfei --001a11c30252f9f8c104e1b4a58b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0=A0=A0 The draft agenda of PPSP = session in IETF 87 has been uploaded. You can find the detail in <http://www.i= etf.org/proceedings/87/agenda/agenda-87-ppsp>.
=A0=A0=A0=A0 Please let Stefano and me know if you have any suggestion= s/update on the draft before July 21. Thanks and see you in Berlin.
=A0
BR
Stefano&Yunfei
--001a11c30252f9f8c104e1b4a58b-- From wwwrun@rfc-editor.org Fri Jul 19 17:35:44 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73ACF11E81CC; Fri, 19 Jul 2013 17:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjZ+hc4T3eEG; Fri, 19 Jul 2013 17:35:43 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E699F11E8199; Fri, 19 Jul 2013 17:35:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6892C62107; Fri, 19 Jul 2013 17:32:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130720003256.6892C62107@rfc-editor.org> Date: Fri, 19 Jul 2013 17:32:56 -0700 (PDT) Cc: drafts-update-ref@iana.org, ppsp@ietf.org, rfc-editor@rfc-editor.org Subject: [ppsp] RFC 6972 on Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:35:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6972 Title: Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) Author: Y. Zhang, N. Zong Status: Informational Stream: IETF Date: July 2013 Mailbox: hishigh@gmail.com, zongning@huawei.com Pages: 22 Characters: 53634 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ppsp-problem-statement-15.txt URL: http://www.rfc-editor.org/rfc/rfc6972.txt Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols. This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP. This document is a product of the Peer to Peer Streaming Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hishigh@gmail.com Sat Jul 20 02:13:00 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F1B11E81C5 for ; Sat, 20 Jul 2013 02:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=1.420, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k4nYTIs3URn for ; Sat, 20 Jul 2013 02:12:59 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0073D11E8135 for ; Sat, 20 Jul 2013 02:12:48 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so7059506oag.17 for ; Sat, 20 Jul 2013 02:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4OsrNPr/Rab7T9hCI3pMteFiHlJtZRWrOsuPGwsI+0c=; b=cyeopIEoOna4OtlShlx5CSs3z+NZPzSHXt08cuPKTMnHgJQ5k0HyB7e6syM4N3+Yii V/JofMFpur7DZUoc2cCOuqO80onkTuAe+IwEGdhCMlWnrHQgNtKTUvmfkN0zAxy5W8RL gmo7FDh+NQFAsmIoEQP6Wy8BHoYtegM9LZdsK7RIIBpHjNxBzNUm8t65edpRm+xmXQ43 6/BlQrOC7Nqe11xuoUK0OiBZZSWy2ooE4FhOndT01kRaLhW2KLmrCM108Uo8r4A6ZhBs 245jmtXZeVVWLrKJtiexu49P/1euTZcghl7AsyhjgmoL6ReSBHMkgZrF78Z/zXP4kyzk yI7A== MIME-Version: 1.0 X-Received: by 10.60.77.70 with SMTP id q6mr20478335oew.98.1374311568285; Sat, 20 Jul 2013 02:12:48 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Sat, 20 Jul 2013 02:12:48 -0700 (PDT) Date: Sat, 20 Jul 2013 17:12:48 +0800 Message-ID: From: yunfei zhang To: "ppsp@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33d3e0d6a76904e1edd8d8 Subject: [ppsp] Webex Meeting information for ppsp session X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 09:13:01 -0000 --047d7b33d3e0d6a76904e1edd8d8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, For those who cannot attend the PPSP meeting in Berlin: The following is the webex meeting information. See you online. BR Yunfei ---------- Forwarded message ---------- From: Cindy Morgan Date: 2013/7/12 Subject: Meeting invitation: ppsp To: hishigh@gmail.com Hello , Cindy Morgan invites you to attend this online meeting. Topic: ppsp Date: Wednesday, July 31, 2013 Time: 3:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 967 786 633 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=208853667&UID=1363261052&PW=NMTg5MWViODQ1&RT=MiMyNQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=208853667&UID=1363261052&PW=NMTg5MWViODQ1&ORT=MiMyNQ%3D%3D ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=208853667&UID=1363261052&ICS=MI&LD=1&RD=2&ST=1&SHA2=rNIMFRpSTf6E-v0XC8i94IZ00a3V0JE5nOBw-ZRjy/M=&RT=MiMyNQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --047d7b33d3e0d6a76904e1edd8d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,
=A0=A0=A0=A0 For those who cann= ot attend the PPSP meeting in Berlin: The following is the webex meeting in= formation. See you online.
=A0
BR
Yunfei
---------- Forwarded message ----------
From: Cindy Morgan <messenger@webex.com>
Date: 2013/7/12
Subject: Me= eting invitation: ppsp
To: hishigh@gmail.com


<= font face=3D"Tahoma, Arial, sans-serif, Helvetica, Geneva">
Hello ,
Cindy Morgan invites you to attend this online meeting.

To= pic: ppsp
Date: Wednesday, July 31, 2013
Time: 3:00 pm, Europe Summer Time (Ber= lin, GMT+02:00)
Meeting Number: 967 786 633
Meeting Password: 123= 4


------------------------------------------------------- To join the online meeting (Now from mobile devices!)
---------------= ----------------------------------------
1. Go to https://workgre= en.webex.com/workgreen/j.php?ED=3D208853667&UID=3D1363261052&PW=3DN= MTg5MWViODQ1&RT=3DMiMyNQ%3D%3D
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://workgreen.webex.com/workgreen/j.php?ED=3D208853667&UID= =3D1363261052&PW=3DNMTg5MWViODQ1&ORT=3DMiMyNQ%3D%3D


-------------------------------------------------------
For= assistance
------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
cmorgan@amsl.com
1-510-492-4085

To add this meeting to= your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=3D208853667&= UID=3D1363261052&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3Dr= NIMFRpSTf6E-v0XC8i94IZ00a3V0JE5nOBw-ZRjy/M=3D&RT=3DMiMyNQ%3D%3D
The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter by going to https://workgreen.webex.com/workgreen/systemd= iagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com



IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. By joining this session, you automatically= consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation.

--047d7b33d3e0d6a76904e1edd8d8-- From denglingli@chinamobile.com Sun Jul 21 22:26:20 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25121F9A1D for ; Sun, 21 Jul 2013 22:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.73 X-Spam-Level: **** X-Spam-Status: No, score=4.73 tagged_above=-999 required=5 tests=[AWL=-3.089, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QddIi-hJDLG for ; Sun, 21 Jul 2013 22:26:15 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 5FE8321F89D8 for ; Sun, 21 Jul 2013 22:26:14 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151ecc23235f-7735f; Mon, 22 Jul 2013 13:25:07 +0800 (CST) X-RM-TRANSID: 2ee151ecc23235f-7735f Received: from cmccPC (unknown[10.2.43.200]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351ecc23096d-0ccbf; Mon, 22 Jul 2013 13:25:07 +0800 (CST) X-RM-TRANSID: 2ee351ecc23096d-0ccbf From: =?gb2312?B?tcvB6cDyL0xpbmdsaSBEZW5n?= To: "'Riccardo Petrocco'" , "'ppsp'" References: <20130715165826.16712.69876.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 22 Jul 2013 13:26:07 +0800 Message-ID: <00a701ce869b$f86785f0$e93691d0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CE86DF.068AC5F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6BgcEN0mIuzfm4QVm7yDs7SxlGjQFEPCnQ Content-Language: zh-cn Subject: [ppsp] =?gb2312?b?tPC4tDogIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0?= =?gb2312?b?aW9uIGZvcglkcmFmdC1pZXRmLXBwc3AtcGVlci1wcm90b2NvbC0w?= =?gb2312?b?Ny50eHQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 05:26:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01CE86DF.068AC5F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Riccardo, =20 Sorry I haven=A1=AFt been able to finish the whole draft, but I gather a = few general comments for you to consider: =20 1, The reference implementation is not available, as it requires a login account and password? 2, There are a few inconsistencies with the tracker protocol: 2.1 firstly, in terms of the MPD file acquisition, the tracker protocol states that the MPD file is acquired by the peer from the service = portal, which is out of scope of PPSP=A1=AFs specification. Whereas your = statement says that the MPD file is acquired by the peer from the tracker. 2.2 secondly, regarding the peer enrollment, the tracker protocol states that there will be an offline CA instead of the central tracker to issue peers=A1=AF security certificates, which contradicts the relevant = description in the current peer protocol draft. 3, As for the chunk availability specification schemes, being a highly efficient scheme itself, the binnum scheme could be kind of = heavy-weighted for it requires every chunk be acknowledged a logarithmic number of = times (which may be costly and unnecessary if PPSPP is carried over a reliable transport protocols, such as TCP).=20 =20 BTW, I have been proposing a lossy compression method to mitigate this matter. (http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/ ) I=A1=AFd appreciate it if you would provide some comments about it:-) =20 BR Lingli =20 =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Riccardo Petrocco =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C216=C8=D5 1:21 =CA=D5=BC=FE=C8=CB: ppsp =D6=F7=CC=E2: [ppsp] Fwd: New Version Notification for draft-ietf-ppsp-peer-protocol-07.txt =20 Hi all, I just uploaded an updated version of the peer protocol draft. We mostly focused on the issues presented in the recent AD review. Unfortunately due to the lack of time, and the extensive review, some = points still need to be addressed. See you in Berlin, ciao, Riccardo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= -07 2013-06-19 Revision following AD Review Quoting the AD review by Martin Stiemerling: ***High-level issues: 1) Merkle Hash Trees I have found the document very confusing on whether Merkle Hash Trees (MHTs) and the for the MHT required bin numbering scheme are now optional or mandatory. Parts of the draft make the impression that either of them or both or optional (mainly in the beginning of the document), while Section 5 and later Sections are relying heavily on MHTs. My naive reading of the current draft is that you could rely on start-end ranges for chunk addressing and MHTs for content protection. However, I do know that this combination is not working. If MHTs are really optional, including the bin numbering, the document should really state this and make clear what the operations of the protocol are with the mandatory to implement (MTI) mechanisms. The MHT, bins, and all the protocol handling should go in an appendix. There is a call to make for the WG: I do know that MHTs were considered by some as burden and they have called for a leaner way, i.e., the start-end ranges. The call for the leaner way has been implemented in the document but not fully. + The text now states that MHTs SHOULD be used unless in benign environments and are mandatory-to-implement. It also states that only start-end chunk range is mandatory- to-implement, and bins are optional. 2) LEDBAT as congestion control vs. PPSPP The PPSP peer protocol is intended for the Standards Track and relies in a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an **experimental** delay-based congestion control algorithm. A Standards Track protocol cannot normatively rely on an Experimental congestion control mechanism (or RFC in general). There are ways out of this situation: i) Do not use ledbat: this would call for another congestion control mechanism to be described in the PPSPP draft. ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track: Possible, but a very long way. iii) Agree on having PPSPP also as Experimental protocol. I'm currently leaning towards option iii), but this is my pure personal opinion as an individual in the IETF. + A new paragraph has been added to Section 8.16 describing the feasibility of LEDBAT in P2P systems. 3) No formal protocol message definition Section 7 and more specific Section 8 describe the protocol syntax of the protocol options and the messages, though Section 8 is talking about UDP encapsulation. Section 7 is hard to digest if someone should implement the options, see also later, but Section 8 is almost impossible to understand by somebody who has not been involved in the PPSP working group. See also further down for a more detailed review of the sections. To give an example out of Section 8.4: This section describes the HANDSHAKE message and gives examples how such a HANDSHAKE message could look like. But no formal definition of the message is given leaving a number of thins unclear, such as what the local channel number and what's the remote channel number is. This is implicitly defined, but that is not a good way of writing Standards Track drafts. 4) Implicit use of default values There are a number of places all over the draft where default values are defined. Many of those default values are used when there are no values explicitly signaled, e.g., the default chunk size of 1 Kbyte in Section 8.4 or Section Section 7.5. with the default for the Content Integrity Protection Method. I have the feeling that the protocol and the surroundings (e.g., what comes in via the 'tracker') are over-optimized, e.g., always providing the Content Integrity Protection Method as part of the Protocol options will not waste more than 2 bytes in a HANDSHAKE message. Further, I do not see the need to define a default chunk size in the base protocol specification, as this default can look very different, depending on who is deploying the protocol and in what context. This calls for a more dynamic way of handling the system chunk size, either as part of an external mechanisms (e.g. via the tracker) or in the HANDSHAKE message. + Removed implicit defaults from protocol options. Chunk size is part of the content's metadata and thus configurable. The default 1KiB has been turned into a recommendation. 5) Concept of channels The concept of channels is good but it is introduced too late in the draft, namely in Section 8.3, and it is introduced with very few words. Why isn't this introduced as part of Section 2 or Section 3, also in the relationship to the used transport protocol? I.e., the intention is to keep only one transport 'connection' between two distinct peers and to allow to run multiple swarm instances at the same time over the same transport. And how do swarms and channels correlate? + Concept now introduced in Section 3 with a figure. ***Technicals: - Section 2.1, 2nd paragraph, about the tracker: I haven't seen a single place where the interaction with a tracker is discussed or where the tracker less operation is discussed in contrast. It is further unclear what type of information is really required from a tracker. A tracker (or a resource directory) would need to provide more then IP address & port, e.g., the used transport protocol for the protocol exchange (given that other transports are allowed), used chunk size, chunk addressing scheme, etc - Section 2.3, the 1st paragraph, 'close-channel': This has been the first time where I stumbled over the channel without knowing the concept. + Rephrased. - Section 3.1: ordering of messages The 1st sentence implies that ordering of messages in a datagram matters a lot. This is outlined later in the document, but I would add this as part of 3., i.e., the messages are processed in the strict order or something along this line. - Section 3.1, 1st paragraph, options to include I would not say anything about 'SHOULD include options' here, as this is anyhow described in Section 8. + Phrase removed. - Section 3.1, 2nd paragraph: "Datagrams exchanged MAY also contain some minor payload, e.g. HAVE messages to indicate the current progress of a peer or a REQUEST (see Section 3.7)." to be added, just to make it clear IMHO: ", but MUST NOT include any DATA message". + Added. - Section 3.2, 2nd paragraph: "In particular, whenever a receiving peer has successfully checked the integrity of a chunk or interval of chunks it MUST send a HAVE message to all peers it wants to interact with in the near future." This looks like a place where a lot of traffic can be send out of a peer, i.e., whenever a chunk arrives a HAVE message must be sent. I don't believe that this should be mandated by the protocol specification, but there should guidance on when to send this, e.g., peers might be also able to wait for a short period of time to gather more chunks to be reported in HAVE. Or should in this case a single UDP datagram contain multiple HAVEs? + Clarified. - Section 3.4 on ACKs This section looks pretty weak, as ACKs may be sent but on the other hand MUST be sent if ledbat is used. I would simply say: - ACK MUST be sent if an unreliable transport protocol is used - ACK MAY be sent if a reliable transport protocol is used - keep clarification about ledbat. + DONE. - Section 3.5: Give text where INTEGERITY is described at least for the MTI scheme. + DONE. - Section 3.7, 2nd paragraph - all 'MAY' are actually not right here. Please remove or replace them with lower letters if appropriate. - It is not clear what the 'sequentially' means exactly. Is it in the received order? + First point TODO. "Sequentially" replaced with "received order". - Section 3.8: Please replace 'MAY' by can, as those are not normative behaviors but more the fact that peers can, for instance, request urgent data. + DONE. - Section 3.9 Same comment as for the Section 3.8 just above this comment. + DONE. - Section 3.9 waiting for responses OLD " When peer B receives a CHOKE message from A it MUST NOT send new REQUEST messages and SHOULD NOT expect answers to any outstanding ones." NEW " When peer B receives a CHOKE message from A it MUST NOT send new REQUEST messages and it cannot expect answers to any outstanding ones, as the transfer of chunks is choked." + DONE. - Section 3.10.2 This whole section about PEX hole punching reads very, very experimental. The STUN method is ok, but PEX isn't. First of all, the safe behavior for a peer when it receives unsolicited PEX messages, is to discard those messages. Second, this unsolicited PEX messages trigger some behavior which may open an attack vector. The best way, but this needs more discussion, is to include to some token in the messages that are exchanged in order to make avoid any blind attacks here. However, this will need more and detailed discussions of the purpose of this. + TODO: hole punching comment. + We moved parts of the security analysis of PEX up, such that all mechanisms are explained in the main text, and the analysis of what attacks there are and how these mechanisms prevent them is in the Sec. Considerations section. - Section 3.11 I don't see the 'MUST send keep-alive' as a mandatory requirement, as peers might have good reasons not to send any keep alive. Why not saying 'A peer can send a keep-alive' and it 'MUST use the simple datagram...' as already described. Though there is also no really need to say MUST. + Now Section 3.12. Rephrased and clarified the reason and consequences of sending keep-alive msgs. - Section 4 The syntax definition for each of the chunk addressing schemes is missing. This is not suitable for any specification that aims at interoperable implementations. - Section 4.3.2 PPSPP peers MUST use the ACK message if an unreliable transport protocol is used. + DONE. - Section 4.4 Has been tested in an implementation? I would like to understand the need for such a section, as in my understanding a peer implementation should chose one scheme and support this and there shouldn't be the need to convert between the different schemes. - Section 5 This reads that MHTs are mandatory to implement while the document makes the impression that MHTs are optional. + Rephrased, see High-level issues. - Section 5.3 " so each datagram SHOULD be processed separately and a loss of one datagram MUST NOT disrupt the flow" The MUST NOT is not a protocol specification requirement, but more an informative part saying that a lost message shouldn't impact the protocol machinery, but it can impact the overall operation. What is the flow here in that sentence? + Rephrased. - Section 5.6.2. An illustrative example explaining how the automatic size detection works is required here. + Added a paragraph with an example that follows the figure used during the explanation. A state diagram could also be added, but bight be a bit redundant. - Section 6.1, 4th paragraph: Where do I find the 1 byte algorithm field in the swarm ID? The swarm ID is not really defined in a single place. + Expanded. TODO: Formal spec of swarm ID. - Section 7.3 The described min/max versioning relies on the fact that there are major and minor version numbers. I cannot find any major and minor version number scheme in the draft. + Actually, it does not. - Section 7.4, Length field It is not clear what the 'Length' field is referring to. Further, it is not clear of the swam IDs are concatenated in one swarm ID option, of each swarm ID must be placed in a separate swam ID option. - Section 7.6 MHTs are mandatory to support though MHTs are optional? + Clarified. - Section 7.7 'key size ... derived from the swarm ID'. This relates to my high level comment no 4. on the use of implicit information. Either it is clearly specified how this information is derived or there is a protocol field/ information about the size. + Key size derivation procedure added to description of SIGNED_INTEGRITY in UDP encapsulation. - Section 7.8 I would recommend to say that the default MUST be supported, but the peer must always signal what method it is supporting or at least using. + Corrected, see High-level issues 4.) - Section 7.10 I have not understood how the 'Lenght' field relates to the message bitmap and how long the message bitmap can grow. The figure looks like a maximum of 16 bits? + Clarified. - Section 8 I do not see the value of the text in the preface of Section 8. I would say that this text should say what is mandatory and what's not, i.e., MUST use UDP and MUST use LEDBAT. Potentially saying that future protocol versions can also run over other transport protocols. + Adjusted. - Section 8.1 about Maximum Transfer Unit (MTU) The text is discussing that a Ethernet can carry 1500 bytes. This is true, but the Ethernet payload is not the normative MTU across all of the Internet. For IPv6 the min MTU is 1280 bytes and for IPv4 it is 576 bytes, though for IPv4 it can be theoretically much lower at 64 bytes. It would move the definition of the default chunk size to a recommendation with text saying that this size has a high likelihood to travel end-to-end in the Internet without any fragmentation. Fragmentation might increase the loss of complete chunks, as one lost fragment will cause the loss of a complete chunk. One way of getting an informed decision on whether chunks can travel in their size is to use the Don't Fragment (DF) bit in IPv4 and also to watch for ICMP error messages. However, ICMP error messages are not a reliable indication, but they can be some indication. + 1 KiB chunk size has been made a recommendation. - Section 8.1 Definition of the default chunk size There is no need to define a default chunk size, if the chunk size would be always signaled per swarm. This is another default/ implicit value places that is unnecessary. + The chunk size is always part of the content's metadata. - Section 8.3: see also my comment no 3. The concept of channels is introduced very late and with few words. A figure to explain the concept will help a lot and also more formal text on what a channel is and how they are identified. Also what the init channel is. + Concept now introduced in Section 3.11. TODO init channel. - Section 8 in general: There is no formal definition of the messages, just bit pattern examples. - Section 8.4 (as example for the other Sections in 8.x): i) What is the '(CHANNEL' paramter? Is it actually a parameter? ii) it is implicit that the first channel no (0000000) is the remote peer's channel and that the second channel no (00000011) is the local peer's channel, right? This isn't clear from the text, but my guess. - Section 8.5 Can HAVE messages multiple bin specs in one message or do I have to make a HAVE message for each bin? + Clarified. - Section 8.6 What is the formal defintion of a DATA message? That's completely missing or I have not understood it. - Section 8.7 looks just underspecified, especially as this is the link to LEDBAT. - Section 8.11 How are the chunks specified here? The formal syntax definition or reference to one is missing. - Section 8.13 I'm lost on this section, as I haven't fully understood the concept of the PEX in this document. Especially not why there is the PEX_REScert. + We moved parts of the security analysis of PEX up into 3.10, such that all mechanisms are explained in the main text, and the analysis of what attacks there are and how these mechanisms prevent them is in the Sec. Considerations section. - Section 11 The RFC required for protocol extensions of a standards track protocol looks odd. This must be at least IETF Review or Standards Action. ***Editorials: - Abstract (and probably also other places), 1st sentence of, PPSPP is not a transport protocol, just a protocol + DONE - Section 1.1, 4th paragraph: I would remove the reference to rmcat, as it is not yet clear what the outcome of the rmcat wg will be + DONE - Section 1.3, on page 8, about seeding/leeching: I would break it in to sub-bullets. + DONE - Section 2.1 and following: These are examples, isn'it? If so, this should be mentioned or clarified. + DONE. All subsections now labeled "Example:". - Section 2.1: What is the PPSP Url? - Section 2.3, the 1st paragraph, detection of dead peers: It would be good to say where this detection is described in the remainder of the draft. Just for completeness. + DONE. Dead peer detection is now a separate section and referenced here. - Section 2.2, the very last paragraph, 'Peer A MAY also': This 'MAY' is not useful here. I would just write 'Peer A can also', as there is nothing normative described here. + DONE - Section 3.2, last paragraph: What is the latter confinement? This is not clear to me. + Rephrased. - Section 3.9, last sentence I am not sure to what the reference to Section 3.7 is pointing in this respect. + Rephrased. - Section 3.10.1 about PEX messages The text says 'PPSPP optionally features...'. I have not understood if this optionally refers to mandatory to implement but optionally to use, or if the PEX messages are optionally to implement. + Made it clear that is OPTIONAL and not mandatory-to- implement. - Section 3.12 I'm not sure what this section is telling exactly. Isn't just saying that PPSPP as such does not care how chunks are stored locally, as this is implementation dependent? + Yes. Removed. - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer MAY support' NEW 'The support for this scheme is OPTIONAL' + DONE, for byte ranges as well. - Section 6.1.1 This section is not describing sign-all, but rather a justification why it may still work. This doesn't help at all. - Section 7, 1st paragraph Why is there a reference to RFC 2132? + Removed, just similarity in format. - Section 7 in general i) It is common to give bit positions in the figures where the syntax of options is described. This allows to count how many bits are used for a protocol field more easily and also way more reliable. ii) Please add also Figure labels to the syntax definitions of the options. This makes it easier to reference them later on if needed. - Section 8.1 1 kibibyte is 1 kbyte? + We follow ISO/IEC 80000-13 to avoid the kilo =3D 1000 or 1024 confusion. - Section 8.2, last paragraph i ) "All messages are idempotent" in what respect? ii) "or recognizable as duplicates" but how are the recognized as duplicates? + Idempotent means that processing a message twice does not lead to a different state than processing them once. Resent handshakes can be recognized as duplicates because a peer already recorded the first connection attempt in its state. Updated text. - Section 8.5, last sentence in brackets: What is this last sentence about? - Section 8.13 " If sender of the PEX_REQ message does not have a private or link-local address, then the PEX_RES* messages MUST NOT contain such addresses [RFC1918][RFC4291]." What is this text saying? Do not include what you do not have anyway? + Rephrased. It tries to say that internal addresses must not be leaked to external peers. - Section 8.14 There is no single place where all the constants are collected and also documented what the default values or the recommended values. For instance in this Section 8.14 where the dead peer time out is set to 3 minutes and also the number of datagrams that should have sent. I would make a section or subsection to discuss dead peers and how they are detected and just link to the keep-alive mechanism in Section 8.14. + A new section Section 12.1.1.1 "Summary of Default Values" was created for this in the Ops & Mgmt part. - Section 11 This section needs to be overhauled once the document is ready for the IESG. The section is not wrong but can be improved to help IANA. =20 ---------- Forwarded message ---------- From: Date: 2013/7/15 Subject: New Version Notification for = draft-ietf-ppsp-peer-protocol-07.txt To: Riccardo Petrocco , Arno Bakker = , Victor Grishchenko A new version of I-D, draft-ietf-ppsp-peer-protocol-07.txt has been successfully submitted by Arno Bakker and posted to the IETF repository. Filename: draft-ietf-ppsp-peer-protocol Revision: 07 Title: Peer-to-Peer Streaming Peer Protocol (PPSPP) Creation date: 2013-07-15 Group: ppsp Number of pages: 84 URL: http://www.ietf.org/internet-drafts/draft-ietf-ppsp-peer-protocol-07.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol Htmlized: = http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-peer-protocol-07 Abstract: The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both pre-recorded (on-demand) and live audio/video content. It is based on the peer- to-peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user, and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using LEDBAT for congestion control. The IETF Secretariat =20 ------=_NextPart_000_00A8_01CE86DF.068AC5F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Riccardo,

 

Sorry I haven=A1=AFt been able to finish the whole draft, but I = gather a few general comments for you to = consider:

 

1, The reference implementation is not available, as it requires a = login account and password?

2, There are a few inconsistencies with the tracker = protocol:

2.1 firstly, in terms of the MPD file acquisition, the tracker = protocol states that the MPD file is acquired by the peer from the = service portal, which is out of scope of PPSP=A1=AFs specification. = Whereas your statement says that the MPD file is acquired by the peer = from the tracker.

2.2 secondly, regarding the peer enrollment, the tracker protocol = states that there will be an offline CA instead of the central tracker = to issue peers=A1=AF security certificates, which contradicts the = relevant description in the current peer protocol = draft.

3, As for the chunk availability specification schemes, being a = highly efficient scheme itself, the binnum scheme could be kind of = heavy-weighted for it requires every chunk be acknowledged a logarithmic = number of times (which may be costly and unnecessary if PPSPP is carried = over a reliable transport protocols, such as TCP). =

 

BTW, I have been proposing a lossy compression method to mitigate = this matter. (http:/= /datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/ = )

I=A1=AFd appreciate it if you would provide some comments about = it:-)

 

BR

Lingli

 

=B7=A2=BC=FE=C8=CB: = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = Riccardo = Petrocco
=B7=A2=CB=CD=CA=B1=BC= =E4: 2013=C4=EA7=D4=C216=C8=D5 1:21
=CA=D5=BC=FE=C8=CB: = ppsp
=D6=F7=CC=E2: [ppsp] Fwd: New Version Notification for = draft-ietf-ppsp-peer-protocol-07.txt

 

Hi = all,

I just uploaded an = updated version of the peer protocol = draft.

We mostly focused on the issues presented in the recent AD = review.

Unfortunately due to = the lack of time, and the extensive review, some points still need to be = addressed.

See you in = Berlin,
ciao,
Riccardo



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

  = -07        2013-06-19 Revision = following AD = Review

          = ; Quoting the AD review by Martin Stiemerling: = ***High-level
         &n= bsp; = issues:

         &nbs= p; 1) Merkle Hash Trees I have found the document very = confusing
          = on whether Merkle Hash Trees (MHTs) and the for the = MHT
           = required bin numbering scheme are now optional or = mandatory.
          = ; Parts of the draft make the impression that either of them = or
           both = or optional (mainly in the beginning of the = document),
          = ; while Section 5 and later Sections are relying heavily = on
           = MHTs.  My naive reading of the current draft is that = you
           = could rely on start-end ranges for chunk addressing and = MHTs
           for = content protection.  However, I do know that = this
           = combination is not working.  If MHTs are really = optional,
          = including the bin numbering, the document should really = state
           = this and make clear what the operations of the protocol = are
           with = the mandatory to implement (MTI) mechanisms.  The = MHT,
           = bins, and all the protocol handling should go in an = appendix.
          = There is a call to make for the WG: I do know that MHTs = were
           = considered by some as burden and they have called for = a
           leaner = way, i.e., the start-end ranges.  The call for = the
           = leaner way has been implemented in the document but = not
           = fully.

          = ; +   The text now states that MHTs SHOULD be used unless = in
           &= nbsp;   benign environments and are = mandatory-to-implement.  = It
           &= nbsp;   also states that only start-end chunk range is = mandatory-
          = ;     to-implement, and bins are = optional.

         &n= bsp; 2) LEDBAT as congestion control vs. PPSPP The PPSP = peer
           = protocol is intended for the Standards Track and relies in = a
           = normative manner on LEDBAT (RFC 6817).  LEDBAT as such is = an
           = **experimental** delay-based congestion control algorithm.  = A
           = Standards Track protocol cannot normatively rely on = an
           = Experimental congestion control mechanism (or RFC = in
           = general).  There are ways out of this situation: i) Do = not
           use = ledbat: this would call for another congestion = control
           = mechanism to be described in the PPSPP draft. ii) Work on = an
           = 'upgrade' of the LEDBAT specification to Standards = Track:
           = Possible, but a very long way. iii) Agree on having = PPSPP
           = also as Experimental protocol.  I'm currently leaning = towards
           = option iii), but this is my pure personal opinion as = an
           = individual in the = IETF.

          = +   A new paragraph has been added to Section 8.16 = describing
          = ;     the feasibility of LEDBAT in P2P = systems.

         &nb= sp; 3) No formal protocol message definition Section 7 and = more
           = specific Section 8 describe the protocol syntax of = the
           = protocol options and the messages, though Section 8 = is
           = talking about UDP encapsulation.  Section 7 is hard to = digest
           = if someone should implement the options, see also later, = but
           = Section 8 is almost impossible to understand by somebody = who
           has = not been involved in the PPSP working group.  See = also
           = further down for a more detailed review of the sections.  = To
           give = an example out of Section 8.4: This section = describes
          = the HANDSHAKE message and gives examples how such a = HANDSHAKE
          = message could look like.  But no formal definition of = the
           = message is given leaving a number of thins unclear, such = as
           what = the local channel number and what's the remote = channel
           = number is.  This is implicitly defined, but that is not = a
           good = way of writing Standards Track = drafts.

         &nbs= p; 4) Implicit use of default values There are a number = of
           = places all over the draft where default values are = defined.
           = Many of those default values are used when there are = no
           = values explicitly signaled, e.g., the default chunk size of = 1
           Kbyte = in Section 8.4 or Section Section 7.5. with the = default
           = for the Content Integrity Protection Method.  I have = the
           = feeling that the protocol and the surroundings (e.g., = what
           = comes in via the 'tracker') are over-optimized, e.g., = always
           = providing the Content Integrity Protection Method as part = of
           the = Protocol options will not waste more than 2 bytes in = a
           = HANDSHAKE message.  Further, I do not see the need to = define
           a = default chunk size in the base protocol specification, = as
           this = default can look very different, depending on who = is
           = deploying the protocol and in what context.  This calls for = a
           more = dynamic way of handling the system chunk size, either = as
           part = of an external mechanisms (e.g. via the tracker) or = in
           the = HANDSHAKE = message.

         &nb= sp; +   Removed implicit defaults from protocol options.  = Chunk
          &nbs= p;    size is part of the content's metadata and = thus
           = ;    configurable.  The default 1KiB has been turned = into = a
           &n= bsp;   = recommendation.

        &n= bsp;  5) Concept of channels The concept of channels is good but = it
           is = introduced too late in the draft, namely in Section = 8.3,
           and = it is introduced with very few words.  Why isn't = this
           = introduced as part of Section 2 or Section 3, also in = the
           = relationship to the used transport protocol?  I.e., = the
           = intention is to keep only one transport 'connection' = between
           = two distinct peers and to allow to run multiple = swarm
           = instances at the same time over the same transport.  And = how
           do = swarms and channels = correlate?

         &= nbsp; +   Concept now introduced in Section 3 with a = figure.

         &nbs= p; = ***Technicals:

        &nb= sp;  - Section 2.1, 2nd paragraph, about the tracker: I = haven't
           = seen a single place where the interaction with a tracker = is
           = discussed or where the tracker less operation is discussed = in
           = contrast.  It is further unclear what type of information = is
           = really required from a tracker.  A tracker (or a = resource
           = directory) would need to provide more then IP address & = port,
           = e.g., the used transport protocol for the protocol = exchange
           = (given that other transports are allowed), used chunk = size,
           = chunk addressing scheme, = etc

           = - Section 2.3, the 1st paragraph, 'close-channel': This = has
           been = the first time where I stumbled over the channel = without
           = knowing the = concept.

         &nb= sp; +   = Rephrased.

         &= nbsp; - Section 3.1: ordering of messages The 1st sentence = implies
           = that ordering of messages in a datagram matters a lot.  = This
           is = outlined later in the document, but I would add this = as
           part = of 3., i.e., the messages are processed in the = strict
           = order or something along this = line.

          = - Section 3.1, 1st paragraph, options to include I would = not
           say = anything about 'SHOULD include options' here, as this = is
           = anyhow described in Section = 8.

           = +   Phrase = removed.

         &nb= sp; - Section 3.1, 2nd paragraph: "Datagrams exchanged MAY = also
           = contain some minor payload, e.g.  HAVE messages to = indicate
           = the current progress of a peer or a REQUEST (see = Section
           = 3.7)." to be added, just to make it clear IMHO: ", but = MUST
           NOT = include any DATA = message".

        &nb= sp;  +   = Added.

          = ; - Section 3.2, 2nd paragraph: "In particular, whenever = a
           = receiving peer has successfully checked the integrity of = a
           chunk = or interval of chunks it MUST send a HAVE message = to
           all = peers it wants to interact with in the near = future."
         &n= bsp; This looks like a place where a lot of traffic can be = send
           out = of a peer, i.e., whenever a chunk arrives a HAVE = message
           = must be sent.  I don't believe that this should be = mandated
           = by the protocol specification, but there should guidance = on
           when = to send this, e.g., peers might be also able to wait = for
           a = short period of time to gather more chunks to be = reported
           = in HAVE.  Or should in this case a single UDP = datagram
           = contain multiple = HAVEs?

          = ; +   = Clarified.

         &= nbsp; - Section 3.4 on ACKs This section looks pretty weak, as = ACKs
           may = be sent but on the other hand MUST be sent if ledbat = is
           = used.  I would simply say: - ACK MUST be sent if = an
           = unreliable transport protocol is used - ACK MAY be sent if = a
           = reliable transport protocol is used - keep = clarification
         &n= bsp; about = ledbat.

         &nbs= p; +   = DONE.

          = - Section 3.5: Give text where INTEGERITY is described = at
           least = for the MTI = scheme.

         &nbs= p; +   = DONE.

          = - Section 3.7, 2nd paragraph - all 'MAY' are actually = not
           = right here.  Please remove or replace them with lower = letters
           = if appropriate. - It is not clear what the = 'sequentially'
         &= nbsp; means exactly.  Is it in the received = order?

          = ; +   First point TODO.  "Sequentially" = replaced with = "received
         &= nbsp;     = order".

         = ;  - Section 3.8: Please replace 'MAY' by can, as those are = not
           = normative behaviors but more the fact that peers can, = for
           = instance, request urgent = data.

          = +   = DONE.

          = - Section 3.9 Same comment as for the Section 3.8 just = above
           = this = comment.

         &nb= sp; +   = DONE.

          = - Section 3.9 waiting for responses OLD " When peer = B
           = receives a CHOKE message from A it MUST NOT send new = REQUEST
           = messages and SHOULD NOT expect answers to any = outstanding
         &nbs= p; ones."  NEW " When peer B receives a CHOKE message = from A = it
           MUST = NOT send new REQUEST messages and it cannot = expect
           = answers to any outstanding ones, as the transfer of chunks = is
           = choked."

        &nbs= p;  +   = DONE.

          = - Section 3.10.2 This whole section about PEX hole = punching
           = reads very, very experimental.  The STUN method is ok, = but
           PEX = isn't.  First of all, the safe behavior for a peer = when
           it = receives unsolicited PEX messages, is to discard = those
           = messages.  Second, this unsolicited PEX messages trigger = some
           = behavior which may open an attack vector.  The best way, = but
           this = needs more discussion, is to include to some token = in
           the = messages that are exchanged in order to make avoid = any
           = blind attacks here.  However, this will need more = and
           = detailed discussions of the purpose of = this.

          = +   TODO: hole punching = comment.

         &nb= sp; +   We moved parts of the security analysis of PEX up, = such
           = ;    that all mechanisms are explained in the main text, = and
           =     the analysis of what attacks there are and how = these
          &nbs= p;    mechanisms prevent them is in the Sec. = Considerations
         &= nbsp;     = section.

         &nb= sp; - Section 3.11 I don't see the 'MUST send keep-alive' as = a
           = mandatory requirement, as peers might have good reasons = not
           to = send any keep alive.  Why not saying 'A peer can send = a
           = keep-alive' and it 'MUST use the simple datagram...' = as
           = already described.  Though there is also no really need = to
           say = MUST.

          = +   Now Section 3.12.  Rephrased and clarified the = reason = and
           =     consequences of sending keep-alive = msgs.

          = - Section 4 The syntax definition for each of the = chunk
           = addressing schemes is missing.  This is not suitable for = any
           = specification that aims at interoperable = implementations.

        &= nbsp;  - Section 4.3.2 PPSPP peers MUST use the ACK message if = an
           = unreliable transport protocol is = used.

          = +   = DONE.

          = - Section 4.4 Has been tested in an implementation?  I = would
           = like to understand the need for such a section, as in = my
           = understanding a peer implementation should chose one = scheme
           = and support this and there shouldn't be the need to = convert
           = between the different = schemes.

         &nb= sp; - Section 5 This reads that MHTs are mandatory to = implement
          = while the document makes the impression that MHTs = are
           = optional.

         &n= bsp; +   Rephrased, see High-level = issues.

         &nbs= p; - Section 5.3 " so each datagram SHOULD be = processed
          = separately and a loss of one datagram MUST NOT disrupt = the
           = flow" The MUST NOT is not a protocol = specification
         &n= bsp; requirement, but more an informative part saying that a = lost
           = message shouldn't impact the protocol machinery, but it = can
           = impact the overall operation.  What is the flow here in = that
           = sentence?

         &n= bsp; +   = Rephrased.

         &= nbsp; - Section 5.6.2.  An illustrative example explaining how = the
           = automatic size detection works is required = here.

          = +   Added a paragraph with an example that follows the = figure
          &nb= sp;    used during the explanation.  A state diagram = could = also
           = ;    be added, but bight be a bit = redundant.

         &= nbsp; - Section 6.1, 4th paragraph: Where do I find the 1 = byte
           = algorithm field in the swarm ID?  The swarm ID is not = really
           = defined in a single = place.

          = ; +   Expanded.  TODO: Formal spec of swarm = ID.

           = - Section 7.3 The described min/max versioning relies on = the
           fact = that there are major and minor version numbers.  = I
           cannot = find any major and minor version number scheme in = the
           = draft.

          = ; +   Actually, it does = not.

           = - Section 7.4, Length field It is not clear what the = 'Length'
           = field is referring to.  Further, it is not clear of the = swam
           IDs = are concatenated in one swarm ID option, of each swarm = ID
           must = be placed in a separate swam ID = option.

         &nbs= p; - Section 7.6 MHTs are mandatory to support though MHTs = are
           = optional?

         &n= bsp; +   = Clarified.

         &= nbsp; - Section 7.7 'key size ... derived from the swarm ID'.  = This
           = relates to my high level comment no 4. on the use of = implicit
           = information.  Either it is clearly specified how = this
           = information is derived or there is a protocol = field/
           = information about the = size.

          = +   Key size derivation procedure added to description = of
           &= nbsp;   SIGNED_INTEGRITY in UDP = encapsulation.

        &nb= sp;  - Section 7.8 I would recommend to say that the default = MUST
           be = supported, but the peer must always signal what method = it
           is = supporting or at least = using.

          = ; +   Corrected, see High-level issues = 4.)

           = - Section 7.10 I have not understood how the 'Lenght' = field
           = relates to the message bitmap and how long the message = bitmap
           = can grow.  The figure looks like a maximum of 16 = bits?

          = +   = Clarified.

         &= nbsp; - Section 8 I do not see the value of the text in the = preface
           = of Section 8.  I would say that this text should say what = is
           = mandatory and what's not, i.e., MUST use UDP and MUST = use
           = LEDBAT.  Potentially saying that future protocol versions = can
           also = run over other transport = protocols.

         &= nbsp; +   = Adjusted.

         &n= bsp; - Section 8.1 about Maximum Transfer Unit (MTU) The text = is
           = discussing that a Ethernet can carry 1500 bytes.  This = is
           true, = but the Ethernet payload is not the normative = MTU
           = across all of the Internet.  For IPv6 the min MTU is = 1280
           = bytes and for IPv4 it is 576 bytes, though for IPv4 it can = be
           = theoretically much lower at 64 bytes.  It would move = the
           = definition of the default chunk size to a recommendation = with
           = text saying that this size has a high likelihood to = travel
           = end-to-end in the Internet without any = fragmentation.
         &= nbsp; Fragmentation might increase the loss of complete chunks, = as
           one = lost fragment will cause the loss of a complete = chunk.
           = One way of getting an informed decision on whether chunks = can
           = travel in their size is to use the Don't Fragment (DF) bit = in
           IPv4 = and also to watch for ICMP error messages.  = However,
           = ICMP error messages are not a reliable indication, but = they
           can = be some = indication.

         =   +   1 KiB chunk size has been made a = recommendation.

        &n= bsp;  - Section 8.1 Definition of the default chunk size There = is
           no = need to define a default chunk size, if the chunk = size
           = would be always signaled per swarm.  This is another = default/
           = implicit value places that is = unnecessary.

         = ;  +   The chunk size is always part of the content's = metadata.

         &n= bsp; - Section 8.3: see also my comment no 3.  The concept = of
           = channels is introduced very late and with few words.  = A
           figure = to explain the concept will help a lot and also = more
           = formal text on what a channel is and how they are = identified.
         &nbs= p; Also what the init channel = is.

           = +   Concept now introduced in Section 3.11.  TODO = init
           = ;    = channel.

         &nb= sp; - Section 8 in general: There is no formal definition of = the
           = messages, just bit pattern = examples.

         &n= bsp; - Section 8.4 (as example for the other Sections in 8.x): = i)
           What = is the '(CHANNEL' paramter?  Is it actually a = parameter?
          = ; ii) it is implicit that the first channel no (0000000) is = the
           = remote peer's channel and that the second channel = no
           = (00000011) is the local peer's channel, right?  This = isn't
           = clear from the text, but my = guess.

          = ; - Section 8.5 Can HAVE messages multiple bin specs in = one
           = message or do I have to make a HAVE message for each = bin?

           = +   = Clarified.

         &= nbsp; - Section 8.6 What is the formal defintion of a DATA = message?
           = That's completely missing or I have not understood = it.

           = - Section 8.7 looks just underspecified, especially as = this
           is = the link to = LEDBAT.

         &nbs= p; - Section 8.11 How are the chunks specified here?  The = formal
           = syntax definition or reference to one is = missing.

         &nb= sp; - Section 8.13 I'm lost on this section, as I haven't = fully
           = understood the concept of the PEX in this = document.
          = Especially not why there is the = PEX_REScert.

         = ;  +   We moved parts of the security analysis of PEX up = into
           = ;    3.10, such that all mechanisms are explained in the = main
           = ;    text, and the analysis of what attacks there are and = how
           =     these mechanisms prevent them is in the = Sec.
           = ;    Considerations = section.

         &nb= sp; - Section 11 The RFC required for protocol extensions of = a
           = standards track protocol looks odd.  This must be at = least
           = IETF Review or Standards = Action.

         &nbs= p; = ***Editorials:

        &nb= sp;  - Abstract (and probably also other places), 1st sentence = of,
           = PPSPP is not a transport protocol, just a = protocol

         &nb= sp; +   = DONE

           = - Section 1.1, 4th paragraph: I would remove the reference = to
           = rmcat, as it is not yet clear what the outcome of the = rmcat
           wg = will = be

           = +   = DONE

           = - Section 1.3, on page 8, about seeding/leeching: I = would
           = break it in to = sub-bullets.

         = ;  +   = DONE

           = - Section 2.1 and following: These are examples, isn'it?  = If
           so, = this should be mentioned or = clarified.

         &= nbsp; +   DONE.  All subsections now labeled = "Example:".

       &n= bsp;   - Section 2.1: What is the PPSP = Url?

           = - Section 2.3, the 1st paragraph, detection of dead peers: = It
           would = be good to say where this detection is described in = the
           = remainder of the draft.  Just for = completeness.

        &nbs= p;  +   DONE.  Dead peer detection is now a separate = section = and
           =     referenced = here.

          = - Section 2.2, the very last paragraph, 'Peer A MAY = also':
           = This 'MAY' is not useful here.  I would just write 'Peer = A
           can = also', as there is nothing normative described = here.

          = +   = DONE

           = - Section 3.2, last paragraph: What is the = latter
           = confinement?  This is not clear to = me.

           = +   = Rephrased.

         &= nbsp; - Section 3.9, last sentence I am not sure to what = the
           = reference to Section 3.7 is pointing in this = respect.

         &nb= sp; +   = Rephrased.

         &= nbsp; - Section 3.10.1 about PEX messages The text says = 'PPSPP
           = optionally features...'.  I have not understood if = this
           = optionally refers to mandatory to implement but optionally = to
           use, = or if the PEX messages are optionally to = implement.

         &= nbsp; +   Made it clear that is OPTIONAL and not = mandatory-to-
         &n= bsp;     = implement.

         &= nbsp; - Section 3.12 I'm not sure what this section is = telling
           = exactly.  Isn't just saying that PPSPP as such does not = care
           how = chunks are stored locally, as this is = implementation
         &= nbsp; = dependent?

         &= nbsp; +   Yes. = Removed.

         &nb= sp; - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer = MAY
           = support' NEW 'The support for this scheme is = OPTIONAL'

         &n= bsp; +   DONE, for byte ranges as = well.

          = - Section 6.1.1 This section is not describing sign-all, = but
           = rather a justification why it may still work.  This = doesn't
           = help at = all.

           = - Section 7, 1st paragraph Why is there a reference to = RFC
           = 2132?

          = +   Removed, just similarity in = format.

         &nbs= p; - Section 7 in general i) It is common to give bit = positions
          = in the figures where the syntax of options is = described.
          = ; This allows to count how many bits are used for a = protocol
           = field more easily and also way more reliable. ii) Please = add
           also = Figure labels to the syntax definitions of the = options.
           = This makes it easier to reference them later on if = needed.

         &nbs= p; - Section 8.1 1 kibibyte is 1 = kbyte?

          = ; +   We follow ISO/IEC 80000-13 to avoid the kilo =3D 1000 = or
           &= nbsp;   1024 = confusion.

         &= nbsp; - Section 8.2, last paragraph i ) "All messages = are
           = idempotent" in what respect? ii) "or recognizable = as
           = duplicates" but how are the recognized as = duplicates?

         =   +   Idempotent means that processing a message twice = does = not
           =     lead to a different state than processing them = once.
          &nbs= p;    Resent handshakes can be recognized as duplicates = because
          &n= bsp;    a peer already recorded the first connection = attempt = in
           &= nbsp;   its state.  Updated = text.

          = - Section 8.5, last sentence in brackets: What is this = last
           = sentence = about?

          = ; - Section 8.13 " If sender of the PEX_REQ message does = not
           have = a private or link-local address, then the = PEX_RES*
           = messages MUST NOT contain such addresses = [RFC1918][RFC4291]."
       &n= bsp;   What is this text saying?  Do not include what you = do not
           = have = anyway?

         &nbs= p; +   Rephrased.  It tries to say that internal = addresses = must
           = ;    not be leaked to external = peers.

          = ; - Section 8.14 There is no single place where all = the
           = constants are collected and also documented what the = default
           = values or the recommended values.  For instance in = this
           = Section 8.14 where the dead peer time out is set to 3 = minutes
           = and also the number of datagrams that should have sent.  = I
           would = make a section or subsection to discuss dead peers = and
           how = they are detected and just link to the = keep-alive
          = ; mechanism in Section = 8.14.

          = +   A new section Section 12.1.1.1 "Summary of = Default
          &n= bsp;    Values" was created for this in the Ops = & Mgmt = part.

          = - Section 11 This section needs to be overhauled once = the
           = document is ready for the IESG.  The section is not wrong = but
           can = be improved to help = IANA.


 

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>=
Date: 2013/7/15
Subject: New Version Notification for = draft-ietf-ppsp-peer-protocol-07.txt
To: Riccardo Petrocco <r.petrocco@gmail.com>, Arno = Bakker <arno@cs.vu.nl>, = Victor Grishchenko <victor.grishchenko@gmail.com= >



A new version of I-D, = draft-ietf-ppsp-peer-protocol-07.txt
has been successfully submitted = by Arno Bakker and posted to the
IETF repository.

Filename: =        draft-ietf-ppsp-peer-protocol
Revision: =        07
Title:         =   Peer-to-Peer Streaming Peer Protocol (PPSPP)
Creation date: =   2013-07-15
Group:           = ppsp
Number of pages: 84
URL:           =   http://www.ietf.org/internet-drafts/draft-ietf-ppsp-pee= r-protocol-07.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-pr= otocol
Htmlized:        http://tools.ietf.org/html/draft-ietf-ppsp-peer-protoco= l-07
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-peer= -protocol-07

Abstract:
   The Peer-to-Peer = Streaming Peer Protocol (PPSPP) is a protocol for
  =  disseminating the same content to a group of interested parties in = a
   streaming fashion.  PPSPP supports streaming of = both pre-recorded
   (on-demand) and live audio/video = content.  It is based on the peer-
   to-peer = paradigm, where clients consuming the content are put on
  =  equal footing with the servers initially providing the content, = to
   create a system where everyone can potentially = provide upload
   bandwidth.  It has been designed to = provide short time-till-playback
   for the end user, and = to prevent disruption of the streams by
   malicious peers. =  PPSPP has also been designed to be flexible and
  =  extensible.  It can use different mechanisms to optimize = peer
   uploading, prevent freeriding, and work with = different peer discovery
   schemes (centralized trackers = or Distributed Hash Tables).  It
   supports multiple = methods for content integrity protection and chunk
  =  addressing.  Designed as a generic protocol that can run on = top of
   various transport protocols, it currently runs on = top of UDP using
   LEDBAT for congestion = control.




The IETF = Secretariat

 

------=_NextPart_000_00A8_01CE86DF.068AC5F0-- From r.petrocco@gmail.com Mon Jul 22 10:07:05 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBF11E8113 for ; Mon, 22 Jul 2013 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEeZu+lMaT+Q for ; Mon, 22 Jul 2013 10:07:00 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8210A11E814B for ; Mon, 22 Jul 2013 09:54:03 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so2135314wiw.17 for ; Mon, 22 Jul 2013 09:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kEUpiq9JWQYVjc+2J1qcUoAit/QDPZf+4E1Yjfd4C68=; b=KjfI8W5mVEBnOCvdAn6kXgFkRWQD8xTBt46LYP0R8gyLXwG5hDAczpDPACBJ279X+d cogRMLH05Buuw2GtgNBeAz++eLYWrBzPMpULSLpc4a3ZFymnw5IBxzhGe3TXs2UIWQmd Tf/w60uCNEu3eDLNXIw9PBCIbKwmj/drQY6p8zC6VSGLCNMjUyQs/r5auSjYUZrR5BhS unntMHvKeN9abO5+PlvZjHu3U2FZo/BtR+7twN40K1WoUSJtOGIXlJPdBkYK62W44MQz 46eNcKFdPAQD4iF6AuCnXXZnZfNwJF93/14zReKBYFfj3Db6pTCMm2oIkX84Bdsi6ywH PeYw== MIME-Version: 1.0 X-Received: by 10.180.95.201 with SMTP id dm9mr30578029wib.21.1374512042266; Mon, 22 Jul 2013 09:54:02 -0700 (PDT) Received: by 10.194.236.38 with HTTP; Mon, 22 Jul 2013 09:54:02 -0700 (PDT) In-Reply-To: <00a701ce869b$f86785f0$e93691d0$@com> References: <20130715165826.16712.69876.idtracker@ietfa.amsl.com> <00a701ce869b$f86785f0$e93691d0$@com> Date: Mon, 22 Jul 2013 18:54:02 +0200 Message-ID: From: Riccardo Petrocco To: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= Content-Type: multipart/alternative; boundary=f46d044402b604d80804e21c86b2 Cc: ppsp Subject: Re: [ppsp] =?utf-8?b?562U5aSNOiAgRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?utf-8?q?on_for_draft-ietf-ppsp-peer-protocol-07=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:07:05 -0000 --f46d044402b604d80804e21c86b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lingli, 1, The reference implementation is not available, as it requires a login > account and password? > The reference implementation is available. Just replace "https" with "http". > **** > > 2, There are a few inconsistencies with the tracker protocol:**** > > 2.1 firstly, in terms of the MPD file acquisition, the tracker protocol > states that the MPD file is acquired by the peer from the service portal, > which is out of scope of PPSP=E2=80=99s specification. Whereas your state= ment says > that the MPD file is acquired by the peer from the tracker. > I don't think we state that peers acquire the MPD file from the tracker, since that file holds the addresses of the available trackers. The main responsibility of trackers is to provide addresses of peers which are interested in the same content. > **** > > 2.2 secondly, regarding the peer enrollment, the tracker protocol states > that there will be an offline CA instead of the central tracker to issue > peers=E2=80=99 security certificates, which contradicts the relevant desc= ription in > the current peer protocol draft. > I don't see how the two descriptions contradict. >From the ppspp draft: "Several designs are possible for the security environment for these membership certificates." We provides just an example in which the tracker acts as CA, without relying on the portal. The tracker specification also suggests peers to retrieve the certificate from the portal, but it is not mandatory. Indeed we can clarify the text providing a more suitable example. > **** > > 3, As for the chunk availability specification schemes, being a highly > efficient scheme itself, the binnum scheme could be kind of heavy-weighte= d > for it requires every chunk be acknowledged a logarithmic number of times > (which may be costly and unnecessary if PPSPP is carried over a reliable > transport protocols, such as TCP). > Every chunk is acknowledged only once, and only in case an unreliable protocol, such as UDP is used. If the transmission is carried over a reliable protocol, such as TCP, each packet is acknowledged by the protocol itself. > **** > > BTW, I have been proposing a lossy compression method to mitigate this > matter. (http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/ ) > I think those are different subjects. One thing is the acknowledgement of received packets, another is sending announces of locally available content. > I=E2=80=99d appreciate it if you would provide some comments about it:-) > I browsed through the draft. Sorry but I'm currently on vacation till the meeting in Berlin :-). In my personal opinion, I don't really see the need for it. In the PPSPP peers are not announcing content to the swarm using bitmaps as in BitTorrent. The only time such an information, similar to bitmaps, is sent by a peer, is during the handshake procedure. During the handshake procedure, peers announce for the first time what they have locally available, afterwards they just send "updates" to what they have already announced. I agree with you, original bitmaps are inefficient, but that is the reason we use bin numbers or chunk/byte-ranges. Especially in a streaming environment, content is mostly downloaded in-order, hence bin numbers and chunk/byte-ranges are very well suited to send update information. See you in Berlin regards, Riccardo BR**** > > Lingli**** > > ** ** > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* ppsp-bounces@ietf.org [mailto:ppsp-bounces= @ietf.org] *=E4=BB=A3=E8=A1=A8 *Riccardo > Petrocco > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2013=E5=B9=B47=E6=9C=8816=E6=97= =A5 1:21 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* ppsp > *=E4=B8=BB=E9=A2=98:* [ppsp] Fwd: New Version Notification for > draft-ietf-ppsp-peer-protocol-07.txt**** > > ** ** > > Hi all,**** > > I just uploaded an updated version of the peer protocol draft.**** > > We mostly focused on the issues presented in the recent AD review.**** > > Unfortunately due to the lack of time, and the extensive review, some > points still need to be addressed.**** > > See you in Berlin, > ciao, > Riccardo**** > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > -07 2013-06-19 Revision following AD Review > > Quoting the AD review by Martin Stiemerling: ***High-level > issues: > > 1) Merkle Hash Trees I have found the document very confusing > on whether Merkle Hash Trees (MHTs) and the for the MHT > required bin numbering scheme are now optional or mandatory. > Parts of the draft make the impression that either of them or > both or optional (mainly in the beginning of the document), > while Section 5 and later Sections are relying heavily on > MHTs. My naive reading of the current draft is that you > could rely on start-end ranges for chunk addressing and MHTs > for content protection. However, I do know that this > combination is not working. If MHTs are really optional, > including the bin numbering, the document should really state > this and make clear what the operations of the protocol are > with the mandatory to implement (MTI) mechanisms. The MHT, > bins, and all the protocol handling should go in an appendix. > There is a call to make for the WG: I do know that MHTs were > considered by some as burden and they have called for a > leaner way, i.e., the start-end ranges. The call for the > leaner way has been implemented in the document but not > fully. > > + The text now states that MHTs SHOULD be used unless in > benign environments and are mandatory-to-implement. It > also states that only start-end chunk range is mandatory- > to-implement, and bins are optional. > > 2) LEDBAT as congestion control vs. PPSPP The PPSP peer > protocol is intended for the Standards Track and relies in a > normative manner on LEDBAT (RFC 6817). LEDBAT as such is an > **experimental** delay-based congestion control algorithm. A > Standards Track protocol cannot normatively rely on an > Experimental congestion control mechanism (or RFC in > general). There are ways out of this situation: i) Do not > use ledbat: this would call for another congestion control > mechanism to be described in the PPSPP draft. ii) Work on an > 'upgrade' of the LEDBAT specification to Standards Track: > Possible, but a very long way. iii) Agree on having PPSPP > also as Experimental protocol. I'm currently leaning towards > option iii), but this is my pure personal opinion as an > individual in the IETF. > > + A new paragraph has been added to Section 8.16 describing > the feasibility of LEDBAT in P2P systems. > > 3) No formal protocol message definition Section 7 and more > specific Section 8 describe the protocol syntax of the > protocol options and the messages, though Section 8 is > talking about UDP encapsulation. Section 7 is hard to digest > if someone should implement the options, see also later, but > Section 8 is almost impossible to understand by somebody who > has not been involved in the PPSP working group. See also > further down for a more detailed review of the sections. To > give an example out of Section 8.4: This section describes > the HANDSHAKE message and gives examples how such a HANDSHAKE > message could look like. But no formal definition of the > message is given leaving a number of thins unclear, such as > what the local channel number and what's the remote channel > number is. This is implicitly defined, but that is not a > good way of writing Standards Track drafts. > > 4) Implicit use of default values There are a number of > places all over the draft where default values are defined. > Many of those default values are used when there are no > values explicitly signaled, e.g., the default chunk size of 1 > Kbyte in Section 8.4 or Section Section 7.5. with the default > for the Content Integrity Protection Method. I have the > feeling that the protocol and the surroundings (e.g., what > comes in via the 'tracker') are over-optimized, e.g., always > providing the Content Integrity Protection Method as part of > the Protocol options will not waste more than 2 bytes in a > HANDSHAKE message. Further, I do not see the need to define > a default chunk size in the base protocol specification, as > this default can look very different, depending on who is > deploying the protocol and in what context. This calls for a > more dynamic way of handling the system chunk size, either as > part of an external mechanisms (e.g. via the tracker) or in > the HANDSHAKE message. > > + Removed implicit defaults from protocol options. Chunk > size is part of the content's metadata and thus > configurable. The default 1KiB has been turned into a > recommendation. > > 5) Concept of channels The concept of channels is good but it > is introduced too late in the draft, namely in Section 8.3, > and it is introduced with very few words. Why isn't this > introduced as part of Section 2 or Section 3, also in the > relationship to the used transport protocol? I.e., the > intention is to keep only one transport 'connection' between > two distinct peers and to allow to run multiple swarm > instances at the same time over the same transport. And how > do swarms and channels correlate? > > + Concept now introduced in Section 3 with a figure. > > ***Technicals: > > - Section 2.1, 2nd paragraph, about the tracker: I haven't > seen a single place where the interaction with a tracker is > discussed or where the tracker less operation is discussed in > contrast. It is further unclear what type of information is > really required from a tracker. A tracker (or a resource > directory) would need to provide more then IP address & port, > e.g., the used transport protocol for the protocol exchange > (given that other transports are allowed), used chunk size, > chunk addressing scheme, etc > > - Section 2.3, the 1st paragraph, 'close-channel': This has > been the first time where I stumbled over the channel without > knowing the concept. > > + Rephrased. > > - Section 3.1: ordering of messages The 1st sentence implies > that ordering of messages in a datagram matters a lot. This > is outlined later in the document, but I would add this as > part of 3., i.e., the messages are processed in the strict > order or something along this line. > > - Section 3.1, 1st paragraph, options to include I would not > say anything about 'SHOULD include options' here, as this is > anyhow described in Section 8. > > + Phrase removed. > > - Section 3.1, 2nd paragraph: "Datagrams exchanged MAY also > contain some minor payload, e.g. HAVE messages to indicate > the current progress of a peer or a REQUEST (see Section > 3.7)." to be added, just to make it clear IMHO: ", but MUST > NOT include any DATA message". > > + Added. > > - Section 3.2, 2nd paragraph: "In particular, whenever a > receiving peer has successfully checked the integrity of a > chunk or interval of chunks it MUST send a HAVE message to > all peers it wants to interact with in the near future." > This looks like a place where a lot of traffic can be send > out of a peer, i.e., whenever a chunk arrives a HAVE message > must be sent. I don't believe that this should be mandated > by the protocol specification, but there should guidance on > when to send this, e.g., peers might be also able to wait for > a short period of time to gather more chunks to be reported > in HAVE. Or should in this case a single UDP datagram > contain multiple HAVEs? > > + Clarified. > > - Section 3.4 on ACKs This section looks pretty weak, as ACKs > may be sent but on the other hand MUST be sent if ledbat is > used. I would simply say: - ACK MUST be sent if an > unreliable transport protocol is used - ACK MAY be sent if a > reliable transport protocol is used - keep clarification > about ledbat. > > + DONE. > > - Section 3.5: Give text where INTEGERITY is described at > least for the MTI scheme. > > + DONE. > > - Section 3.7, 2nd paragraph - all 'MAY' are actually not > right here. Please remove or replace them with lower letters > if appropriate. - It is not clear what the 'sequentially' > means exactly. Is it in the received order? > > + First point TODO. "Sequentially" replaced with "received > order". > > - Section 3.8: Please replace 'MAY' by can, as those are not > normative behaviors but more the fact that peers can, for > instance, request urgent data. > > + DONE. > > - Section 3.9 Same comment as for the Section 3.8 just above > this comment. > > + DONE. > > - Section 3.9 waiting for responses OLD " When peer B > receives a CHOKE message from A it MUST NOT send new REQUEST > messages and SHOULD NOT expect answers to any outstanding > ones." NEW " When peer B receives a CHOKE message from A it > MUST NOT send new REQUEST messages and it cannot expect > answers to any outstanding ones, as the transfer of chunks is > choked." > > + DONE. > > - Section 3.10.2 This whole section about PEX hole punching > reads very, very experimental. The STUN method is ok, but > PEX isn't. First of all, the safe behavior for a peer when > it receives unsolicited PEX messages, is to discard those > messages. Second, this unsolicited PEX messages trigger some > behavior which may open an attack vector. The best way, but > this needs more discussion, is to include to some token in > the messages that are exchanged in order to make avoid any > blind attacks here. However, this will need more and > detailed discussions of the purpose of this. > > + TODO: hole punching comment. > > + We moved parts of the security analysis of PEX up, such > that all mechanisms are explained in the main text, and > the analysis of what attacks there are and how these > mechanisms prevent them is in the Sec. Considerations > section. > > - Section 3.11 I don't see the 'MUST send keep-alive' as a > mandatory requirement, as peers might have good reasons not > to send any keep alive. Why not saying 'A peer can send a > keep-alive' and it 'MUST use the simple datagram...' as > already described. Though there is also no really need to > say MUST. > > + Now Section 3.12. Rephrased and clarified the reason and > consequences of sending keep-alive msgs. > > - Section 4 The syntax definition for each of the chunk > addressing schemes is missing. This is not suitable for any > specification that aims at interoperable implementations. > > - Section 4.3.2 PPSPP peers MUST use the ACK message if an > unreliable transport protocol is used. > > + DONE. > > - Section 4.4 Has been tested in an implementation? I would > like to understand the need for such a section, as in my > understanding a peer implementation should chose one scheme > and support this and there shouldn't be the need to convert > between the different schemes. > > - Section 5 This reads that MHTs are mandatory to implement > while the document makes the impression that MHTs are > optional. > > + Rephrased, see High-level issues. > > - Section 5.3 " so each datagram SHOULD be processed > separately and a loss of one datagram MUST NOT disrupt the > flow" The MUST NOT is not a protocol specification > requirement, but more an informative part saying that a lost > message shouldn't impact the protocol machinery, but it can > impact the overall operation. What is the flow here in that > sentence? > > + Rephrased. > > - Section 5.6.2. An illustrative example explaining how the > automatic size detection works is required here. > > + Added a paragraph with an example that follows the figure > used during the explanation. A state diagram could also > be added, but bight be a bit redundant. > > - Section 6.1, 4th paragraph: Where do I find the 1 byte > algorithm field in the swarm ID? The swarm ID is not really > defined in a single place. > > + Expanded. TODO: Formal spec of swarm ID. > > - Section 7.3 The described min/max versioning relies on the > fact that there are major and minor version numbers. I > cannot find any major and minor version number scheme in the > draft. > > + Actually, it does not. > > - Section 7.4, Length field It is not clear what the 'Length' > field is referring to. Further, it is not clear of the swam > IDs are concatenated in one swarm ID option, of each swarm ID > must be placed in a separate swam ID option. > > - Section 7.6 MHTs are mandatory to support though MHTs are > optional? > > + Clarified. > > - Section 7.7 'key size ... derived from the swarm ID'. This > relates to my high level comment no 4. on the use of implicit > information. Either it is clearly specified how this > information is derived or there is a protocol field/ > information about the size. > > + Key size derivation procedure added to description of > SIGNED_INTEGRITY in UDP encapsulation. > > - Section 7.8 I would recommend to say that the default MUST > be supported, but the peer must always signal what method it > is supporting or at least using. > > + Corrected, see High-level issues 4.) > > - Section 7.10 I have not understood how the 'Lenght' field > relates to the message bitmap and how long the message bitmap > can grow. The figure looks like a maximum of 16 bits? > > + Clarified. > > - Section 8 I do not see the value of the text in the preface > of Section 8. I would say that this text should say what is > mandatory and what's not, i.e., MUST use UDP and MUST use > LEDBAT. Potentially saying that future protocol versions can > also run over other transport protocols. > > + Adjusted. > > - Section 8.1 about Maximum Transfer Unit (MTU) The text is > discussing that a Ethernet can carry 1500 bytes. This is > true, but the Ethernet payload is not the normative MTU > across all of the Internet. For IPv6 the min MTU is 1280 > bytes and for IPv4 it is 576 bytes, though for IPv4 it can be > theoretically much lower at 64 bytes. It would move the > definition of the default chunk size to a recommendation with > text saying that this size has a high likelihood to travel > end-to-end in the Internet without any fragmentation. > Fragmentation might increase the loss of complete chunks, as > one lost fragment will cause the loss of a complete chunk. > One way of getting an informed decision on whether chunks can > travel in their size is to use the Don't Fragment (DF) bit in > IPv4 and also to watch for ICMP error messages. However, > ICMP error messages are not a reliable indication, but they > can be some indication. > > + 1 KiB chunk size has been made a recommendation. > > - Section 8.1 Definition of the default chunk size There is > no need to define a default chunk size, if the chunk size > would be always signaled per swarm. This is another default/ > implicit value places that is unnecessary. > > + The chunk size is always part of the content's metadata. > > - Section 8.3: see also my comment no 3. The concept of > channels is introduced very late and with few words. A > figure to explain the concept will help a lot and also more > formal text on what a channel is and how they are identified. > Also what the init channel is. > > + Concept now introduced in Section 3.11. TODO init > channel. > > - Section 8 in general: There is no formal definition of the > messages, just bit pattern examples. > > - Section 8.4 (as example for the other Sections in 8.x): i) > What is the '(CHANNEL' paramter? Is it actually a parameter? > ii) it is implicit that the first channel no (0000000) is the > remote peer's channel and that the second channel no > (00000011) is the local peer's channel, right? This isn't > clear from the text, but my guess. > > - Section 8.5 Can HAVE messages multiple bin specs in one > message or do I have to make a HAVE message for each bin? > > + Clarified. > > - Section 8.6 What is the formal defintion of a DATA message? > That's completely missing or I have not understood it. > > - Section 8.7 looks just underspecified, especially as this > is the link to LEDBAT. > > - Section 8.11 How are the chunks specified here? The formal > syntax definition or reference to one is missing. > > - Section 8.13 I'm lost on this section, as I haven't fully > understood the concept of the PEX in this document. > Especially not why there is the PEX_REScert. > > + We moved parts of the security analysis of PEX up into > 3.10, such that all mechanisms are explained in the main > text, and the analysis of what attacks there are and how > these mechanisms prevent them is in the Sec. > Considerations section. > > - Section 11 The RFC required for protocol extensions of a > standards track protocol looks odd. This must be at least > IETF Review or Standards Action. > > ***Editorials: > > - Abstract (and probably also other places), 1st sentence of, > PPSPP is not a transport protocol, just a protocol > > + DONE > > - Section 1.1, 4th paragraph: I would remove the reference to > rmcat, as it is not yet clear what the outcome of the rmcat > wg will be > > + DONE > > - Section 1.3, on page 8, about seeding/leeching: I would > break it in to sub-bullets. > > + DONE > > - Section 2.1 and following: These are examples, isn'it? If > so, this should be mentioned or clarified. > > + DONE. All subsections now labeled "Example:". > > - Section 2.1: What is the PPSP Url? > > - Section 2.3, the 1st paragraph, detection of dead peers: It > would be good to say where this detection is described in the > remainder of the draft. Just for completeness. > > + DONE. Dead peer detection is now a separate section and > referenced here. > > - Section 2.2, the very last paragraph, 'Peer A MAY also': > This 'MAY' is not useful here. I would just write 'Peer A > can also', as there is nothing normative described here. > > + DONE > > - Section 3.2, last paragraph: What is the latter > confinement? This is not clear to me. > > + Rephrased. > > - Section 3.9, last sentence I am not sure to what the > reference to Section 3.7 is pointing in this respect. > > + Rephrased. > > - Section 3.10.1 about PEX messages The text says 'PPSPP > optionally features...'. I have not understood if this > optionally refers to mandatory to implement but optionally to > use, or if the PEX messages are optionally to implement. > > + Made it clear that is OPTIONAL and not mandatory-to- > implement. > > - Section 3.12 I'm not sure what this section is telling > exactly. Isn't just saying that PPSPP as such does not care > how chunks are stored locally, as this is implementation > dependent? > > + Yes. Removed. > > - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer MAY > support' NEW 'The support for this scheme is OPTIONAL' > > + DONE, for byte ranges as well. > > - Section 6.1.1 This section is not describing sign-all, but > rather a justification why it may still work. This doesn't > help at all. > > - Section 7, 1st paragraph Why is there a reference to RFC > 2132? > > + Removed, just similarity in format. > > - Section 7 in general i) It is common to give bit positions > in the figures where the syntax of options is described. > This allows to count how many bits are used for a protocol > field more easily and also way more reliable. ii) Please add > also Figure labels to the syntax definitions of the options. > This makes it easier to reference them later on if needed. > > - Section 8.1 1 kibibyte is 1 kbyte? > > + We follow ISO/IEC 80000-13 to avoid the kilo =3D 1000 or > 1024 confusion. > > - Section 8.2, last paragraph i ) "All messages are > idempotent" in what respect? ii) "or recognizable as > duplicates" but how are the recognized as duplicates? > > + Idempotent means that processing a message twice does not > lead to a different state than processing them once. > Resent handshakes can be recognized as duplicates because > a peer already recorded the first connection attempt in > its state. Updated text. > > - Section 8.5, last sentence in brackets: What is this last > sentence about? > > - Section 8.13 " If sender of the PEX_REQ message does not > have a private or link-local address, then the PEX_RES* > messages MUST NOT contain such addresses [RFC1918][RFC4291]." > What is this text saying? Do not include what you do not > have anyway? > > + Rephrased. It tries to say that internal addresses must > not be leaked to external peers. > > - Section 8.14 There is no single place where all the > constants are collected and also documented what the default > values or the recommended values. For instance in this > Section 8.14 where the dead peer time out is set to 3 minutes > and also the number of datagrams that should have sent. I > would make a section or subsection to discuss dead peers and > how they are detected and just link to the keep-alive > mechanism in Section 8.14. > > + A new section Section 12.1.1.1 "Summary of Default > Values" was created for this in the Ops & Mgmt part. > > - Section 11 This section needs to be overhauled once the > document is ready for the IESG. The section is not wrong but > can be improved to help IANA. > > > **** > > ** ** > > ---------- Forwarded message ---------- > From: > Date: 2013/7/15 > Subject: New Version Notification for draft-ietf-ppsp-peer-protocol-07.tx= t > To: Riccardo Petrocco , Arno Bakker = , > Victor Grishchenko > > > > A new version of I-D, draft-ietf-ppsp-peer-protocol-07.txt > has been successfully submitted by Arno Bakker and posted to the > IETF repository. > > Filename: draft-ietf-ppsp-peer-protocol > Revision: 07 > Title: Peer-to-Peer Streaming Peer Protocol (PPSPP) > Creation date: 2013-07-15 > Group: ppsp > Number of pages: 84 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-ppsp-peer-protocol-07.txt > Status: > http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol > Htmlized: > http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-07 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-peer-protocol-07 > > Abstract: > The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for > disseminating the same content to a group of interested parties in a > streaming fashion. PPSPP supports streaming of both pre-recorded > (on-demand) and live audio/video content. It is based on the peer- > to-peer paradigm, where clients consuming the content are put on > equal footing with the servers initially providing the content, to > create a system where everyone can potentially provide upload > bandwidth. It has been designed to provide short time-till-playback > for the end user, and to prevent disruption of the streams by > malicious peers. PPSPP has also been designed to be flexible and > extensible. It can use different mechanisms to optimize peer > uploading, prevent freeriding, and work with different peer discovery > schemes (centralized trackers or Distributed Hash Tables). It > supports multiple methods for content integrity protection and chunk > addressing. Designed as a generic protocol that can run on top of > various transport protocols, it currently runs on top of UDP using > LEDBAT for congestion control. > > > > > The IETF Secretariat**** > > ** ** > --f46d044402b604d80804e21c86b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SGkgTGluZ2xpLDxicj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGxh bmc9IkVOLVVTIj48L3NwYW4+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXIt bGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iWkgtQ04iPjxkaXY+PHAgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzMSw3MywxMjUpIiBsYW5nPSJF Ti1VUyI+MSwgVGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiBpcyBub3QgYXZhaWxhYmxlLCBh cyBpdCByZXF1aXJlcyBhIGxvZ2luIGFjY291bnQgYW5kIHBhc3N3b3JkPzwvc3Bhbj48L3A+DQo8 L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj5UaGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9u IGlzIGF2YWlsYWJsZS4gPC9kaXY+PGRpdj48L2Rpdj48ZGl2Pkp1c3QgcmVwbGFjZSAmcXVvdDto dHRwcyZxdW90OyB3aXRoICZxdW90O2h0dHAmcXVvdDsuPGJyPjwvZGl2PjxkaXY+wqA8L2Rpdj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+DQo8ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGxhbmc9IlpILUNOIj48ZGl2 PjxwIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzEsNzMs MTI1KSIgbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGxhbmc9IkVO LVVTIj4yLCBUaGVyZSBhcmUgYSBmZXcgaW5jb25zaXN0ZW5jaWVzIHdpdGggdGhlIHRyYWNrZXIg cHJvdG9jb2w6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiIgc3R5bGU9Im1h cmdpbi1sZWZ0OjIxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzEs NzMsMTI1KSIgbGFuZz0iRU4tVVMiPjIuMSBmaXJzdGx5LCBpbiB0ZXJtcyBvZiB0aGUgTVBEIGZp bGUgYWNxdWlzaXRpb24sIHRoZSB0cmFja2VyIHByb3RvY29sIHN0YXRlcyB0aGF0IHRoZSBNUEQg ZmlsZSBpcyBhY3F1aXJlZCBieSB0aGUgcGVlciBmcm9tIHRoZSBzZXJ2aWNlIHBvcnRhbCwgd2hp Y2ggaXMgb3V0IG9mIHNjb3BlIG9mIFBQU1DigJlzIHNwZWNpZmljYXRpb24uIFdoZXJlYXMgeW91 ciBzdGF0ZW1lbnQgc2F5cyB0aGF0IHRoZSBNUEQgZmlsZSBpcyBhY3F1aXJlZCBieSB0aGUgcGVl ciBmcm9tIHRoZSB0cmFja2VyLjwvc3Bhbj48L3A+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+ PGRpdj5JIGRvbiYjMzk7dCB0aGluayB3ZSBzdGF0ZSB0aGF0IHBlZXJzIGFjcXVpcmUgdGhlIE1Q RCBmaWxlIGZyb20gdGhlIHRyYWNrZXIsIHNpbmNlIHRoYXQgZmlsZSBob2xkcyB0aGUgYWRkcmVz c2VzIG9mIHRoZSBhdmFpbGFibGUgdHJhY2tlcnMuPGJyPjwvZGl2PjxkaXY+VGhlIG1haW4gcmVz cG9uc2liaWxpdHkgb2YgdHJhY2tlcnMgaXMgdG8gcHJvdmlkZSBhZGRyZXNzZXMgb2YgcGVlcnMg d2hpY2ggYXJlIGludGVyZXN0ZWQgaW4gdGhlIHNhbWUgY29udGVudC48YnI+DQo8L2Rpdj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCI+PGRpdiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJaSC1DTiI+PGRpdj48cCBj bGFzcz0iIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnJnYigzMSw3MywxMjUpIiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgbGFuZz0iRU4tVVMiPjIuMiBz ZWNvbmRseSwgcmVnYXJkaW5nIHRoZSBwZWVyIGVucm9sbG1lbnQsIHRoZSB0cmFja2VyIHByb3Rv Y29sIHN0YXRlcyB0aGF0IHRoZXJlIHdpbGwgYmUgYW4gb2ZmbGluZSBDQSBpbnN0ZWFkIG9mIHRo ZSBjZW50cmFsIHRyYWNrZXIgdG8gaXNzdWUgcGVlcnPigJkgc2VjdXJpdHkgY2VydGlmaWNhdGVz LCB3aGljaCBjb250cmFkaWN0cyB0aGUgcmVsZXZhbnQgZGVzY3JpcHRpb24gaW4gdGhlIGN1cnJl bnQgcGVlciBwcm90b2NvbCBkcmFmdC48L3NwYW4+PC9wPg0KPC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjxkaXY+SSBkb24mIzM5O3Qgc2VlIGhvdyB0aGUgdHdvIGRlc2NyaXB0aW9ucyBjb250cmFk aWN0Ljxicj48L2Rpdj48ZGl2PkZyb20gdGhlIHBwc3BwIGRyYWZ0OiAmcXVvdDtTZXZlcmFsIGRl c2lnbnMgYXJlIHBvc3NpYmxlIGZvciB0aGUgc2VjdXJpdHkgZW52aXJvbm1lbnQgZm9yIHRoZXNl IG1lbWJlcnNoaXAgY2VydGlmaWNhdGVzLiZxdW90Ozxicj4NCjwvZGl2PjxkaXY+V2UgcHJvdmlk ZXMganVzdCBhbiBleGFtcGxlIGluIHdoaWNoIHRoZSB0cmFja2VyIGFjdHMgYXMgQ0EsIHdpdGhv dXQgcmVseWluZyBvbiB0aGUgcG9ydGFsLiBUaGUgdHJhY2tlciBzcGVjaWZpY2F0aW9uIGFsc28g c3VnZ2VzdHMgcGVlcnMgdG8gcmV0cmlldmUgdGhlIGNlcnRpZmljYXRlIGZyb20gdGhlIHBvcnRh bCwgYnV0IGl0IGlzIG5vdCBtYW5kYXRvcnkuPGJyPg0KPC9kaXY+PGRpdj5JbmRlZWQgd2UgY2Fu IGNsYXJpZnkgdGhlIHRleHQgcHJvdmlkaW5nIGEgbW9yZSBzdWl0YWJsZSBleGFtcGxlLjxicj48 L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBw eCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGlu Zy1sZWZ0OjFleCI+PGRpdiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJaSC1DTiI+ DQo8ZGl2PjxwIGNsYXNzPSIiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGxhbmc9IkVOLVVTIj48dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJnYigzMSw3MywxMjUpIiBsYW5nPSJFTi1VUyI+MywgQXMgZm9yIHRoZSBjaHVuayBh dmFpbGFiaWxpdHkgc3BlY2lmaWNhdGlvbiBzY2hlbWVzLCBiZWluZyBhIGhpZ2hseSBlZmZpY2ll bnQgc2NoZW1lIGl0c2VsZiwgdGhlIGJpbm51bSBzY2hlbWUgY291bGQgYmUga2luZCBvZiBoZWF2 eS13ZWlnaHRlZCBmb3IgaXQgcmVxdWlyZXMgZXZlcnkgY2h1bmsgYmUgYWNrbm93bGVkZ2VkIGEg bG9nYXJpdGhtaWMgbnVtYmVyIG9mIHRpbWVzICh3aGljaCBtYXkgYmUgY29zdGx5IGFuZCB1bm5l Y2Vzc2FyeSBpZiBQUFNQUCBpcyBjYXJyaWVkIG92ZXIgYSByZWxpYWJsZSB0cmFuc3BvcnQgcHJv dG9jb2xzLCBzdWNoIGFzIFRDUCkuIDwvc3Bhbj48L3A+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj5FdmVyeSBjaHVuayBpcyBhY2tub3dsZWRnZWQgb25seSBvbmNlLCBhbmQgb25seSBp biBjYXNlIGFuIHVucmVsaWFibGUgcHJvdG9jb2wsIHN1Y2ggYXMgVURQIGlzIHVzZWQuPGJyPjwv ZGl2PjxkaXY+SWYgdGhlIHRyYW5zbWlzc2lvbiBpcyBjYXJyaWVkIG92ZXIgYSByZWxpYWJsZSBw cm90b2NvbCwgc3VjaCBhcyBUQ1AsIGVhY2ggcGFja2V0IGlzIGFja25vd2xlZGdlZCBieSB0aGUg cHJvdG9jb2wgaXRzZWxmLjxicj4NCjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQg cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiIGxhbmc9IlpILUNOIj48ZGl2PjxwIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzEsNzMsMTI1KSIgbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpyZ2IoMzEsNzMsMTI1KSIgbGFuZz0iRU4tVVMiPkJUVywgSSBoYXZlIGJlZW4gcHJvcG9z aW5nIGEgbG9zc3kgY29tcHJlc3Npb24gbWV0aG9kIHRvIG1pdGlnYXRlIHRoaXMgbWF0dGVyLiAo PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZW5nLXBwc3At YmZiaXRtYXAvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1kZW5nLXBwc3AtYmZiaXRtYXAvPC9hPiApPC9zcGFuPjwvcD4NCjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48ZGl2PkkgdGhpbmsgdGhvc2UgYXJlIGRpZmZlcmVudCBzdWJqZWN0cy48 YnI+PC9kaXY+PGRpdj5PbmUgdGhpbmcgaXMgdGhlIGFja25vd2xlZGdlbWVudCBvZiByZWNlaXZl ZCBwYWNrZXRzLCBhbm90aGVyIGlzIHNlbmRpbmcgYW5ub3VuY2VzIG9mIGxvY2FsbHkgYXZhaWxh YmxlIGNvbnRlbnQuPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSIgbGFuZz0iWkgtQ04iPjxkaXY+PHAgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOnJnYigzMSw3MywxMjUpIiBsYW5nPSJFTi1VUyI+SeKAmWQgYXBwcmVjaWF0 ZSBpdCBpZiB5b3Ugd291bGQgcHJvdmlkZSBzb21lIGNvbW1lbnRzIGFib3V0IGl0Oi0pPC9zcGFu PjwvcD4NCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PkkgYnJvd3NlZCB0aHJvdWdoIHRo ZSBkcmFmdC4gPGJyPlNvcnJ5IGJ1dCBJJiMzOTttIGN1cnJlbnRseSBvbiB2YWNhdGlvbiB0aWxs IHRoZSBtZWV0aW5nIGluIEJlcmxpbiA6LSkuPGJyPjxicj48L2Rpdj48ZGl2PkluIG15IHBlcnNv bmFsIG9waW5pb24sIEkgZG9uJiMzOTt0IHJlYWxseSBzZWUgdGhlIG5lZWQgZm9yIGl0LiBJbiB0 aGUgUFBTUFAgcGVlcnMgYXJlIG5vdCBhbm5vdW5jaW5nIGNvbnRlbnQgdG8gdGhlIHN3YXJtIHVz aW5nIGJpdG1hcHMgYXMgaW4gQml0VG9ycmVudC48YnI+DQo8L2Rpdj48ZGl2PlRoZSBvbmx5IHRp bWUgc3VjaCBhbiBpbmZvcm1hdGlvbiwgc2ltaWxhciB0byBiaXRtYXBzLCBpcyBzZW50IGJ5IGEg cGVlciwgaXMgZHVyaW5nIHRoZSBoYW5kc2hha2UgcHJvY2VkdXJlLjxicj5EdXJpbmcgdGhlIGhh bmRzaGFrZSBwcm9jZWR1cmUsIHBlZXJzIGFubm91bmNlIGZvciB0aGUgZmlyc3QgdGltZSB3aGF0 IHRoZXkgaGF2ZSBsb2NhbGx5IGF2YWlsYWJsZSwgYWZ0ZXJ3YXJkcyB0aGV5IGp1c3Qgc2VuZCAm cXVvdDt1cGRhdGVzJnF1b3Q7IHRvIHdoYXQgdGhleSBoYXZlIGFscmVhZHkgYW5ub3VuY2VkLjxi cj4NCjwvZGl2PjxkaXY+SSBhZ3JlZSB3aXRoIHlvdSwgb3JpZ2luYWwgYml0bWFwcyBhcmUgaW5l ZmZpY2llbnQsIGJ1dCB0aGF0IGlzIHRoZSByZWFzb24gd2UgdXNlIGJpbiBudW1iZXJzIG9yIGNo dW5rL2J5dGUtcmFuZ2VzLiBFc3BlY2lhbGx5IGluIGEgc3RyZWFtaW5nIGVudmlyb25tZW50LCBj b250ZW50IGlzIG1vc3RseSBkb3dubG9hZGVkIDxicj5pbi1vcmRlciwgaGVuY2UgYmluIG51bWJl cnMgYW5kIGNodW5rL2J5dGUtcmFuZ2VzIGFyZSB2ZXJ5IHdlbGwgc3VpdGVkIHRvIHNlbmQgdXBk YXRlIGluZm9ybWF0aW9uLjxicj4NCjxicj48L2Rpdj48ZGl2PlNlZSB5b3UgaW4gQmVybGluPGJy PjwvZGl2PjxkaXY+cmVnYXJkcyw8YnI+PC9kaXY+PGRpdj5SaWNjYXJkbzxicj48YnI+PGJyPjwv ZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzMSw3MywxMjUp IiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp ZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSIgbGFuZz0iWkgtQ04iPjxkaXY+PHAgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzMSw3MywxMjUpIiBsYW5nPSJFTi1VUyI+QlI8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6cmdiKDMxLDczLDEyNSkiIGxhbmc9IkVOLVVTIj5MaW5nbGk8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OnJnYigzMSw3MywxMjUpIiBsYW5nPSJFTi1VUyI+PHU+PC91PsKgPHU+PC91Pjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6MXB0IG1lZGl1bSBtZWRpdW07Ym9yZGVyLXN0eWxl OnNvbGlkIG5vbmUgbm9uZTtib3JkZXItY29sb3I6cmdiKDE4MSwxOTYsMjIzKSAtbW96LXVzZS10 ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3I7cGFkZGluZzozcHQgMGNtIDBjbSI+PHAgY2xh c3M9IiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+ 5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk65a6L5L2TIiBsYW5nPSJFTi1VUyI+IDxhIGhy ZWY9Im1haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wcHNwLWJv dW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBwc3AtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBwc3AtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7ku6Po oaggPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk65a6L 5L2TIiBsYW5nPSJFTi1VUyI+UmljY2FyZG8gUGV0cm9jY288YnI+DQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwcHQ7Zm9udC1mYW1pbHk65a6L5L2TIiBsYW5nPSJFTi1VUyI+IDIwMTM8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PHNwYW4gbGFuZz0i RU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE2PC9zcGFuPuaXpTxzcGFuIGxh bmc9IkVOLVVTIj4gMToyMTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBwcHNwPGJyPjwvc3Bhbj48Yj7kuLvp opg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbcHBz cF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcHBzcC1wZWVy LXByb3RvY29sLTA3LnR4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj48 ZGl2PjxkaXYgY2xhc3M9Img1Ij48cCBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91 PsKgPHU+PC91Pjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSIi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEycHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSIiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEycHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkkganVzdCB1cGxvYWRlZCBhbiB1cGRhdGVk IHZlcnNpb24gb2YgdGhlIHBlZXIgcHJvdG9jb2wgZHJhZnQuPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPjwvZGl2PjxwIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBtb3N0bHkgZm9jdXNl ZCBvbiB0aGUgaXNzdWVzIHByZXNlbnRlZCBpbiB0aGUgcmVjZW50IEFEIHJldmlldy48dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj48cCBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VW5mb3J0dW5hdGVseSBkdWUgdG8gdGhlIGxhY2sg b2YgdGltZSwgYW5kIHRoZSBleHRlbnNpdmUgcmV2aWV3LCBzb21lIHBvaW50cyBzdGlsbCBuZWVk IHRvIGJlIGFkZHJlc3NlZC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9 IiI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlZSB5b3UgaW4gQmVybGluLDxicj4NCmNpYW8sPGJyPlJp Y2NhcmRvPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9IiIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj48YnI+PT09PT09PT09PT09 PT09PT09PT09PT09PTxicj48YnI+wqAgLTA3wqDCoMKgwqDCoMKgwqAgMjAxMy0wNi0xOSBSZXZp c2lvbiBmb2xsb3dpbmcgQUQgUmV2aWV3PGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBRdW90 aW5nIHRoZSBBRCByZXZpZXcgYnkgTWFydGluIFN0aWVtZXJsaW5nOiAqKipIaWdoLWxldmVsPGJy Pg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgaXNzdWVzOjxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqAgMSkgTWVya2xlIEhhc2ggVHJlZXMgSSBoYXZlIGZvdW5kIHRoZSBkb2N1bWVudCB2ZXJ5IGNv bmZ1c2luZzxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBvbiB3aGV0aGVyIE1lcmtsZSBIYXNoIFRy ZWVzIChNSFRzKSBhbmQgdGhlIGZvciB0aGUgTUhUPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHJl cXVpcmVkIGJpbiBudW1iZXJpbmcgc2NoZW1lIGFyZSBub3cgb3B0aW9uYWwgb3IgbWFuZGF0b3J5 Ljxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIFBhcnRzIG9mIHRoZSBkcmFmdCBtYWtlIHRoZSBp bXByZXNzaW9uIHRoYXQgZWl0aGVyIG9mIHRoZW0gb3I8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAg Ym90aCBvciBvcHRpb25hbCAobWFpbmx5IGluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGRvY3VtZW50 KSw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgd2hpbGUgU2VjdGlvbiA1IGFuZCBsYXRlciBTZWN0 aW9ucyBhcmUgcmVseWluZyBoZWF2aWx5IG9uPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgTUhU cy7CoCBNeSBuYWl2ZSByZWFkaW5nIG9mIHRoZSBjdXJyZW50IGRyYWZ0IGlzIHRoYXQgeW91PGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvdWxkIHJlbHkgb24gc3RhcnQtZW5kIHJhbmdlcyBmb3Ig Y2h1bmsgYWRkcmVzc2luZyBhbmQgTUhUczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBmb3IgY29u dGVudCBwcm90ZWN0aW9uLsKgIEhvd2V2ZXIsIEkgZG8ga25vdyB0aGF0IHRoaXM8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgY29tYmluYXRpb24gaXMgbm90IHdvcmtpbmcuwqAgSWYgTUhUcyBhcmUg cmVhbGx5IG9wdGlvbmFsLDxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIGluY2x1ZGluZyB0aGUg YmluIG51bWJlcmluZywgdGhlIGRvY3VtZW50IHNob3VsZCByZWFsbHkgc3RhdGU8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgdGhpcyBhbmQgbWFrZSBjbGVhciB3aGF0IHRoZSBvcGVyYXRpb25zIG9m IHRoZSBwcm90b2NvbCBhcmU8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgd2l0aCB0aGUgbWFuZGF0 b3J5IHRvIGltcGxlbWVudCAoTVRJKSBtZWNoYW5pc21zLsKgIFRoZSBNSFQsPGJyPg0KwqDCoMKg wqDCoMKgwqDCoMKgwqAgYmlucywgYW5kIGFsbCB0aGUgcHJvdG9jb2wgaGFuZGxpbmcgc2hvdWxk IGdvIGluIGFuIGFwcGVuZGl4Ljxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBUaGVyZSBpcyBhIGNh bGwgdG8gbWFrZSBmb3IgdGhlIFdHOiBJIGRvIGtub3cgdGhhdCBNSFRzIHdlcmU8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgY29uc2lkZXJlZCBieSBzb21lIGFzIGJ1cmRlbiBhbmQgdGhleSBoYXZl IGNhbGxlZCBmb3IgYTxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIGxlYW5lciB3YXksIGkuZS4s IHRoZSBzdGFydC1lbmQgcmFuZ2VzLsKgIFRoZSBjYWxsIGZvciB0aGU8YnI+wqDCoMKgwqDCoMKg wqDCoMKgwqAgbGVhbmVyIHdheSBoYXMgYmVlbiBpbXBsZW1lbnRlZCBpbiB0aGUgZG9jdW1lbnQg YnV0IG5vdDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBmdWxseS48YnI+PGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgICvCoMKgIFRoZSB0ZXh0IG5vdyBzdGF0ZXMgdGhhdCBNSFRzIFNIT1VMRCBiZSB1 c2VkIHVubGVzcyBpbjxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYmVuaWduIGVu dmlyb25tZW50cyBhbmQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQuwqAgSXQ8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhbHNvIHN0YXRlcyB0aGF0IG9ubHkgc3RhcnQtZW5kIGNo dW5rIHJhbmdlIGlzIG1hbmRhdG9yeS08YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0 by1pbXBsZW1lbnQsIGFuZCBiaW5zIGFyZSBvcHRpb25hbC48YnI+PGJyPsKgwqDCoMKgwqDCoMKg wqDCoMKgIDIpIExFREJBVCBhcyBjb25nZXN0aW9uIGNvbnRyb2wgdnMuIFBQU1BQIFRoZSBQUFNQ IHBlZXI8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBwcm90b2NvbCBpcyBpbnRlbmRlZCBmb3Ig dGhlIFN0YW5kYXJkcyBUcmFjayBhbmQgcmVsaWVzIGluIGE8YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqAgbm9ybWF0aXZlIG1hbm5lciBvbiBMRURCQVQgKFJGQyA2ODE3KS7CoCBMRURCQVQgYXMgc3Vj aCBpcyBhbjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAqKmV4cGVyaW1lbnRhbCoqIGRlbGF5LWJh c2VkIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0uwqAgQTxicj4NCsKgwqDCoMKgwqDCoMKg wqDCoMKgIFN0YW5kYXJkcyBUcmFjayBwcm90b2NvbCBjYW5ub3Qgbm9ybWF0aXZlbHkgcmVseSBv biBhbjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBFeHBlcmltZW50YWwgY29uZ2VzdGlvbiBjb250 cm9sIG1lY2hhbmlzbSAob3IgUkZDIGluPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGdlbmVyYWwp LsKgIFRoZXJlIGFyZSB3YXlzIG91dCBvZiB0aGlzIHNpdHVhdGlvbjogaSkgRG8gbm90PGJyPsKg wqDCoMKgwqDCoMKgwqDCoMKgIHVzZSBsZWRiYXQ6IHRoaXMgd291bGQgY2FsbCBmb3IgYW5vdGhl ciBjb25nZXN0aW9uIGNvbnRyb2w8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBtZWNoYW5pc20g dG8gYmUgZGVzY3JpYmVkIGluIHRoZSBQUFNQUCBkcmFmdC4gaWkpIFdvcmsgb24gYW48YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqAgJiMzOTt1cGdyYWRlJiMzOTsgb2YgdGhlIExFREJBVCBzcGVjaWZp Y2F0aW9uIHRvIFN0YW5kYXJkcyBUcmFjazo8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgUG9zc2li bGUsIGJ1dCBhIHZlcnkgbG9uZyB3YXkuIGlpaSkgQWdyZWUgb24gaGF2aW5nIFBQU1BQPGJyPg0K wqDCoMKgwqDCoMKgwqDCoMKgwqAgYWxzbyBhcyBFeHBlcmltZW50YWwgcHJvdG9jb2wuwqAgSSYj Mzk7bSBjdXJyZW50bHkgbGVhbmluZyB0b3dhcmRzPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIG9w dGlvbiBpaWkpLCBidXQgdGhpcyBpcyBteSBwdXJlIHBlcnNvbmFsIG9waW5pb24gYXMgYW48YnI+ wqDCoMKgwqDCoMKgwqDCoMKgwqAgaW5kaXZpZHVhbCBpbiB0aGUgSUVURi48YnI+PGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgICvCoMKgIEEgbmV3IHBhcmFncmFwaCBoYXMgYmVlbiBhZGRlZCB0byBT ZWN0aW9uIDguMTYgZGVzY3JpYmluZzxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg dGhlIGZlYXNpYmlsaXR5IG9mIExFREJBVCBpbiBQMlAgc3lzdGVtcy48YnI+PGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgIDMpIE5vIGZvcm1hbCBwcm90b2NvbCBtZXNzYWdlIGRlZmluaXRpb24gU2Vj dGlvbiA3IGFuZCBtb3JlPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHNwZWNpZmljIFNlY3Rpb24g OCBkZXNjcmliZSB0aGUgcHJvdG9jb2wgc3ludGF4IG9mIHRoZTxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoCBwcm90b2NvbCBvcHRpb25zIGFuZCB0aGUgbWVzc2FnZXMsIHRob3VnaCBTZWN0aW9uIDgg aXM8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCB0YWxraW5nIGFib3V0IFVEUCBlbmNhcHN1bGF0 aW9uLsKgIFNlY3Rpb24gNyBpcyBoYXJkIHRvIGRpZ2VzdDxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCBpZiBzb21lb25lIHNob3VsZCBpbXBsZW1lbnQgdGhlIG9wdGlvbnMsIHNlZSBhbHNvIGxhdGVy LCBidXQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgU2VjdGlvbiA4IGlzIGFsbW9zdCBpbXBvc3Np YmxlIHRvIHVuZGVyc3RhbmQgYnkgc29tZWJvZHkgd2hvPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKg wqAgaGFzIG5vdCBiZWVuIGludm9sdmVkIGluIHRoZSBQUFNQIHdvcmtpbmcgZ3JvdXAuwqAgU2Vl IGFsc288YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgZnVydGhlciBkb3duIGZvciBhIG1vcmUgZGV0 YWlsZWQgcmV2aWV3IG9mIHRoZSBzZWN0aW9ucy7CoCBUbzxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCBnaXZlIGFuIGV4YW1wbGUgb3V0IG9mIFNlY3Rpb24gOC40OiBUaGlzIHNlY3Rpb24gZGVzY3Jp YmVzPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgdGhlIEhBTkRTSEFLRSBtZXNzYWdlIGFuZCBn aXZlcyBleGFtcGxlcyBob3cgc3VjaCBhIEhBTkRTSEFLRTxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCBtZXNzYWdlIGNvdWxkIGxvb2sgbGlrZS7CoCBCdXQgbm8gZm9ybWFsIGRlZmluaXRpb24gb2Yg dGhlPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIG1lc3NhZ2UgaXMgZ2l2ZW4gbGVhdmluZyBhIG51 bWJlciBvZiB0aGlucyB1bmNsZWFyLCBzdWNoIGFzPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAg d2hhdCB0aGUgbG9jYWwgY2hhbm5lbCBudW1iZXIgYW5kIHdoYXQmIzM5O3MgdGhlIHJlbW90ZSBj aGFubmVsPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIG51bWJlciBpcy7CoCBUaGlzIGlzIGltcGxp Y2l0bHkgZGVmaW5lZCwgYnV0IHRoYXQgaXMgbm90IGE8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAg Z29vZCB3YXkgb2Ygd3JpdGluZyBTdGFuZGFyZHMgVHJhY2sgZHJhZnRzLjxicj48YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgNCkgSW1wbGljaXQgdXNlIG9mIGRlZmF1bHQgdmFsdWVzIFRoZXJlIGFy ZSBhIG51bWJlciBvZjxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIHBsYWNlcyBhbGwgb3ZlciB0 aGUgZHJhZnQgd2hlcmUgZGVmYXVsdCB2YWx1ZXMgYXJlIGRlZmluZWQuPGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgIE1hbnkgb2YgdGhvc2UgZGVmYXVsdCB2YWx1ZXMgYXJlIHVzZWQgd2hlbiB0aGVy ZSBhcmUgbm88YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgdmFsdWVzIGV4cGxpY2l0bHkgc2lnbmFs ZWQsIGUuZy4sIHRoZSBkZWZhdWx0IGNodW5rIHNpemUgb2YgMTxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoCBLYnl0ZSBpbiBTZWN0aW9uIDguNCBvciBTZWN0aW9uIFNlY3Rpb24gNy41LiB3aXRoIHRo ZSBkZWZhdWx0PGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgZm9yIHRoZSBDb250ZW50IEludGVn cml0eSBQcm90ZWN0aW9uIE1ldGhvZC7CoCBJIGhhdmUgdGhlPGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgIGZlZWxpbmcgdGhhdCB0aGUgcHJvdG9jb2wgYW5kIHRoZSBzdXJyb3VuZGluZ3MgKGUuZy4s IHdoYXQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgY29tZXMgaW4gdmlhIHRoZSAmIzM5O3RyYWNr ZXImIzM5OykgYXJlIG92ZXItb3B0aW1pemVkLCBlLmcuLCBhbHdheXM8YnI+DQrCoMKgwqDCoMKg wqDCoMKgwqDCoCBwcm92aWRpbmcgdGhlIENvbnRlbnQgSW50ZWdyaXR5IFByb3RlY3Rpb24gTWV0 aG9kIGFzIHBhcnQgb2Y8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgdGhlIFByb3RvY29sIG9wdGlv bnMgd2lsbCBub3Qgd2FzdGUgbW9yZSB0aGFuIDIgYnl0ZXMgaW4gYTxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoCBIQU5EU0hBS0UgbWVzc2FnZS7CoCBGdXJ0aGVyLCBJIGRvIG5vdCBzZWUgdGhlIG5l ZWQgdG8gZGVmaW5lPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgYSBkZWZhdWx0IGNodW5rIHNp emUgaW4gdGhlIGJhc2UgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwgYXM8YnI+wqDCoMKgwqDCoMKg wqDCoMKgwqAgdGhpcyBkZWZhdWx0IGNhbiBsb29rIHZlcnkgZGlmZmVyZW50LCBkZXBlbmRpbmcg b24gd2hvIGlzPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGRlcGxveWluZyB0aGUgcHJvdG9jb2wg YW5kIGluIHdoYXQgY29udGV4dC7CoCBUaGlzIGNhbGxzIGZvciBhPGJyPg0KwqDCoMKgwqDCoMKg wqDCoMKgwqAgbW9yZSBkeW5hbWljIHdheSBvZiBoYW5kbGluZyB0aGUgc3lzdGVtIGNodW5rIHNp emUsIGVpdGhlciBhczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBwYXJ0IG9mIGFuIGV4dGVybmFs IG1lY2hhbmlzbXMgKGUuZy4gdmlhIHRoZSB0cmFja2VyKSBvciBpbjxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoCB0aGUgSEFORFNIQUtFIG1lc3NhZ2UuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCArwqDCoCBSZW1vdmVkIGltcGxpY2l0IGRlZmF1bHRzIGZyb20gcHJvdG9jb2wgb3B0aW9ucy7C oCBDaHVuazxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2l6ZSBpcyBwYXJ0IG9m IHRoZSBjb250ZW50JiMzOTtzIG1ldGFkYXRhIGFuZCB0aHVzPGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgY29uZmlndXJhYmxlLsKgIFRoZSBkZWZhdWx0IDFLaUIgaGFzIGJlZW4gdHVy bmVkIGludG8gYTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlY29tbWVuZGF0aW9u Ljxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgNSkgQ29uY2VwdCBvZiBjaGFubmVscyBUaGUg Y29uY2VwdCBvZiBjaGFubmVscyBpcyBnb29kIGJ1dCBpdDxicj4NCsKgwqDCoMKgwqDCoMKgwqDC oMKgIGlzIGludHJvZHVjZWQgdG9vIGxhdGUgaW4gdGhlIGRyYWZ0LCBuYW1lbHkgaW4gU2VjdGlv biA4LjMsPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGFuZCBpdCBpcyBpbnRyb2R1Y2VkIHdpdGgg dmVyeSBmZXcgd29yZHMuwqAgV2h5IGlzbiYjMzk7dCB0aGlzPGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgIGludHJvZHVjZWQgYXMgcGFydCBvZiBTZWN0aW9uIDIgb3IgU2VjdGlvbiAzLCBhbHNvIGlu IHRoZTxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlbGF0aW9uc2hpcCB0byB0aGUgdXNlZCB0 cmFuc3BvcnQgcHJvdG9jb2w/wqAgSS5lLiwgdGhlPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGlu dGVudGlvbiBpcyB0byBrZWVwIG9ubHkgb25lIHRyYW5zcG9ydCAmIzM5O2Nvbm5lY3Rpb24mIzM5 OyBiZXR3ZWVuPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHR3byBkaXN0aW5jdCBwZWVycyBhbmQg dG8gYWxsb3cgdG8gcnVuIG11bHRpcGxlIHN3YXJtPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAg aW5zdGFuY2VzIGF0IHRoZSBzYW1lIHRpbWUgb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQuwqAgQW5k IGhvdzxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBkbyBzd2FybXMgYW5kIGNoYW5uZWxzIGNvcnJl bGF0ZT88YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIENvbmNlcHQgbm93IGludHJv ZHVjZWQgaW4gU2VjdGlvbiAzIHdpdGggYSBmaWd1cmUuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoCAqKipUZWNobmljYWxzOjxicj4NCjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rp b24gMi4xLCAybmQgcGFyYWdyYXBoLCBhYm91dCB0aGUgdHJhY2tlcjogSSBoYXZlbiYjMzk7dDxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBzZWVuIGEgc2luZ2xlIHBsYWNlIHdoZXJlIHRoZSBpbnRl cmFjdGlvbiB3aXRoIGEgdHJhY2tlciBpczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBkaXNjdXNz ZWQgb3Igd2hlcmUgdGhlIHRyYWNrZXIgbGVzcyBvcGVyYXRpb24gaXMgZGlzY3Vzc2VkIGluPGJy Pg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29udHJhc3QuwqAgSXQgaXMgZnVydGhlciB1bmNsZWFy IHdoYXQgdHlwZSBvZiBpbmZvcm1hdGlvbiBpczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCByZWFs bHkgcmVxdWlyZWQgZnJvbSBhIHRyYWNrZXIuwqAgQSB0cmFja2VyIChvciBhIHJlc291cmNlPGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgIGRpcmVjdG9yeSkgd291bGQgbmVlZCB0byBwcm92aWRlIG1v cmUgdGhlbiBJUCBhZGRyZXNzICZhbXA7IHBvcnQsPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAg ZS5nLiwgdGhlIHVzZWQgdHJhbnNwb3J0IHByb3RvY29sIGZvciB0aGUgcHJvdG9jb2wgZXhjaGFu Z2U8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgKGdpdmVuIHRoYXQgb3RoZXIgdHJhbnNwb3J0cyBh cmUgYWxsb3dlZCksIHVzZWQgY2h1bmsgc2l6ZSw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgY2h1 bmsgYWRkcmVzc2luZyBzY2hlbWUsIGV0Yzxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBT ZWN0aW9uIDIuMywgdGhlIDFzdCBwYXJhZ3JhcGgsICYjMzk7Y2xvc2UtY2hhbm5lbCYjMzk7OiBU aGlzIGhhczxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIGJlZW4gdGhlIGZpcnN0IHRpbWUgd2hl cmUgSSBzdHVtYmxlZCBvdmVyIHRoZSBjaGFubmVsIHdpdGhvdXQ8YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqAga25vd2luZyB0aGUgY29uY2VwdC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvC oMKgIFJlcGhyYXNlZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjE6 IG9yZGVyaW5nIG9mIG1lc3NhZ2VzIFRoZSAxc3Qgc2VudGVuY2UgaW1wbGllczxicj4NCsKgwqDC oMKgwqDCoMKgwqDCoMKgIHRoYXQgb3JkZXJpbmcgb2YgbWVzc2FnZXMgaW4gYSBkYXRhZ3JhbSBt YXR0ZXJzIGEgbG90LsKgIFRoaXM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgaXMgb3V0bGluZWQg bGF0ZXIgaW4gdGhlIGRvY3VtZW50LCBidXQgSSB3b3VsZCBhZGQgdGhpcyBhczxicj7CoMKgwqDC oMKgwqDCoMKgwqDCoCBwYXJ0IG9mIDMuLCBpLmUuLCB0aGUgbWVzc2FnZXMgYXJlIHByb2Nlc3Nl ZCBpbiB0aGUgc3RyaWN0PGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgb3JkZXIgb3Igc29tZXRo aW5nIGFsb25nIHRoaXMgbGluZS48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlv biAzLjEsIDFzdCBwYXJhZ3JhcGgsIG9wdGlvbnMgdG8gaW5jbHVkZSBJIHdvdWxkIG5vdDxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCBzYXkgYW55dGhpbmcgYWJvdXQgJiMzOTtTSE9VTEQgaW5jbHVk ZSBvcHRpb25zJiMzOTsgaGVyZSwgYXMgdGhpcyBpczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBh bnlob3cgZGVzY3JpYmVkIGluIFNlY3Rpb24gOC48YnI+DQo8YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqAgK8KgwqAgUGhyYXNlIHJlbW92ZWQuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNl Y3Rpb24gMy4xLCAybmQgcGFyYWdyYXBoOiAmcXVvdDtEYXRhZ3JhbXMgZXhjaGFuZ2VkIE1BWSBh bHNvPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbnRhaW4gc29tZSBtaW5vciBwYXlsb2FkLCBl LmcuwqAgSEFWRSBtZXNzYWdlcyB0byBpbmRpY2F0ZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCB0 aGUgY3VycmVudCBwcm9ncmVzcyBvZiBhIHBlZXIgb3IgYSBSRVFVRVNUIChzZWUgU2VjdGlvbjxi cj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIDMuNykuJnF1b3Q7IHRvIGJlIGFkZGVkLCBqdXN0IHRv IG1ha2UgaXQgY2xlYXIgSU1ITzogJnF1b3Q7LCBidXQgTVVTVDxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoCBOT1QgaW5jbHVkZSBhbnkgREFUQSBtZXNzYWdlJnF1b3Q7Ljxicj48YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgK8KgwqAgQWRkZWQuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNl Y3Rpb24gMy4yLCAybmQgcGFyYWdyYXBoOiAmcXVvdDtJbiBwYXJ0aWN1bGFyLCB3aGVuZXZlciBh PGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVjZWl2aW5nIHBlZXIgaGFzIHN1Y2Nlc3NmdWxs eSBjaGVja2VkIHRoZSBpbnRlZ3JpdHkgb2YgYTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBjaHVu ayBvciBpbnRlcnZhbCBvZiBjaHVua3MgaXQgTVVTVCBzZW5kIGEgSEFWRSBtZXNzYWdlIHRvPGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgIGFsbCBwZWVycyBpdCB3YW50cyB0byBpbnRlcmFjdCB3aXRo IGluIHRoZSBuZWFyIGZ1dHVyZS4mcXVvdDs8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBUaGlz IGxvb2tzIGxpa2UgYSBwbGFjZSB3aGVyZSBhIGxvdCBvZiB0cmFmZmljIGNhbiBiZSBzZW5kPGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgIG91dCBvZiBhIHBlZXIsIGkuZS4sIHdoZW5ldmVyIGEgY2h1 bmsgYXJyaXZlcyBhIEhBVkUgbWVzc2FnZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBtdXN0IGJl IHNlbnQuwqAgSSBkb24mIzM5O3QgYmVsaWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlIG1hbmRhdGVk PGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgYnkgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24s IGJ1dCB0aGVyZSBzaG91bGQgZ3VpZGFuY2Ugb248YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgd2hl biB0byBzZW5kIHRoaXMsIGUuZy4sIHBlZXJzIG1pZ2h0IGJlIGFsc28gYWJsZSB0byB3YWl0IGZv cjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBhIHNob3J0IHBlcmlvZCBvZiB0aW1lIHRvIGdhdGhl ciBtb3JlIGNodW5rcyB0byBiZSByZXBvcnRlZDxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIGlu IEhBVkUuwqAgT3Igc2hvdWxkIGluIHRoaXMgY2FzZSBhIHNpbmdsZSBVRFAgZGF0YWdyYW08YnI+ wqDCoMKgwqDCoMKgwqDCoMKgwqAgY29udGFpbiBtdWx0aXBsZSBIQVZFcz88YnI+PGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgICvCoMKgIENsYXJpZmllZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgIC0gU2VjdGlvbiAzLjQgb24gQUNLcyBUaGlzIHNlY3Rpb24gbG9va3MgcHJldHR5IHdlYWss IGFzIEFDS3M8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgbWF5IGJlIHNlbnQgYnV0IG9uIHRoZSBv dGhlciBoYW5kIE1VU1QgYmUgc2VudCBpZiBsZWRiYXQgaXM8YnI+DQrCoMKgwqDCoMKgwqDCoMKg wqDCoCB1c2VkLsKgIEkgd291bGQgc2ltcGx5IHNheTogLSBBQ0sgTVVTVCBiZSBzZW50IGlmIGFu PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHVucmVsaWFibGUgdHJhbnNwb3J0IHByb3RvY29sIGlz IHVzZWQgLSBBQ0sgTUFZIGJlIHNlbnQgaWYgYTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCByZWxp YWJsZSB0cmFuc3BvcnQgcHJvdG9jb2wgaXMgdXNlZCAtIGtlZXAgY2xhcmlmaWNhdGlvbjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCBhYm91dCBsZWRiYXQuPGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKg wqDCoMKgICvCoMKgIERPTkUuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rpb24g My41OiBHaXZlIHRleHQgd2hlcmUgSU5URUdFUklUWSBpcyBkZXNjcmliZWQgYXQ8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgbGVhc3QgZm9yIHRoZSBNVEkgc2NoZW1lLjxicj48YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgK8KgwqAgRE9ORS48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2Vj dGlvbiAzLjcsIDJuZCBwYXJhZ3JhcGggLSBhbGwgJiMzOTtNQVkmIzM5OyBhcmUgYWN0dWFsbHkg bm90PGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmlnaHQgaGVyZS7CoCBQbGVhc2UgcmVtb3Zl IG9yIHJlcGxhY2UgdGhlbSB3aXRoIGxvd2VyIGxldHRlcnM8YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqAgaWYgYXBwcm9wcmlhdGUuIC0gSXQgaXMgbm90IGNsZWFyIHdoYXQgdGhlICYjMzk7c2VxdWVu dGlhbGx5JiMzOTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgbWVhbnMgZXhhY3RseS7CoCBJcyBp dCBpbiB0aGUgcmVjZWl2ZWQgb3JkZXI/PGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCArwqDC oCBGaXJzdCBwb2ludCBUT0RPLsKgICZxdW90O1NlcXVlbnRpYWxseSZxdW90OyByZXBsYWNlZCB3 aXRoICZxdW90O3JlY2VpdmVkPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBvcmRl ciZxdW90Oy48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjg6IFBsZWFz ZSByZXBsYWNlICYjMzk7TUFZJiMzOTsgYnkgY2FuLCBhcyB0aG9zZSBhcmUgbm90PGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgIG5vcm1hdGl2ZSBiZWhhdmlvcnMgYnV0IG1vcmUgdGhlIGZhY3QgdGhh dCBwZWVycyBjYW4sIGZvcjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBpbnN0YW5jZSwgcmVxdWVz dCB1cmdlbnQgZGF0YS48YnI+DQo8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgK8KgwqAgRE9ORS48 YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjkgU2FtZSBjb21tZW50IGFz IGZvciB0aGUgU2VjdGlvbiAzLjgganVzdCBhYm92ZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCB0 aGlzIGNvbW1lbnQuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBET05FLjxicj48 YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDMuOSB3YWl0aW5nIGZvciByZXNwb25z ZXMgT0xEICZxdW90OyBXaGVuIHBlZXIgQjxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlY2Vp dmVzIGEgQ0hPS0UgbWVzc2FnZSBmcm9tIEEgaXQgTVVTVCBOT1Qgc2VuZCBuZXcgUkVRVUVTVDxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBtZXNzYWdlcyBhbmQgU0hPVUxEIE5PVCBleHBlY3QgYW5z d2VycyB0byBhbnkgb3V0c3RhbmRpbmc8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgb25lcy4mcXVv dDvCoCBORVcgJnF1b3Q7IFdoZW4gcGVlciBCIHJlY2VpdmVzIGEgQ0hPS0UgbWVzc2FnZSBmcm9t IEEgaXQ8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBNVVNUIE5PVCBzZW5kIG5ldyBSRVFVRVNU IG1lc3NhZ2VzIGFuZCBpdCBjYW5ub3QgZXhwZWN0PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGFu c3dlcnMgdG8gYW55IG91dHN0YW5kaW5nIG9uZXMsIGFzIHRoZSB0cmFuc2ZlciBvZiBjaHVua3Mg aXM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgY2hva2VkLiZxdW90Ozxicj48YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgK8KgwqAgRE9ORS48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2Vj dGlvbiAzLjEwLjIgVGhpcyB3aG9sZSBzZWN0aW9uIGFib3V0IFBFWCBob2xlIHB1bmNoaW5nPGJy Pg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVhZHMgdmVyeSwgdmVyeSBleHBlcmltZW50YWwuwqAg VGhlIFNUVU4gbWV0aG9kIGlzIG9rLCBidXQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgUEVYIGlz biYjMzk7dC7CoCBGaXJzdCBvZiBhbGwsIHRoZSBzYWZlIGJlaGF2aW9yIGZvciBhIHBlZXIgd2hl bjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBpdCByZWNlaXZlcyB1bnNvbGljaXRlZCBQRVggbWVz c2FnZXMsIGlzIHRvIGRpc2NhcmQgdGhvc2U8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBtZXNz YWdlcy7CoCBTZWNvbmQsIHRoaXMgdW5zb2xpY2l0ZWQgUEVYIG1lc3NhZ2VzIHRyaWdnZXIgc29t ZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBiZWhhdmlvciB3aGljaCBtYXkgb3BlbiBhbiBhdHRh Y2sgdmVjdG9yLsKgIFRoZSBiZXN0IHdheSwgYnV0PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHRo aXMgbmVlZHMgbW9yZSBkaXNjdXNzaW9uLCBpcyB0byBpbmNsdWRlIHRvIHNvbWUgdG9rZW4gaW48 YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGUgbWVzc2FnZXMgdGhhdCBhcmUgZXhjaGFuZ2Vk IGluIG9yZGVyIHRvIG1ha2UgYXZvaWQgYW55PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGJsaW5k IGF0dGFja3MgaGVyZS7CoCBIb3dldmVyLCB0aGlzIHdpbGwgbmVlZCBtb3JlIGFuZDxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoCBkZXRhaWxlZCBkaXNjdXNzaW9ucyBvZiB0aGUgcHVycG9zZSBvZiB0 aGlzLjxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgK8KgwqAgVE9ETzogaG9sZSBwdW5jaGlu ZyBjb21tZW50Ljxicj4NCjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBXZSBtb3ZlZCBw YXJ0cyBvZiB0aGUgc2VjdXJpdHkgYW5hbHlzaXMgb2YgUEVYIHVwLCBzdWNoPGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgdGhhdCBhbGwgbWVjaGFuaXNtcyBhcmUgZXhwbGFpbmVkIGlu IHRoZSBtYWluIHRleHQsIGFuZDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoZSBh bmFseXNpcyBvZiB3aGF0IGF0dGFja3MgdGhlcmUgYXJlIGFuZCBob3cgdGhlc2U8YnI+DQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG1lY2hhbmlzbXMgcHJldmVudCB0aGVtIGlzIGluIHRo ZSBTZWMuIENvbnNpZGVyYXRpb25zPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2Vj dGlvbi48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjExIEkgZG9uJiMz OTt0IHNlZSB0aGUgJiMzOTtNVVNUIHNlbmQga2VlcC1hbGl2ZSYjMzk7IGFzIGE8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgbWFuZGF0b3J5IHJlcXVpcmVtZW50LCBhcyBwZWVycyBtaWdodCBoYXZl IGdvb2QgcmVhc29ucyBub3Q8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCB0byBzZW5kIGFueSBr ZWVwIGFsaXZlLsKgIFdoeSBub3Qgc2F5aW5nICYjMzk7QSBwZWVyIGNhbiBzZW5kIGE8YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqAga2VlcC1hbGl2ZSYjMzk7IGFuZCBpdCAmIzM5O01VU1QgdXNlIHRo ZSBzaW1wbGUgZGF0YWdyYW0uLi4mIzM5OyBhczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBhbHJl YWR5IGRlc2NyaWJlZC7CoCBUaG91Z2ggdGhlcmUgaXMgYWxzbyBubyByZWFsbHkgbmVlZCB0bzxi cj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIHNheSBNVVNULjxicj48YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqAgK8KgwqAgTm93IFNlY3Rpb24gMy4xMi7CoCBSZXBocmFzZWQgYW5kIGNsYXJpZmllZCB0 aGUgcmVhc29uIGFuZDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbnNlcXVlbmNl cyBvZiBzZW5kaW5nIGtlZXAtYWxpdmUgbXNncy48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKg IC0gU2VjdGlvbiA0IFRoZSBzeW50YXggZGVmaW5pdGlvbiBmb3IgZWFjaCBvZiB0aGUgY2h1bms8 YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBhZGRyZXNzaW5nIHNjaGVtZXMgaXMgbWlzc2luZy7C oCBUaGlzIGlzIG5vdCBzdWl0YWJsZSBmb3IgYW55PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHNw ZWNpZmljYXRpb24gdGhhdCBhaW1zIGF0IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLjxi cj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDQuMy4yIFBQU1BQIHBlZXJzIE1V U1QgdXNlIHRoZSBBQ0sgbWVzc2FnZSBpZiBhbjxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIHVu cmVsaWFibGUgdHJhbnNwb3J0IHByb3RvY29sIGlzIHVzZWQuPGJyPjxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoCArwqDCoCBET05FLjxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9u IDQuNCBIYXMgYmVlbiB0ZXN0ZWQgaW4gYW4gaW1wbGVtZW50YXRpb24/wqAgSSB3b3VsZDxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIG5lZWQgZm9yIHN1Y2gg YSBzZWN0aW9uLCBhcyBpbiBteTxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuZGVyc3RhbmRp bmcgYSBwZWVyIGltcGxlbWVudGF0aW9uIHNob3VsZCBjaG9zZSBvbmUgc2NoZW1lPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgIGFuZCBzdXBwb3J0IHRoaXMgYW5kIHRoZXJlIHNob3VsZG4mIzM5O3Qg YmUgdGhlIG5lZWQgdG8gY29udmVydDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBiZXR3ZWVuIHRo ZSBkaWZmZXJlbnQgc2NoZW1lcy48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlv biA1IFRoaXMgcmVhZHMgdGhhdCBNSFRzIGFyZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50PGJyPg0K wqDCoMKgwqDCoMKgwqDCoMKgwqAgd2hpbGUgdGhlIGRvY3VtZW50IG1ha2VzIHRoZSBpbXByZXNz aW9uIHRoYXQgTUhUcyBhcmU8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgb3B0aW9uYWwuPGJyPjxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBSZXBocmFzZWQsIHNlZSBIaWdoLWxldmVsIGlz c3Vlcy48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA1LjMgJnF1b3Q7IHNv IGVhY2ggZGF0YWdyYW0gU0hPVUxEIGJlIHByb2Nlc3NlZDxicj4NCsKgwqDCoMKgwqDCoMKgwqDC oMKgIHNlcGFyYXRlbHkgYW5kIGEgbG9zcyBvZiBvbmUgZGF0YWdyYW0gTVVTVCBOT1QgZGlzcnVw dCB0aGU8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgZmxvdyZxdW90OyBUaGUgTVVTVCBOT1QgaXMg bm90IGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCByZXF1 aXJlbWVudCwgYnV0IG1vcmUgYW4gaW5mb3JtYXRpdmUgcGFydCBzYXlpbmcgdGhhdCBhIGxvc3Q8 YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgbWVzc2FnZSBzaG91bGRuJiMzOTt0IGltcGFjdCB0aGUg cHJvdG9jb2wgbWFjaGluZXJ5LCBidXQgaXQgY2FuPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAg aW1wYWN0IHRoZSBvdmVyYWxsIG9wZXJhdGlvbi7CoCBXaGF0IGlzIHRoZSBmbG93IGhlcmUgaW4g dGhhdDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBzZW50ZW5jZT88YnI+PGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgICvCoMKgIFJlcGhyYXNlZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0g U2VjdGlvbiA1LjYuMi7CoCBBbiBpbGx1c3RyYXRpdmUgZXhhbXBsZSBleHBsYWluaW5nIGhvdyB0 aGU8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgYXV0b21hdGljIHNpemUgZGV0ZWN0aW9uIHdvcmtz IGlzIHJlcXVpcmVkIGhlcmUuPGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIEFk ZGVkIGEgcGFyYWdyYXBoIHdpdGggYW4gZXhhbXBsZSB0aGF0IGZvbGxvd3MgdGhlIGZpZ3VyZTxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVzZWQgZHVyaW5nIHRoZSBleHBsYW5hdGlv bi7CoCBBIHN0YXRlIGRpYWdyYW0gY291bGQgYWxzbzxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIGJlIGFkZGVkLCBidXQgYmlnaHQgYmUgYSBiaXQgcmVkdW5kYW50Ljxicj48YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDYuMSwgNHRoIHBhcmFncmFwaDogV2hlcmUgZG8g SSBmaW5kIHRoZSAxIGJ5dGU8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBhbGdvcml0aG0gZmll bGQgaW4gdGhlIHN3YXJtIElEP8KgIFRoZSBzd2FybSBJRCBpcyBub3QgcmVhbGx5PGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgIGRlZmluZWQgaW4gYSBzaW5nbGUgcGxhY2UuPGJyPjxicj7CoMKgwqDC oMKgwqDCoMKgwqDCoCArwqDCoCBFeHBhbmRlZC7CoCBUT0RPOiBGb3JtYWwgc3BlYyBvZiBzd2Fy bSBJRC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA3LjMgVGhlIGRlc2Ny aWJlZCBtaW4vbWF4IHZlcnNpb25pbmcgcmVsaWVzIG9uIHRoZTxicj4NCsKgwqDCoMKgwqDCoMKg wqDCoMKgIGZhY3QgdGhhdCB0aGVyZSBhcmUgbWFqb3IgYW5kIG1pbm9yIHZlcnNpb24gbnVtYmVy cy7CoCBJPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGNhbm5vdCBmaW5kIGFueSBtYWpvciBhbmQg bWlub3IgdmVyc2lvbiBudW1iZXIgc2NoZW1lIGluIHRoZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCBkcmFmdC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIEFjdHVhbGx5LCBpdCBk b2VzIG5vdC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA3LjQsIExlbmd0 aCBmaWVsZCBJdCBpcyBub3QgY2xlYXIgd2hhdCB0aGUgJiMzOTtMZW5ndGgmIzM5Ozxicj4NCsKg wqDCoMKgwqDCoMKgwqDCoMKgIGZpZWxkIGlzIHJlZmVycmluZyB0by7CoCBGdXJ0aGVyLCBpdCBp cyBub3QgY2xlYXIgb2YgdGhlIHN3YW08YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgSURzIGFyZSBj b25jYXRlbmF0ZWQgaW4gb25lIHN3YXJtIElEIG9wdGlvbiwgb2YgZWFjaCBzd2FybSBJRDxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCBtdXN0IGJlIHBsYWNlZCBpbiBhIHNlcGFyYXRlIHN3YW0gSUQg b3B0aW9uLjxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDcuNiBNSFRzIGFy ZSBtYW5kYXRvcnkgdG8gc3VwcG9ydCB0aG91Z2ggTUhUcyBhcmU8YnI+DQrCoMKgwqDCoMKgwqDC oMKgwqDCoCBvcHRpb25hbD88YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIENsYXJp ZmllZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA3LjcgJiMzOTtrZXkg c2l6ZSAuLi4gZGVyaXZlZCBmcm9tIHRoZSBzd2FybSBJRCYjMzk7LsKgIFRoaXM8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgcmVsYXRlcyB0byBteSBoaWdoIGxldmVsIGNvbW1lbnQgbm8gNC4gb24g dGhlIHVzZSBvZiBpbXBsaWNpdDxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIGluZm9ybWF0aW9u LsKgIEVpdGhlciBpdCBpcyBjbGVhcmx5IHNwZWNpZmllZCBob3cgdGhpczxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoCBpbmZvcm1hdGlvbiBpcyBkZXJpdmVkIG9yIHRoZXJlIGlzIGEgcHJvdG9jb2wg ZmllbGQvPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzaXpl Ljxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgK8KgwqAgS2V5IHNpemUgZGVyaXZhdGlvbiBw cm9jZWR1cmUgYWRkZWQgdG8gZGVzY3JpcHRpb24gb2Y8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFNJR05FRF9JTlRFR1JJVFkgaW4gVURQIGVuY2Fwc3VsYXRpb24uPGJyPjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rpb24gNy44IEkgd291bGQgcmVjb21tZW5kIHRvIHNh eSB0aGF0IHRoZSBkZWZhdWx0IE1VU1Q8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgYmUgc3VwcG9y dGVkLCBidXQgdGhlIHBlZXIgbXVzdCBhbHdheXMgc2lnbmFsIHdoYXQgbWV0aG9kIGl0PGJyPsKg wqDCoMKgwqDCoMKgwqDCoMKgIGlzIHN1cHBvcnRpbmcgb3IgYXQgbGVhc3QgdXNpbmcuPGJyPg0K PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIENvcnJlY3RlZCwgc2VlIEhpZ2gtbGV2ZWwg aXNzdWVzIDQuKTxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDcuMTAgSSBo YXZlIG5vdCB1bmRlcnN0b29kIGhvdyB0aGUgJiMzOTtMZW5naHQmIzM5OyBmaWVsZDxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoCByZWxhdGVzIHRvIHRoZSBtZXNzYWdlIGJpdG1hcCBhbmQgaG93IGxv bmcgdGhlIG1lc3NhZ2UgYml0bWFwPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgY2FuIGdyb3cu wqAgVGhlIGZpZ3VyZSBsb29rcyBsaWtlIGEgbWF4aW11bSBvZiAxNiBiaXRzPzxicj48YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqAgK8KgwqAgQ2xhcmlmaWVkLjxicj48YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqAgLSBTZWN0aW9uIDggSSBkbyBub3Qgc2VlIHRoZSB2YWx1ZSBvZiB0aGUgdGV4dCBpbiB0 aGUgcHJlZmFjZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBvZiBTZWN0aW9uIDguwqAgSSB3b3Vs ZCBzYXkgdGhhdCB0aGlzIHRleHQgc2hvdWxkIHNheSB3aGF0IGlzPGJyPg0KwqDCoMKgwqDCoMKg wqDCoMKgwqAgbWFuZGF0b3J5IGFuZCB3aGF0JiMzOTtzIG5vdCwgaS5lLiwgTVVTVCB1c2UgVURQ IGFuZCBNVVNUIHVzZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBMRURCQVQuwqAgUG90ZW50aWFs bHkgc2F5aW5nIHRoYXQgZnV0dXJlIHByb3RvY29sIHZlcnNpb25zIGNhbjxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoCBhbHNvIHJ1biBvdmVyIG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMuPGJyPjxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBBZGp1c3RlZC48YnI+DQo8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgLSBTZWN0aW9uIDguMSBhYm91dCBNYXhpbXVtIFRyYW5zZmVyIFVuaXQgKE1U VSkgVGhlIHRleHQgaXM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgZGlzY3Vzc2luZyB0aGF0IGEg RXRoZXJuZXQgY2FuIGNhcnJ5IDE1MDAgYnl0ZXMuwqAgVGhpcyBpczxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoCB0cnVlLCBidXQgdGhlIEV0aGVybmV0IHBheWxvYWQgaXMgbm90IHRoZSBub3JtYXRp dmUgTVRVPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGFjcm9zcyBhbGwgb2YgdGhlIEludGVybmV0 LsKgIEZvciBJUHY2IHRoZSBtaW4gTVRVIGlzIDEyODA8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDC oCBieXRlcyBhbmQgZm9yIElQdjQgaXQgaXMgNTc2IGJ5dGVzLCB0aG91Z2ggZm9yIElQdjQgaXQg Y2FuIGJlPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoZW9yZXRpY2FsbHkgbXVjaCBsb3dlciBh dCA2NCBieXRlcy7CoCBJdCB3b3VsZCBtb3ZlIHRoZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBk ZWZpbml0aW9uIG9mIHRoZSBkZWZhdWx0IGNodW5rIHNpemUgdG8gYSByZWNvbW1lbmRhdGlvbiB3 aXRoPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgdGV4dCBzYXlpbmcgdGhhdCB0aGlzIHNpemUg aGFzIGEgaGlnaCBsaWtlbGlob29kIHRvIHRyYXZlbDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBl bmQtdG8tZW5kIGluIHRoZSBJbnRlcm5ldCB3aXRob3V0IGFueSBmcmFnbWVudGF0aW9uLjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCBGcmFnbWVudGF0aW9uIG1pZ2h0IGluY3JlYXNlIHRoZSBsb3Nz IG9mIGNvbXBsZXRlIGNodW5rcywgYXM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgb25lIGxvc3Qg ZnJhZ21lbnQgd2lsbCBjYXVzZSB0aGUgbG9zcyBvZiBhIGNvbXBsZXRlIGNodW5rLjxicj4NCsKg wqDCoMKgwqDCoMKgwqDCoMKgIE9uZSB3YXkgb2YgZ2V0dGluZyBhbiBpbmZvcm1lZCBkZWNpc2lv biBvbiB3aGV0aGVyIGNodW5rcyBjYW48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgdHJhdmVsIGlu IHRoZWlyIHNpemUgaXMgdG8gdXNlIHRoZSBEb24mIzM5O3QgRnJhZ21lbnQgKERGKSBiaXQgaW48 YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgSVB2NCBhbmQgYWxzbyB0byB3YXRjaCBmb3IgSUNNUCBl cnJvciBtZXNzYWdlcy7CoCBIb3dldmVyLDxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIElDTVAg ZXJyb3IgbWVzc2FnZXMgYXJlIG5vdCBhIHJlbGlhYmxlIGluZGljYXRpb24sIGJ1dCB0aGV5PGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgIGNhbiBiZSBzb21lIGluZGljYXRpb24uPGJyPjxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoCArwqDCoCAxIEtpQiBjaHVuayBzaXplIGhhcyBiZWVuIG1hZGUgYSBy ZWNvbW1lbmRhdGlvbi48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA4LjEg RGVmaW5pdGlvbiBvZiB0aGUgZGVmYXVsdCBjaHVuayBzaXplIFRoZXJlIGlzPGJyPg0KwqDCoMKg wqDCoMKgwqDCoMKgwqAgbm8gbmVlZCB0byBkZWZpbmUgYSBkZWZhdWx0IGNodW5rIHNpemUsIGlm IHRoZSBjaHVuayBzaXplPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHdvdWxkIGJlIGFsd2F5cyBz aWduYWxlZCBwZXIgc3dhcm0uwqAgVGhpcyBpcyBhbm90aGVyIGRlZmF1bHQvPGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgIGltcGxpY2l0IHZhbHVlIHBsYWNlcyB0aGF0IGlzIHVubmVjZXNzYXJ5Ljxi cj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgK8KgwqAgVGhlIGNodW5rIHNpemUgaXMgYWx3YXlz IHBhcnQgb2YgdGhlIGNvbnRlbnQmIzM5O3MgbWV0YWRhdGEuPGJyPg0KPGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgIC0gU2VjdGlvbiA4LjM6IHNlZSBhbHNvIG15IGNvbW1lbnQgbm8gMy7CoCBUaGUg Y29uY2VwdCBvZjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBjaGFubmVscyBpcyBpbnRyb2R1Y2Vk IHZlcnkgbGF0ZSBhbmQgd2l0aCBmZXcgd29yZHMuwqAgQTxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCBmaWd1cmUgdG8gZXhwbGFpbiB0aGUgY29uY2VwdCB3aWxsIGhlbHAgYSBsb3QgYW5kIGFsc28g bW9yZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBmb3JtYWwgdGV4dCBvbiB3aGF0IGEgY2hhbm5l bCBpcyBhbmQgaG93IHRoZXkgYXJlIGlkZW50aWZpZWQuPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKg wqAgQWxzbyB3aGF0IHRoZSBpbml0IGNoYW5uZWwgaXMuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoCArwqDCoCBDb25jZXB0IG5vdyBpbnRyb2R1Y2VkIGluIFNlY3Rpb24gMy4xMS7CoCBUT0RP IGluaXQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjaGFubmVsLjxicj48YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDggaW4gZ2VuZXJhbDogVGhlcmUgaXMgbm8gZm9y bWFsIGRlZmluaXRpb24gb2YgdGhlPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgbWVzc2FnZXMs IGp1c3QgYml0IHBhdHRlcm4gZXhhbXBsZXMuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAt IFNlY3Rpb24gOC40IChhcyBleGFtcGxlIGZvciB0aGUgb3RoZXIgU2VjdGlvbnMgaW4gOC54KTog aSk8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgV2hhdCBpcyB0aGUgJiMzOTsoQ0hBTk5FTCYjMzk7 IHBhcmFtdGVyP8KgIElzIGl0IGFjdHVhbGx5IGEgcGFyYW1ldGVyPzxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoCBpaSkgaXQgaXMgaW1wbGljaXQgdGhhdCB0aGUgZmlyc3QgY2hhbm5lbCBubyAoMDAw MDAwMCkgaXMgdGhlPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVtb3RlIHBlZXImIzM5O3Mg Y2hhbm5lbCBhbmQgdGhhdCB0aGUgc2Vjb25kIGNoYW5uZWwgbm88YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqAgKDAwMDAwMDExKSBpcyB0aGUgbG9jYWwgcGVlciYjMzk7cyBjaGFubmVsLCByaWdodD/C oCBUaGlzIGlzbiYjMzk7dDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBjbGVhciBmcm9tIHRoZSB0 ZXh0LCBidXQgbXkgZ3Vlc3MuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rpb24g OC41IENhbiBIQVZFIG1lc3NhZ2VzIG11bHRpcGxlIGJpbiBzcGVjcyBpbiBvbmU8YnI+DQrCoMKg wqDCoMKgwqDCoMKgwqDCoCBtZXNzYWdlIG9yIGRvIEkgaGF2ZSB0byBtYWtlIGEgSEFWRSBtZXNz YWdlIGZvciBlYWNoIGJpbj88YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIENsYXJp ZmllZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA4LjYgV2hhdCBpcyB0 aGUgZm9ybWFsIGRlZmludGlvbiBvZiBhIERBVEEgbWVzc2FnZT88YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqAgVGhhdCYjMzk7cyBjb21wbGV0ZWx5IG1pc3Npbmcgb3IgSSBoYXZlIG5vdCB1bmRlcnN0 b29kIGl0Ljxicj4NCjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rpb24gOC43IGxvb2tz IGp1c3QgdW5kZXJzcGVjaWZpZWQsIGVzcGVjaWFsbHkgYXMgdGhpczxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoCBpcyB0aGUgbGluayB0byBMRURCQVQuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCAtIFNlY3Rpb24gOC4xMSBIb3cgYXJlIHRoZSBjaHVua3Mgc3BlY2lmaWVkIGhlcmU/wqAgVGhl IGZvcm1hbDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBzeW50YXggZGVmaW5pdGlvbiBvciByZWZl cmVuY2UgdG8gb25lIGlzIG1pc3NpbmcuPGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0g U2VjdGlvbiA4LjEzIEkmIzM5O20gbG9zdCBvbiB0aGlzIHNlY3Rpb24sIGFzIEkgaGF2ZW4mIzM5 O3QgZnVsbHk8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgdW5kZXJzdG9vZCB0aGUgY29uY2VwdCBv ZiB0aGUgUEVYIGluIHRoaXMgZG9jdW1lbnQuPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIEVzcGVj aWFsbHkgbm90IHdoeSB0aGVyZSBpcyB0aGUgUEVYX1JFU2NlcnQuPGJyPjxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoCArwqDCoCBXZSBtb3ZlZCBwYXJ0cyBvZiB0aGUgc2VjdXJpdHkgYW5hbHlzaXMg b2YgUEVYIHVwIGludG88YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDMuMTAsIHN1 Y2ggdGhhdCBhbGwgbWVjaGFuaXNtcyBhcmUgZXhwbGFpbmVkIGluIHRoZSBtYWluPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdGV4dCwgYW5kIHRoZSBhbmFseXNpcyBvZiB3aGF0IGF0 dGFja3MgdGhlcmUgYXJlIGFuZCBob3c8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0 aGVzZSBtZWNoYW5pc21zIHByZXZlbnQgdGhlbSBpcyBpbiB0aGUgU2VjLjxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24uPGJyPg0KPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAxMSBUaGUgUkZDIHJlcXVpcmVkIGZvciBwcm90b2Nv bCBleHRlbnNpb25zIG9mIGE8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgc3RhbmRhcmRzIHRyYWNr IHByb3RvY29sIGxvb2tzIG9kZC7CoCBUaGlzIG11c3QgYmUgYXQgbGVhc3Q8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgSUVURiBSZXZpZXcgb3IgU3RhbmRhcmRzIEFjdGlvbi48YnI+PGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgICoqKkVkaXRvcmlhbHM6PGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgIC0gQWJzdHJhY3QgKGFuZCBwcm9iYWJseSBhbHNvIG90aGVyIHBsYWNlcyksIDFzdCBzZW50 ZW5jZSBvZiw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgUFBTUFAgaXMgbm90IGEgdHJhbnNwb3J0 IHByb3RvY29sLCBqdXN0IGEgcHJvdG9jb2w8YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvC oMKgIERPTkU8YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAxLjEsIDR0aCBw YXJhZ3JhcGg6IEkgd291bGQgcmVtb3ZlIHRoZSByZWZlcmVuY2UgdG88YnI+DQrCoMKgwqDCoMKg wqDCoMKgwqDCoCBybWNhdCwgYXMgaXQgaXMgbm90IHlldCBjbGVhciB3aGF0IHRoZSBvdXRjb21l IG9mIHRoZSBybWNhdDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCB3ZyB3aWxsIGJlPGJyPjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBET05FPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCAtIFNlY3Rpb24gMS4zLCBvbiBwYWdlIDgsIGFib3V0IHNlZWRpbmcvbGVlY2hpbmc6IEkgd291 bGQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgYnJlYWsgaXQgaW4gdG8gc3ViLWJ1bGxldHMuPGJy Pg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIERPTkU8YnI+PGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgIC0gU2VjdGlvbiAyLjEgYW5kIGZvbGxvd2luZzogVGhlc2UgYXJlIGV4YW1wbGVz LCBpc24mIzM5O2l0P8KgIElmPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHNvLCB0aGlzIHNob3Vs ZCBiZSBtZW50aW9uZWQgb3IgY2xhcmlmaWVkLjxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAg K8KgwqAgRE9ORS7CoCBBbGwgc3Vic2VjdGlvbnMgbm93IGxhYmVsZWQgJnF1b3Q7RXhhbXBsZTom cXVvdDsuPGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAyLjE6IFdoYXQg aXMgdGhlIFBQU1AgVXJsPzxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDIu MywgdGhlIDFzdCBwYXJhZ3JhcGgsIGRldGVjdGlvbiBvZiBkZWFkIHBlZXJzOiBJdDxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoCB3b3VsZCBiZSBnb29kIHRvIHNheSB3aGVyZSB0aGlzIGRldGVjdGlv biBpcyBkZXNjcmliZWQgaW4gdGhlPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlbWFpbmRlciBv ZiB0aGUgZHJhZnQuwqAgSnVzdCBmb3IgY29tcGxldGVuZXNzLjxicj4NCjxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoCArwqDCoCBET05FLsKgIERlYWQgcGVlciBkZXRlY3Rpb24gaXMgbm93IGEgc2Vw YXJhdGUgc2VjdGlvbiBhbmQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZWZlcmVu Y2VkIGhlcmUuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rpb24gMi4yLCB0aGUg dmVyeSBsYXN0IHBhcmFncmFwaCwgJiMzOTtQZWVyIEEgTUFZIGFsc28mIzM5Ozo8YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqAgVGhpcyAmIzM5O01BWSYjMzk7IGlzIG5vdCB1c2VmdWwgaGVyZS7CoCBJ IHdvdWxkIGp1c3Qgd3JpdGUgJiMzOTtQZWVyIEE8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBj YW4gYWxzbyYjMzk7LCBhcyB0aGVyZSBpcyBub3RoaW5nIG5vcm1hdGl2ZSBkZXNjcmliZWQgaGVy ZS48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIERPTkU8YnI+PGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjIsIGxhc3QgcGFyYWdyYXBoOiBXaGF0IGlzIHRoZSBs YXR0ZXI8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgY29uZmluZW1lbnQ/wqAgVGhpcyBpcyBub3Qg Y2xlYXIgdG8gbWUuPGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIFJlcGhyYXNl ZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjksIGxhc3Qgc2VudGVu Y2UgSSBhbSBub3Qgc3VyZSB0byB3aGF0IHRoZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCByZWZl cmVuY2UgdG8gU2VjdGlvbiAzLjcgaXMgcG9pbnRpbmcgaW4gdGhpcyByZXNwZWN0Ljxicj48YnI+ wqDCoMKgwqDCoMKgwqDCoMKgwqAgK8KgwqAgUmVwaHJhc2VkLjxicj48YnI+wqDCoMKgwqDCoMKg wqDCoMKgwqAgLSBTZWN0aW9uIDMuMTAuMSBhYm91dCBQRVggbWVzc2FnZXMgVGhlIHRleHQgc2F5 cyAmIzM5O1BQU1BQPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgb3B0aW9uYWxseSBmZWF0dXJl cy4uLiYjMzk7LsKgIEkgaGF2ZSBub3QgdW5kZXJzdG9vZCBpZiB0aGlzPGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgIG9wdGlvbmFsbHkgcmVmZXJzIHRvIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgYnV0 IG9wdGlvbmFsbHkgdG88YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgdXNlLCBvciBpZiB0aGUgUEVY IG1lc3NhZ2VzIGFyZSBvcHRpb25hbGx5IHRvIGltcGxlbWVudC48YnI+DQo8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgK8KgwqAgTWFkZSBpdCBjbGVhciB0aGF0IGlzIE9QVElPTkFMIGFuZCBub3Qg bWFuZGF0b3J5LXRvLTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGltcGxlbWVudC48 YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiAzLjEyIEkmIzM5O20gbm90IHN1 cmUgd2hhdCB0aGlzIHNlY3Rpb24gaXMgdGVsbGluZzxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBl eGFjdGx5LsKgIElzbiYjMzk7dCBqdXN0IHNheWluZyB0aGF0IFBQU1BQIGFzIHN1Y2ggZG9lcyBu b3QgY2FyZTxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIGhvdyBjaHVua3MgYXJlIHN0b3JlZCBs b2NhbGx5LCBhcyB0aGlzIGlzIGltcGxlbWVudGF0aW9uPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKg IGRlcGVuZGVudD88YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIFllcy4gUmVtb3Zl ZC48YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA0LjIsIHBhZ2UgMTUsIDFz dCBwYXJhZ3JhcGg6IE9MRCAmIzM5O0EgUFBTUFAgcGVlciBNQVk8YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqAgc3VwcG9ydCYjMzk7IE5FVyAmIzM5O1RoZSBzdXBwb3J0IGZvciB0aGlzIHNjaGVtZSBp cyBPUFRJT05BTCYjMzk7PGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIERPTkUs IGZvciBieXRlIHJhbmdlcyBhcyB3ZWxsLjxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBT ZWN0aW9uIDYuMS4xIFRoaXMgc2VjdGlvbiBpcyBub3QgZGVzY3JpYmluZyBzaWduLWFsbCwgYnV0 PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHJhdGhlciBhIGp1c3RpZmljYXRpb24gd2h5IGl0IG1h eSBzdGlsbCB3b3JrLsKgIFRoaXMgZG9lc24mIzM5O3Q8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAg aGVscCBhdCBhbGwuPGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA3LCAx c3QgcGFyYWdyYXBoIFdoeSBpcyB0aGVyZSBhIHJlZmVyZW5jZSB0byBSRkM8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqAgMjEzMj88YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgICvCoMKgIFJlbW92 ZWQsIGp1c3Qgc2ltaWxhcml0eSBpbiBmb3JtYXQuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oCAtIFNlY3Rpb24gNyBpbiBnZW5lcmFsIGkpIEl0IGlzIGNvbW1vbiB0byBnaXZlIGJpdCBwb3Np dGlvbnM8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBpbiB0aGUgZmlndXJlcyB3aGVyZSB0aGUg c3ludGF4IG9mIG9wdGlvbnMgaXMgZGVzY3JpYmVkLjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBU aGlzIGFsbG93cyB0byBjb3VudCBob3cgbWFueSBiaXRzIGFyZSB1c2VkIGZvciBhIHByb3RvY29s PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIGZpZWxkIG1vcmUgZWFzaWx5IGFuZCBhbHNvIHdheSBt b3JlIHJlbGlhYmxlLiBpaSkgUGxlYXNlIGFkZDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBhbHNv IEZpZ3VyZSBsYWJlbHMgdG8gdGhlIHN5bnRheCBkZWZpbml0aW9ucyBvZiB0aGUgb3B0aW9ucy48 YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBUaGlzIG1ha2VzIGl0IGVhc2llciB0byByZWZlcmVu Y2UgdGhlbSBsYXRlciBvbiBpZiBuZWVkZWQuPGJyPjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAt IFNlY3Rpb24gOC4xIDEga2liaWJ5dGUgaXMgMSBrYnl0ZT88YnI+PGJyPsKgwqDCoMKgwqDCoMKg wqDCoMKgICvCoMKgIFdlIGZvbGxvdyBJU08vSUVDIDgwMDAwLTEzIHRvIGF2b2lkIHRoZSBraWxv ID0gMTAwMCBvcjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEwMjQgY29uZnVzaW9u Ljxicj4NCjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCAtIFNlY3Rpb24gOC4yLCBsYXN0IHBhcmFn cmFwaCBpICkgJnF1b3Q7QWxsIG1lc3NhZ2VzIGFyZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBp ZGVtcG90ZW50JnF1b3Q7IGluIHdoYXQgcmVzcGVjdD8gaWkpICZxdW90O29yIHJlY29nbml6YWJs ZSBhczxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBkdXBsaWNhdGVzJnF1b3Q7IGJ1dCBob3cgYXJl IHRoZSByZWNvZ25pemVkIGFzIGR1cGxpY2F0ZXM/PGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgICvCoMKgIElkZW1wb3RlbnQgbWVhbnMgdGhhdCBwcm9jZXNzaW5nIGEgbWVzc2FnZSB0d2lj ZSBkb2VzIG5vdDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxlYWQgdG8gYSBkaWZm ZXJlbnQgc3RhdGUgdGhhbiBwcm9jZXNzaW5nIHRoZW0gb25jZS48YnI+wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBSZXNlbnQgaGFuZHNoYWtlcyBjYW4gYmUgcmVjb2duaXplZCBhcyBkdXBs aWNhdGVzIGJlY2F1c2U8YnI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGEgcGVlciBh bHJlYWR5IHJlY29yZGVkIHRoZSBmaXJzdCBjb25uZWN0aW9uIGF0dGVtcHQgaW48YnI+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpdHMgc3RhdGUuwqAgVXBkYXRlZCB0ZXh0Ljxicj48YnI+ wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDguNSwgbGFzdCBzZW50ZW5jZSBpbiBicmFj a2V0czogV2hhdCBpcyB0aGlzIGxhc3Q8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgc2VudGVuY2Ug YWJvdXQ/PGJyPg0KPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gU2VjdGlvbiA4LjEzICZxdW90 OyBJZiBzZW5kZXIgb2YgdGhlIFBFWF9SRVEgbWVzc2FnZSBkb2VzIG5vdDxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoCBoYXZlIGEgcHJpdmF0ZSBvciBsaW5rLWxvY2FsIGFkZHJlc3MsIHRoZW4gdGhl IFBFWF9SRVMqPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIG1lc3NhZ2VzIE1VU1QgTk9UIGNvbnRh aW4gc3VjaCBhZGRyZXNzZXMgW1JGQzE5MThdW1JGQzQyOTFdLiZxdW90Ozxicj4NCsKgwqDCoMKg wqDCoMKgwqDCoMKgIFdoYXQgaXMgdGhpcyB0ZXh0IHNheWluZz/CoCBEbyBub3QgaW5jbHVkZSB3 aGF0IHlvdSBkbyBub3Q8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgaGF2ZSBhbnl3YXk/PGJyPjxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBSZXBocmFzZWQuwqAgSXQgdHJpZXMgdG8gc2F5 IHRoYXQgaW50ZXJuYWwgYWRkcmVzc2VzIG11c3Q8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBub3QgYmUgbGVha2VkIHRvIGV4dGVybmFsIHBlZXJzLjxicj4NCjxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoCAtIFNlY3Rpb24gOC4xNCBUaGVyZSBpcyBubyBzaW5nbGUgcGxhY2Ugd2hlcmUg YWxsIHRoZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBjb25zdGFudHMgYXJlIGNvbGxlY3RlZCBh bmQgYWxzbyBkb2N1bWVudGVkIHdoYXQgdGhlIGRlZmF1bHQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqAgdmFsdWVzIG9yIHRoZSByZWNvbW1lbmRlZCB2YWx1ZXMuwqAgRm9yIGluc3RhbmNlIGluIHRo aXM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgU2VjdGlvbiA4LjE0IHdoZXJlIHRoZSBkZWFkIHBl ZXIgdGltZSBvdXQgaXMgc2V0IHRvIDMgbWludXRlczxicj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKg IGFuZCBhbHNvIHRoZSBudW1iZXIgb2YgZGF0YWdyYW1zIHRoYXQgc2hvdWxkIGhhdmUgc2VudC7C oCBJPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgIHdvdWxkIG1ha2UgYSBzZWN0aW9uIG9yIHN1YnNl Y3Rpb24gdG8gZGlzY3VzcyBkZWFkIHBlZXJzIGFuZDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBo b3cgdGhleSBhcmUgZGV0ZWN0ZWQgYW5kIGp1c3QgbGluayB0byB0aGUga2VlcC1hbGl2ZTxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCBtZWNoYW5pc20gaW4gU2VjdGlvbiA4LjE0Ljxicj4NCjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoCArwqDCoCBBIG5ldyBzZWN0aW9uIFNlY3Rpb24gMTIuMS4xLjEg JnF1b3Q7U3VtbWFyeSBvZiBEZWZhdWx0PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg VmFsdWVzJnF1b3Q7IHdhcyBjcmVhdGVkIGZvciB0aGlzIGluIHRoZSBPcHMgJmFtcDsgTWdtdCBw YXJ0Ljxicj48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgLSBTZWN0aW9uIDExIFRoaXMgc2VjdGlv biBuZWVkcyB0byBiZSBvdmVyaGF1bGVkIG9uY2UgdGhlPGJyPg0KwqDCoMKgwqDCoMKgwqDCoMKg wqAgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHRoZSBJRVNHLsKgIFRoZSBzZWN0aW9uIGlzIG5vdCB3 cm9uZyBidXQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgY2FuIGJlIGltcHJvdmVkIHRvIGhlbHAg SUFOQS48YnI+PGJyPjxicj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91PsKgPHU+PC91Pjwvc3Bh bj48L3A+DQo8ZGl2PjxwIGNsYXNzPSIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEycHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+ RnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj5EYXRlOiAyMDEz LzcvMTU8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll dGYtcHBzcC1wZWVyLXByb3RvY29sLTA3LnR4dDxicj5UbzogUmljY2FyZG8gUGV0cm9jY28gJmx0 OzxhIGhyZWY9Im1haWx0bzpyLnBldHJvY2NvQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnIu cGV0cm9jY29AZ21haWwuY29tPC9hPiZndDssIEFybm8gQmFra2VyICZsdDs8YSBocmVmPSJtYWls dG86YXJub0Bjcy52dS5ubCIgdGFyZ2V0PSJfYmxhbmsiPmFybm9AY3MudnUubmw8L2E+Jmd0Oywg VmljdG9yIEdyaXNoY2hlbmtvICZsdDs8YSBocmVmPSJtYWlsdG86dmljdG9yLmdyaXNoY2hlbmtv QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpY3Rvci5ncmlzaGNoZW5rb0BnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxicj48YnI+PGJyPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRm LXBwc3AtcGVlci1wcm90b2NvbC0wNy50eHQ8YnI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBBcm5vIEJha2tlciBhbmQgcG9zdGVkIHRvIHRoZTxicj5JRVRGIHJlcG9zaXRvcnku PGJyPjxicj5GaWxlbmFtZTogwqAgwqAgwqAgwqBkcmFmdC1pZXRmLXBwc3AtcGVlci1wcm90b2Nv bDxicj5SZXZpc2lvbjogwqAgwqAgwqAgwqAwNzxicj4NClRpdGxlOiDCoCDCoCDCoCDCoCDCoCBQ ZWVyLXRvLVBlZXIgU3RyZWFtaW5nIFBlZXIgUHJvdG9jb2wgKFBQU1BQKTxicj5DcmVhdGlvbiBk YXRlOiDCoCAyMDEzLTA3LTE1PGJyPkdyb3VwOiDCoCDCoCDCoCDCoCDCoCBwcHNwPGJyPk51bWJl ciBvZiBwYWdlczogODQ8YnI+VVJMOiDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBwc3AtcGVlci1wcm90b2Nv bC0wNy50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLXBwc3AtcGVlci1wcm90b2NvbC0wNy50eHQ8L2E+PGJyPg0KU3RhdHVz OiDCoCDCoCDCoCDCoCDCoDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1wcHNwLXBlZXItcHJvdG9jb2wiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sPC9hPjxi cj5IdG1saXplZDogwqAgwqAgwqAgwqA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXBwc3AtcGVlci1wcm90b2NvbC0wNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTA3PC9h Pjxicj4NCkRpZmY6IMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1wcHNwLXBlZXItcHJvdG9jb2wtMDciIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXBwc3At cGVlci1wcm90b2NvbC0wNzwvYT48YnI+PGJyPkFic3RyYWN0Ojxicj7CoCDCoFRoZSBQZWVyLXRv LVBlZXIgU3RyZWFtaW5nIFBlZXIgUHJvdG9jb2wgKFBQU1BQKSBpcyBhIHByb3RvY29sIGZvcjxi cj4NCsKgIMKgZGlzc2VtaW5hdGluZyB0aGUgc2FtZSBjb250ZW50IHRvIGEgZ3JvdXAgb2YgaW50 ZXJlc3RlZCBwYXJ0aWVzIGluIGE8YnI+wqAgwqBzdHJlYW1pbmcgZmFzaGlvbi4gwqBQUFNQUCBz dXBwb3J0cyBzdHJlYW1pbmcgb2YgYm90aCBwcmUtcmVjb3JkZWQ8YnI+wqAgwqAob24tZGVtYW5k KSBhbmQgbGl2ZSBhdWRpby92aWRlbyBjb250ZW50LiDCoEl0IGlzIGJhc2VkIG9uIHRoZSBwZWVy LTxicj4NCsKgIMKgdG8tcGVlciBwYXJhZGlnbSwgd2hlcmUgY2xpZW50cyBjb25zdW1pbmcgdGhl IGNvbnRlbnQgYXJlIHB1dCBvbjxicj7CoCDCoGVxdWFsIGZvb3Rpbmcgd2l0aCB0aGUgc2VydmVy cyBpbml0aWFsbHkgcHJvdmlkaW5nIHRoZSBjb250ZW50LCB0bzxicj7CoCDCoGNyZWF0ZSBhIHN5 c3RlbSB3aGVyZSBldmVyeW9uZSBjYW4gcG90ZW50aWFsbHkgcHJvdmlkZSB1cGxvYWQ8YnI+wqAg wqBiYW5kd2lkdGguIMKgSXQgaGFzIGJlZW4gZGVzaWduZWQgdG8gcHJvdmlkZSBzaG9ydCB0aW1l LXRpbGwtcGxheWJhY2s8YnI+DQrCoCDCoGZvciB0aGUgZW5kIHVzZXIsIGFuZCB0byBwcmV2ZW50 IGRpc3J1cHRpb24gb2YgdGhlIHN0cmVhbXMgYnk8YnI+wqAgwqBtYWxpY2lvdXMgcGVlcnMuIMKg UFBTUFAgaGFzIGFsc28gYmVlbiBkZXNpZ25lZCB0byBiZSBmbGV4aWJsZSBhbmQ8YnI+wqAgwqBl eHRlbnNpYmxlLiDCoEl0IGNhbiB1c2UgZGlmZmVyZW50IG1lY2hhbmlzbXMgdG8gb3B0aW1pemUg cGVlcjxicj7CoCDCoHVwbG9hZGluZywgcHJldmVudCBmcmVlcmlkaW5nLCBhbmQgd29yayB3aXRo IGRpZmZlcmVudCBwZWVyIGRpc2NvdmVyeTxicj4NCsKgIMKgc2NoZW1lcyAoY2VudHJhbGl6ZWQg dHJhY2tlcnMgb3IgRGlzdHJpYnV0ZWQgSGFzaCBUYWJsZXMpLiDCoEl0PGJyPsKgIMKgc3VwcG9y dHMgbXVsdGlwbGUgbWV0aG9kcyBmb3IgY29udGVudCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhbmQg Y2h1bms8YnI+wqAgwqBhZGRyZXNzaW5nLiDCoERlc2lnbmVkIGFzIGEgZ2VuZXJpYyBwcm90b2Nv bCB0aGF0IGNhbiBydW4gb24gdG9wIG9mPGJyPsKgIMKgdmFyaW91cyB0cmFuc3BvcnQgcHJvdG9j b2xzLCBpdCBjdXJyZW50bHkgcnVucyBvbiB0b3Agb2YgVURQIHVzaW5nPGJyPg0KwqAgwqBMRURC QVQgZm9yIGNvbmdlc3Rpb24gY29udHJvbC48YnI+PGJyPjxicj48YnI+PGJyPlRoZSBJRVRGIFNl Y3JldGFyaWF0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSIiPjxzcGFu IGxhbmc9IkVOLVVTIj48dT48L3U+wqA8dT48L3U+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4NCjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+DQo= --f46d044402b604d80804e21c86b2-- From hishigh@gmail.com Mon Jul 29 00:15:13 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77DF21F9B8D for ; Mon, 29 Jul 2013 00:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co1ooSZ54-pW for ; Mon, 29 Jul 2013 00:15:13 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D921F9AF5 for ; Mon, 29 Jul 2013 00:14:57 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so3041321oag.13 for ; Mon, 29 Jul 2013 00:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=g2VrRmLOR+ggnLdKKX7zaubBRdRssjXnKqYzdFaeWtw=; b=Ddiwo37eRu+OCy7X5lAgCEw7W+ck9iPWPyo40oMOBtUXiel8thcvI1fOm7I1Z4oJot PDA5zRuss9LcpQgX1VDcy0idohEXfMGLFpNrlhR4Uo1BigAED6t8kDQoiFKbP80iGLrj vIXjAMqtYJqRQjxkYPC2b5e7gryP/XpMNCxXoFEKeZ/RDuOQ4USlLClDc7Iklg78Spgi dJ12ZklGLH+7ERo78s/W5nSWTC8SOdLgiY2a37uzgfXQCx5dqHepG3gsO/vX6CBYr34j JuwCM5veP6l8PFAdOTQ0qmW/7yf0Cq/trPohgwRjUc+HzANf5D1QXeoS/3R2OxPcRcZO xDlQ== MIME-Version: 1.0 X-Received: by 10.60.57.130 with SMTP id i2mr10590365oeq.51.1375082097144; Mon, 29 Jul 2013 00:14:57 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Mon, 29 Jul 2013 00:14:57 -0700 (PDT) Date: Mon, 29 Jul 2013 15:14:57 +0800 Message-ID: From: yunfei zhang To: "ppsp@ietf.org" Content-Type: multipart/alternative; boundary=089e013d0a6ceff74004e2a13f8c Subject: [ppsp] Please send the slides presented in PPSP session by tommorrow X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:15:14 -0000 --089e013d0a6ceff74004e2a13f8c Content-Type: text/plain; charset=ISO-8859-1 Hi all, Just to remind that please send the slides presented in PPSP session to Stefano and me by tommorrow afternoon, 17:00. Thanks and see you in Berlin. BR --089e013d0a6ceff74004e2a13f8c Content-Type: text/html; charset=ISO-8859-1
Hi all,
Just to remind that please send the slides presented in PPSP session to Stefano and me by tommorrow afternoon, 17:00. Thanks and see you in Berlin.
BR
--089e013d0a6ceff74004e2a13f8c-- From Martin.Stiemerling@neclab.eu Tue Jul 30 01:03:58 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED70B21E80C2 for ; Tue, 30 Jul 2013 01:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DauPcojnej+m for ; Tue, 30 Jul 2013 01:03:53 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7021E80DD for ; Tue, 30 Jul 2013 01:03:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C73EA103A4B for ; Tue, 30 Jul 2013 10:02:36 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueoXdvIWkyGl for ; Tue, 30 Jul 2013 10:02:36 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id AFA77102181 for ; Tue, 30 Jul 2013 10:02:31 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 30 Jul 2013 10:03:16 +0200 Message-ID: <51F77342.4060109@neclab.eu> Date: Tue, 30 Jul 2013 10:03:14 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ppsp References: <51F772DB.1070105@neclab.eu> In-Reply-To: <51F772DB.1070105@neclab.eu> X-Forwarded-Message-Id: <51F772DB.1070105@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [ppsp] Looking for a new co-chair for PPSP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:03:58 -0000 Dear all, Stefano Previdi will step down as co-chair of the PPSP WG [1]. I am now looking for volunteers to step forward as candidates for the PPSP co-chair position. Please send an email to tsv-ads@tools.ietf.org or directly to me if you are interested in being PPSP co-chair until August 7, 1pm CEST. If you send your email today or this week, we may have a chance to meet also with you. In the case you're wondering what a chair is supposed to do, please email or talk with Spencer or me. Let me thank Stefano for his service as PPSP co-chair! Martin [1] https://datatracker.ietf.org/wg/ppsp/ -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From a.bakker@vu.nl Tue Jul 30 01:43:23 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CD811E81C0 for ; Tue, 30 Jul 2013 01:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsHOTGvKh9d6 for ; Tue, 30 Jul 2013 01:43:16 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 727D121E80BC for ; Tue, 30 Jul 2013 01:42:34 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 10:42:26 +0200 Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 10:42:30 +0200 Message-ID: <51F77C9E.2060605@cs.vu.nl> Date: Tue, 30 Jul 2013 10:43:10 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20130711153958.21463.84549.idtracker@ietfa.amsl.com> In-Reply-To: <20130711153958.21463.84549.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.253.20] Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-base-tracker-protocol-01.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:43:23 -0000 Hi all browsing the changes I have one major comment on the current -01 base tracker protocol. It must be possible for a client to request a sample of the peer population of a swarm that MUST be random, for security reasons as explained in Section 13.2.3 of the peer protocol draft. Currently there is just an implementation note saying that the tracker MAY return a random sample when no PeerNum attributes are present in the request. We need a solution where it is mandatory for the tracker to return this, e.g. indicated by a new request attribute. Regards, Arno Bakker From a.bakker@vu.nl Tue Jul 30 02:06:37 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF80C21E80E7 for ; Tue, 30 Jul 2013 02:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS9OUzlwBWrY for ; Tue, 30 Jul 2013 02:06:31 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id A733311E80DF for ; Tue, 30 Jul 2013 02:02:53 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 11:02:54 +0200 Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 11:02:51 +0200 Message-ID: <51F78163.8050605@cs.vu.nl> Date: Tue, 30 Jul 2013 11:03:31 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.253.20] Subject: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:06:38 -0000 Hi all I have some comments on the extended tracker protocol's motivation. The draft lists 4 use cases that the base protocol "may not be able to deal with". "1. The peer list of a specific swarm obtained by a peer may be out of date": I always assumed that when the initial peer list received via the base protocol is outdated, a peer would send a new CONNECT message with a PeerNum attribute to get a new list. So why is extra support needed? "2. A peer may have the requirement to inform the tracker its new network address when the peer has changed its primary network attachment." a) Isn't this the role of mobile IP? and b) can't the base CONNECT handle this? It seems most of the spec is actually about finding peers based on what content they have and not these two specific use cases, so perhaps they can be removed? Regards, Arno From rui.cruz@ieee-pt.org Tue Jul 30 02:23:10 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EE021F8793 for ; Tue, 30 Jul 2013 02:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm3HBlB4HGyd for ; Tue, 30 Jul 2013 02:22:59 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0AACA21F9017 for ; Tue, 30 Jul 2013 02:19:21 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id en1so3991409wid.6 for ; Tue, 30 Jul 2013 02:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fXeqS2lsMbS7f65pQ4C18qXjkrL7P8AEqmeBqP85PB4=; b=k4YfZ5bEq4JiXT3VclialjKpAUfdYEzcDb0ek6FqYdNZxkmph+FT77a4Hp7BjozlhV +mXi741DkyILBiuna2kAqlLY8Ub0WKArMPY75Vh1IOetwc1LClmlF83ujyBoHYf3OOpr pTUoa4gw+M/me6smQystfC+IntQfIoT87BuhS0QcHbj01A5nc+RvuBD9arJIVC1VE5Hr n5TVxWssAMZYPiGasKlVJlA80F1qwku0prqGl6EWgjzQQEKnebZBqK7mVfRUFBIqcPJt /gVu+BBfdEFyfgYItz3Beqkj38moHbW6bH7/NpcaSenlfFUtlt5Sk1A+6F135YUsrt7d CVkQ== X-Received: by 10.180.126.10 with SMTP id mu10mr280087wib.64.1375175960653; Tue, 30 Jul 2013 02:19:20 -0700 (PDT) Received: from [192.168.1.216] ([89.180.13.164]) by mx.google.com with ESMTPSA id ev19sm27181002wid.2.2013.07.30.02.19.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 02:19:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC83FF34-B6A9-4F38-9FE6-3054A9171D43" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Rui Cruz In-Reply-To: <51F77C9E.2060605@cs.vu.nl> Date: Tue, 30 Jul 2013 10:19:16 +0100 Message-Id: <32BB007A-AA42-44AE-BF5C-8242527C64CB@ieee-pt.org> References: <20130711153958.21463.84549.idtracker@ietfa.amsl.com> <51F77C9E.2060605@cs.vu.nl> To: arno@cs.vu.nl X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkU3yr3TuOyGT/s22jzn6RGAeIF/9YlCAcIYcCr/oVnc0GykSwBsQ9vp2XpSIc3CnuGwiri Cc: ppsp@ietf.org Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-base-tracker-protocol-01.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:23:11 -0000 --Apple-Mail=_FC83FF34-B6A9-4F38-9FE6-3054A9171D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We will rephrase the text to reflect that condition: examples in section 4.1: In case the @peerMode is LEECH (or if the peer Seeder includes a PeerNum = element in the request) the tracker will search and select a random list = of peers satisfying the conditions set by the requesting peer. IMPLEMENTATION NOTE: If no PeerNum attributes are present in the request = the tracker MUST return a random sample from the peer population. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 30/07/2013, at 09:43, Arno Bakker wrote: > Hi all >=20 > browsing the changes I have one major comment on the current -01 base = tracker protocol. It must be possible for a client to request a sample = of the peer population of a swarm that MUST be random, for security = reasons as explained in Section 13.2.3 of the peer protocol draft. >=20 > Currently there is just an implementation note saying that the tracker = MAY return a random sample when no PeerNum attributes are present in the = request. We need a solution where it is mandatory for the tracker to > return this, e.g. indicated by a new request attribute. >=20 > Regards, > Arno Bakker >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_FC83FF34-B6A9-4F38-9FE6-3054A9171D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 30/07/2013, at 09:43, Arno Bakker <arno@cs.vu.nl> wrote:

Hi = all

browsing the changes I have one major comment on the current = -01 base tracker protocol. It must be possible for a client to request a = sample of the peer population of a swarm that MUST be random, for = security reasons as explained in Section 13.2.3 of the peer protocol = draft.

Currently there is just an implementation note saying that = the tracker MAY return a random sample when no PeerNum attributes are = present in the request. We need a solution where it is mandatory for the = tracker to
return this, e.g. indicated by a new request = attribute.

Regards,
   Arno = Bakker

_______________________________________________
ppsp = mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

= --Apple-Mail=_FC83FF34-B6A9-4F38-9FE6-3054A9171D43-- From a.bakker@vu.nl Tue Jul 30 02:23:49 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D07E21F9346 for ; Tue, 30 Jul 2013 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX7nyOuw0ShG for ; Tue, 30 Jul 2013 02:23:40 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22A1321F9E44 for ; Tue, 30 Jul 2013 02:21:30 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 11:21:25 +0200 Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 11:21:24 +0200 Message-ID: <51F785B7.9010003@cs.vu.nl> Date: Tue, 30 Jul 2013 11:21:59 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Rui Cruz References: <20130711153958.21463.84549.idtracker@ietfa.amsl.com> <51F77C9E.2060605@cs.vu.nl> <32BB007A-AA42-44AE-BF5C-8242527C64CB@ieee-pt.org> In-Reply-To: <32BB007A-AA42-44AE-BF5C-8242527C64CB@ieee-pt.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.253.20] Cc: ppsp@ietf.org Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-base-tracker-protocol-01.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:23:50 -0000 On 30/07/2013 11:19, Rui Cruz wrote: > Hi, > > We will rephrase the text to reflect that condition: > Great! Thanks, Arno From rui.cruz@ieee-pt.org Tue Jul 30 03:17:10 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8798D21E80D1 for ; Tue, 30 Jul 2013 03:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8UsEgGZ8ukb for ; Tue, 30 Jul 2013 03:17:05 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92321E80C8 for ; Tue, 30 Jul 2013 03:17:01 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id j17so3531104wiw.7 for ; Tue, 30 Jul 2013 03:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=pm64z1zEPXEy65X8wrf2ay2ZzEUDqoUElksQAossQiE=; b=ouCKo4/1bUXiNj6zVFb9vsMRp0weDsK0aqvmP2cU/zaBHTrUytmDQimjQF9FoopD3X QzivDaLBRwyCxFRrgECSf8dxcfGffhhOeKG2KrFAro5tRJIOZMnAJQZ1knIi5bsr62uD HnmyaHRnlqHQScR4JhgiXvyBfb8+fKv2SfcF0y24YPsX5hxSEC2umm1SukEk1EesYapS czm+iU23BSNQovp5/vEz6ODDBbLC/I34Zyq7Dt3ISMcc8L3q/88tKVKdLMVvaVRWoJgV 7aCaDbdTiey/YvyviSfqJSbSJV1V0x1/WFNypQxqt2uaijbFKSPHIjEd0uAGtjoyj573 u6Mg== X-Received: by 10.180.83.163 with SMTP id r3mr501260wiy.10.1375179419940; Tue, 30 Jul 2013 03:16:59 -0700 (PDT) Received: from [192.168.1.216] (89-180-13-164.net.novis.pt. [89.180.13.164]) by mx.google.com with ESMTPSA id v9sm13200449wiw.8.2013.07.30.03.16.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 03:16:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_527C2ED0-07F4-4658-BCAB-55DF1425B2F6" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Rui Cruz In-Reply-To: Date: Tue, 30 Jul 2013 11:16:54 +0100 Message-Id: <8661FDE3-E14B-44A9-BF85-D9174E2CBCAC@ieee-pt.org> References: To: yunfei zhang X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQksewNXf3CiSgRdBeR3YiSk70NKAucHkpvDIiTHmclwHZafjeWy2igb8RoYjg5kD9ZKvQIj Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Please send the slides presented in PPSP session by tommorrow X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:17:10 -0000 --Apple-Mail=_527C2ED0-07F4-4658-BCAB-55DF1425B2F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Yunfei, Please find attached the slides for the PPSP Base Tracker Protocol. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 29/07/2013, at 08:14, yunfei zhang wrote: > Hi all, > Just to remind that please send the slides presented in PPSP session = to Stefano and me by tommorrow afternoon, 17:00. Thanks and see you in = Berlin. > BR > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_527C2ED0-07F4-4658-BCAB-55DF1425B2F6 Content-Type: multipart/mixed; boundary="Apple-Mail=_83D74ABC-09E5-4BB5-BAA2-278E42575BAE" --Apple-Mail=_83D74ABC-09E5-4BB5-BAA2-278E42575BAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Yunfei,

Please find attached the slides for the PPSP = Base Tracker Protocol.

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list
= --Apple-Mail=_83D74ABC-09E5-4BB5-BAA2-278E42575BAE Content-Disposition: attachment; filename="PPSP Base Tracker Protocol 87.pptx" Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; x-mac-type=50505458; x-mac-creator=50505433; x-unix-mode=0644; name="PPSP Base Tracker Protocol 87.pptx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCs7ej9IQIAAJwRAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM mE1v2kAQhu+V+h+svVZ4IW3TtAJy6MepH5GSSr1u7AFW3S/tDjT8+45t4liRi+MsLlxAi5l5n50d XjOeXt5plWzAB2nNjE3SMUvAZDaXZjljP2++jC5YElCYXChrYMa2ENjl/OWL6c3WQUgo2oQZWyG6 D5yHbAVahNQ6MHRlYb0WSEu/5E5kv8US+Nl4fM4zaxAMjrDIwebTT7AQa4XJ5zv6uCKhcJZ8rL5X SM2YcE7JTCCB8uIqb43zoMKewI3JH9GNdmQpRZbJw0q68OrfCrfS9BOwi4XMILfZWtOmU+ch0Hup pRUtJRXDXwMi1TwU2/pB5+FlDsmV8PhdaNo8dw55MzLdX6CWfXZhPFClWkhzX4E2mGwd0OpfWnGJ oK+8dWESDVQnLfKBRwn1KTyR4ewEGF7/b4aiMYKibvkmAvVRaC7iD6XZctSsDaF9/VEz7WiG4ehD EN8abZXoQxDfGLEEb6JbM5bg7dEJzo9O8O4oBMXJlT59aPU6cddvYSPhzyAEdeIuAqQ/J8DL13hD KtN0KopbBde4VRAOXXd8SN1FUZr2V7G1a9z5cbWIL0KbH1S5n8s0jE/HMQ3j3HFMw3h5HNMw7h7H NIzfxzENcweIY7o4tD81TOe5XvD+BJkm41OEOpaT00xb3tJpoPfQvzD3k3cRPXJPmvpqRXoa0F/w 0QgMxeOGHPK+2tWkGi1fpWkR5+WzlflfAAAA//8DAFBLAwQUAAYACAAAACEAssp6gQMBAADkAgAA CwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0oDMRDG74LvEObenW0VEWm2FxF6E1kfYEimu4ubPyRT ad/eoIgu1K2HHpN8+eY338x6c3CjeueUh+A1LKsaFHsT7OA7Da/t0+IeVBbylsbgWcORM2ya66v1 C48k5VPuh5hVcfFZQy8SHxCz6dlRrkJkX152ITmSckwdRjJv1DGu6voO028PaCaeams1pK29AdUe Y6l83jvsdoPhx2D2jr2cKIF8EPaW7SKmwpZkKN2ollLHosEG81yuM1KMVcEGPE10e0kis88S3DzP l2YOaXlJpGmMP/nEKBgT55Lt5+TngFb/B/p7I9CxkCUhNCHxmYyK4hsIJ7vZfAAAAP//AwBQSwME FAAGAAgAAAAhABvEQJSDAwAAXgoAABUAAABwcHQvc2xpZGVzL3NsaWRlNi54bWy0Vttu2zgQfV9g /4HQuyM7cd1EiF3Ebl0U6LZBk34ATY0tohRJkLQTY7H/voeUlK5y2Tjprh9kkRrOzDlz4/m721qx HTkvjZ5mo6NhxkgLU0q9mWbfr5eD04z5wHXJldE0zfbks3ez3387t4VXJcNp7Qs+zaoQbJHnXlRU c39kLGl8WxtX84Cl2+Sl4zfQWqv8eDic5DWXOmvPu0POm/VaCnpvxLYmHRoljhQP8NxX0vpOmz1E m3XkoSad7rk0AzJxpcr47+21I4pvevfR2St76dLnL7tLx2QJvjKmeQ1asrz90IqlpYYYXvJ7xzed Jl7crl09O+cFsLHbaQby9/GJQ7yg28BEsyl+7orq6yOyovrwiHTeGYAHd0YjqgbRQzjHHZxrGRSx 0R2qRpTj6GcjfnimDXBG+A088WXXKYuYo3pbsbC3YCZEVa1c8zHx0cl7cJrICrdzU+4j8BX+0yYv lA9XYa8oEQK3eQHleIB+xWOGkh58v8pYKV1IHDFfh4UijlxuaQwzUEM65rdnyGP2qbaKYgql2J+D pIAYtZpJl5fc8W9PGoiAeQFXgKJzGa8Np08ze9IxuzAa3gR2qbigyqiSHDv+NZ5liSzpQvH/U5xi EWbXFTHrTDDCKCY9K8nLjaaS+a1A7CsemEQCc81WxJDLYBYf0RDQXyquRVxstYjVy5UMknwvFA3J ielng9569HErS1JSk2/MJJvoOIw7Yj3lz2p8LI0AdgcDJZMa8Iihn63DPbWHp8+LkF3o/8D/uzJg N9y/UF/LMFeOeLlHiFe1DAFccF/0KOiFDaXN1E61yfks6a2RhthBT+2zZxk5DJFUBLGeqy26w8s0 tNZ/za613r7ObFchg+C4+EFu0NVWT12P3le0wm+0Jof5Tkz2uuDr0gGF0PPuqSitYmSe6NGxnXuj ZLmUSqWF26wWyrEdR+IM8TtLjRzI/yGGFWZAFA+zRRoFW76hg5z511FxH8/h9fxwHKSp0N0fEN7P HnPGprG+dXKa/Tmfn02OF6fzwXw0Xg7G78/eDi6WkzeD5ZuT8XgxP71YnHz4K8OZ0bgQKLzYKj91 Vy5sPrjm1FI44806HAlT5819Kbfmhpw1Ml2ZRsP23pXYHQ9HJ2/PJpNJGkDwF16mwdZ5i63uKiSU +4Pbr7tEOm54gRyihC2LDovaiaI/RSJ2XKH+BgAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3 AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dS imVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0 FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7 Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA //8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUy LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiP g3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLL EMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8 c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhABLx9cSGAQAAQQkAAB8A CAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAvJZNT8MwDIbvSPyHKneadZ+A1u2CkHZAQmxIu2at10W0SZR4g/17om50H2KG Q7RLJTut8+itXyfD8VdVRhuwTmqVsiRusQhUpnOpipS9z57v7lnkUKhclFpByrbg2Hh0ezN8g1Kg /8itpHGRr6JcylaI5pFzl62gEi7WBpRfWWpbCfShLbgR2YcogLdbrT63xzXY6KRmNMlTZid5krBo tjV+67+L6+VSZvCks3UFCn/Zg7tS5uALClsApqwO3S47iD0q4xco2iEpjJUKwU4B0evsDjxnC/ws TuKFVBcRO2ERwb1abU7g9ilSqG5Iio2EzzOKJkVS9EJSoO/mo6apQ14/ExKiHxRCLEqY4rb0Bmz6 Fw9JkiQkSLZ2qKu590qDEce8yXKJUJG6BLVSsy9B06a0Ceqa/9B0KJqg7qmn24twftQc1DlK7gff 7g3ylwW1EzGDSYigdiIgyHYZhLQSAUF2iT+Tr3IkdqlWfbgSRI+CSPx95SpS9H8o+MnFZ/QNAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQu eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEA5zUqZ6kCAACqBwAAFQAA AHBwdC9zbGlkZXMvc2xpZGU3LnhtbORVTW/bMAy9D9h/0HRPnTRu2hpJijpthgFdGyzpYUdNZmKj siRIappg2H8fJVst+jUEwbDLLv6QyCe+R1Icnm1qQdZgbKXkiPYOupSA5Kqo5GpEbxfTzgkl1jFZ MKEkjOgWLD0bf/ww1JkVBUFvaTM2oqVzOksSy0uomT1QGiTuLZWpmcNfs0oKwx4QtRbJYbc7SGpW Sdr6m1381XJZcbhQ/L4G6RoQA4I5jNyWlbYRTe+Cpg1YhAnez0IaIzM+F4V/W70wAP5Lrj8bPdcz E7av1zNDqgL1okSyGmWhSbvRmoVfiWb4kbxwX0Uklm2Wph4PWYbcyGZEUfytf6ITy2DjCG8W+dMq L2/esOXl5RvWSTwAI3g81LNqGL2mk0Y6i8oJIP1HVo0pQ9crxe8skQp5evoNPX69jmCes4fXJXFb jco4D9XaNZtBj2hvUdMgltvkqth64j/wHRZZJqybu62AIAiGzTI0J0yssFa5Mx6WZXgePnBdMF+0 IDu3c0qKyrggG7G1mwhg6NIq68aLksk78l3dk09DVMlhklockMWMGfbtXTjPGMMIaY0xI6NG1Pel PXqU1ud1JhiHUokCDEk9C6y5qOFeKnvNKJYk1ktMyl8X28tsNc9h2X7NnCVrJlpdUZW46wXyZbBX biaq9g1uCTNAHkBwVUPxPE1NAkIWXlbEPkHunvN/d+TLqv0PKP+hs0KDxbsYG+jKYsvqcEXem2pE f+b56eBwcpJ38l467aQXp8ed8+ngqDM96qfpJD85n/Qvf1H06aUZNxCu/S9xfOHiq5FRV9woq5bu AOsvaWZPotUDGK2qMH563XaGhRZIu+lp/7h3nA7auw6jDHdEjBYpxLHChfnK9M06dAhOSwdmEpY0 zkevApo+mXjuOI5+AwAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2 iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7 yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesM HYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAh AEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc4SPwQrCMBBE 74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4 306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSm qrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqim Vl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBskBhtwQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTcueG1sLnJlbHOEj0GrwjAQhO+C/yHs3aQ+QUSa9iKC8E6iP2BJtm2wTUI2Pl7/vTlW EDzODvPNTt3+T6P4o8QueA1bWYEgb4J1vtdwv503BxCc0VscgycNMzG0zXpVX2nEXEI8uMiiUDxr GHKOR6XYDDQhyxDJF6cLacJcZOpVRPPAntRPVe1VWjKgeWOKi9WQLnYL4jbH0vydHbrOGToF85zI 5w8Vikdn6Rfn8MwFi6mnrEHK5Z2XYifL+6CaWr3NbV4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3s vwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2 blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0I zugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z 0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sP AAAA//8DAFBLAwQUAAYACAAAACEArUY0ZYACAABxDQAAFAAAAHBwdC9wcmVzZW50YXRpb24ueG1s 7JfbjtowEIbvK/UdLN9WbA7kRERYqVshrbSVUGEfwJsYiNZxIttQ2KfvjBOKC6q0D5C7OP/MP/aX sTHzx1MjyJErXbeyoMGDTwmXZVvVclfQ181yklGiDZMVE63kBT1zTR8XX7/Mu7xTXHNpmIFUAjZS 56yge2O63PN0uecN0w9txyVo21Y1zMBQ7bxKsd9g3wgv9P3Ea1gt6ZCvPpPfbrd1yX+05aGB8r2J 4sLOQ+/rTl/cus+4uav4d0qaHfn68Ka5WbbSaKBDCTuY9qltMEmv6tIc4KGgPl0ADy2qn0wbrp6r F21u3pC6KmgYRGk0m0ZxTInK8Q3ERtRbzL3/pLtWz1VvEidOdozZNvkip655cicnoZOd3stTR87u Zbf27E7O3NqBf6fHqeMeBKj3K3fXuf4g5amgsyCKfB/6sTwXNMnizA7MuYMu1KXiXEanaV9Btobr Ie1vJKZdPCyjim/ZQZgNP5m1OQu+mLMc3q1Wanj6tVJEMGx8Lievazs7N0QcRdBBTMPUC350wsQO No2gBGw27G39UdAoTqGrYZVG2BDOXuR39W6bB1tUDkMI2UMp2AergywN6s4sNDgFsGBK3rnCfYme qOtW1NWyFsIOcI/xJ6HIkUE1c+qB3kTZqgS5bVkJ7L41ciIMLo7lnN0InPVCqW+EUl9xACf4biwf eKARPIZXNBcIIx+EMvCZXvn0bTn2z1EglIFPdOUTTNMgwe4fGwipDIBiB1AWZvZ4GAEhlQFQcgUU hhk00NhBcC4jlQFQ6gBKo6n9oRo7CKkMgLIrIKQD94/xDDoKpDIAmjmAkjgdD2l79UEq9iZ7f8WE 6637D2PxBwAA//8DAFBLAwQUAAYACAAAACEAR9cpnJkDAAB9CgAAFQAAAHBwdC9zbGlkZXMvc2xp ZGU1LnhtbKxWUW/jNgx+H7D/IPj5UidprkuNJocmbYYDrtegyWGPAyMzsVBZ8iTFTTDsv4+S7evS +takGxA4tkR+Ij9SJK8+7XLJSjRWaDWKemfdiKHiOhVqM4q+LWedYcSsA5WC1ApH0R5t9Gn8809X RWJlykhb2QRGUeZckcSx5RnmYM90gYr21trk4OjTbOLUwBOh5jLud7sXcQ5CRbW+OUZfr9eC443m 2xyVq0AMSnBkuc1EYRu04hi0wqAlmKB9YNKYPOMLmfp/WywNon9T5a+mWBRzE7a/lnPDREp8RUxB TrREcb1Ri4VPRWL0Er9Q3zRIkOzWJh9fQUK+sd0oIvL3/klKkODOMV4t8udVnt23yPLstkU6bg4g C74f6r2qPHrtTr9xZymcRNb77lUlCqT6RfNHy5QmP737lXv8a9mAeZ89fJExty+IGeeharlqM/DR yFviNJDldhOd7r3jK/oPi5BI6xZuLzEQQmZDQuD0IPol+AxF1fm2iFgqjAscMZu7qUSgXK5pdOMH /GOL1rE7tBY2aK+IF0dhqcFQpXMw8PBDTO8jJHQ6Gd5YSa8VjT8m87whc6qVo1RjcwkcMy1TNKz/ 36gVKSVGw/4prHr2FF3K663Ta+Eq1yrC/daxfK9C6rez7nGsliKdCSnDh9msptKwEuQoGsyGvclN yIcDMR8Nnzk+NIvl9fL3h9v5/cPyRazeEf2EHWBUkQzhpIePeUlWBSrfTK6QhW68tZgegr6p2ZaW qz2DE2FqA+ZIGeT0icptNgjlKzRzGZ4IVluyNMAfyZgDit/Fhla+zThhneAsBQeMek5Y2trkAL49 guFCvevkz5YJJZwAd3JYaxYokp7BgsLygZ5GUPvkIOWePWWC6ihwJ0o8O/CC6vtbdedlwP5vx+9g zzjVJmrElYnC7Z+DYA/tbT/8uHvz0hF/x3/LUFEbccQ9l1s/bvzj6JAAH9gKMyjRMqDfcSn2b3Wp DtYjYtEBSQE5DrK9yNVgVmwUSH8XfQK46ja0Efe6dYQO0owX1Ou/WOpJRej6WyNG0Z+TyeVFfzqc dCa9wawzuLn8pXM9u/jYmX08Hwymk+H19Pz2r4h0eoOEGwyTzOdmIqPFV1NQLrjRVq/dGdd5XI1T caGf0BRahImq163HslCq+5cXw273st8f1O2brAxNsLGWXGgmJS7NHRT3ZSjQNAA6NFTyaamgyBJZ XvRZxPtOE9bfAAAA//8DAFBLAwQUAAYACAAAACEAztcNo6AFAACsIAAAFQAAAHBwdC9zbGlkZXMv c2xpZGUxLnhtbOyabW8aRxCAv1fqf1jdp1YNgTsODiPjyOBgJXIcFIj68m1ZFnP13u5pdyF2ov6Y qj8lf6yzL2deDIi4uC6VZQnubnfnZuaZGe52fPzqJmNoRqVKBW8F4ctKgCgnYpTyq1bwcdAtNQKk NOYjzASnreCWquDVyfffHedNxUYIVnPVxK1gonXeLJcVmdAMq5cipxzGxkJmWMOpvCqPJP4EUjNW jiqVejnDKQ/8ernLejEep4SeCTLNKNdOiKQMa9BcTdJcFdLyXaTlkioQY1cvqXQClpE+G5lvlQ8k peaIz85l3s970g5fznoSpSPwV4A4zsAtQdkP+Gn2lMM0OCivLL8qJOHmzVhmJ8e4Cbahm1YAzr81 n7AIN+mNRsRdJPOrZPJ+zVwyeb1mdrm4AWhwd1NjlbPovjlRYc4g1Yyi8M4qNxXD0gtBrhXiAuw0 5jvzyOWsEGZsNuLzCdK3OXiGaGml+alu3LqkWKKsWwtd75xRb9QaFeeRsBJX61F12S9JkkSxmWC8 E8ZJpRLV7E0KSXATJzpv6pu2GN0arw7h21LBTaZ0X98yar0NPsFN0Bw+gC3DJvwpL33sB2iUSm0B IJXpDqMYEsUz0ie9Xr+H2lhRNJCYXFOJelJoQQQ7BvdroO/FUj7qYYk/bJRuXImboAfoXehrTTDu 3MysVjDrT4faYouMFyCIHRRkZEEYhYExzgNci81d5HcoN3AJq0lY92CiRliLwmQZTB2oWHIGTLUG f42jJTBgpVT6nIoMmYNWICnRVj08u1DaO8JPsf7YxNFULlg/EfJzgNgbrlrBURjHEBTansS1JIIT uTgyXBrRrCOY4Wm8w6FcnU61GKdeCRctZqgIFns8YyHELMqwvDBLUcpHUEvsIWZXEB4Q9BA3dDzA w/7nVmDVMHpoeytE8QVvy2tbP0wB4/4Upkwg8qBK9qacgMACGmnTscNHekSjGQY5UEWBgnOWyosZ w2lXcG1zb4wJ5N+pTDFzgIbTS6jhsAI3QTcTiQqUq4KgAEHkmvpvju2NBEtH3ZQxe2KKOu0w6W6s b5xaoLdXJaktqFJMtuGsFuVYUxdU+ynjJaZ98OCVAYrdAFErA0R5o50N9jbMETHKwmE0h1N4/qAJ RTabDp6QweIJVeeEbL4eeg65H6KDJ2SweELxnNBdwT/sJDIl6vDLnOHiEdUWEDWihi0Sz4ie/pfI cPGI6nNEUdSAp6aDL3T/jywyXDyiZAFREruHoecsevosMlw8osYckeFjX/qeET09IsPFIzpaQFSv Jfb98BnR0yMyXNwbkt/sMLy27HWYF0L3urF11wP28sZ6ZYPDhsK9zZMdBZYeLIxK2D2Efbg1ezMp 1eMHy10j71GUzHOV71XJIWxGlbTbjCrl6zaj3DbTPuLA7n79fL6k//6kv3k96KIl2Zu26HaMskaC 2lSylK8I3bQ3t4PYJWv3JWdzKoX2KX+em1ui/xK2kVbs3F3umujfncQ3KPmb2LOSP+zTZN8koPLH JalLzP+RTz9MU9SR088vHsW5777+KVOxpPq2BFrF9m/FwOWUU7VPLR/Hm79CPv2e0n0q+ijUz6f7 VPFxfPk25Z9ouk89H+7KNWH+S4rv2T18cKJDufCLzcPX2iek1dTbUtbfiq9//fdzeoBnNJV4n4Rf oDPKrx7OeYtPLyC12Wo4bvsxX+W1EkNLPxDfIMd3vuCB/V4L0HYCi240tIahT2aafKZJPJVpK/jS bh/Vo06jXWqHcbcUnx0lpdNuvVbq1qpx3Gk3TjvV138EsCaMm0RS2/h+UzTw4eK9pnmWEimUGOuX RGRl130v5+ITlbmAzg804MOK7+LbflS1ksCreT1p2P4j6Au6WUsKbeFS0VgnTL7D+fuZzSn4fwFN JbSX4FIOJIwXYOp8irEdGvJ/AwAA//8DAFBLAwQUAAYACAAAACEAlWWLtlkEAAB2EAAAFQAAAHBw dC9zbGlkZXMvc2xpZGUzLnhtbOxXX28iNxB/r9TvMNqn3gNZIFwu2QucAoFTpTQg4PpaOV4D1nlt 1zYEVFW6D9J+ufskHXt3uSMBSkKivpSHZdc7Mzu/3/yx5/LDMhOwYMZyJZtR7aQaAZNUpVxOm9Gn ca9yHoF1RKZEKMma0YrZ6EPrxx8udWJFCqgtbUKa0cw5ncSxpTOWEXuiNJP4bqJMRhw+mmmcGnKP VjMR16vVszgjXEaFvjlEX00mnLJrRecZky43YpggDj23M65taU0fYk0bZtFM0N5wqYXI6Eik/t/q sWHM38nFR6NHemDC69vFwABPka8IJMmQliguXhRi4VGiGN7ED9SnpSWSLCcma12SBLHBshkh+St/ RSWSsKUDmi/Sb6t01t8iS2fdLdJx+QH0YP1RjypH9BhOvYQz5k4wqK1R5aIEVW8U/WxBKsTp4efw 6O2iNOYxe/N6Bm6lkRnnTRVy+cvARylvkdNAllu2VbrywO/wPyySRFg3civBAiHoNknQOF6QfkF8 hjJZ+TSKIOXGBY7AZq4jGMFcLmh0rYFRTlEloI95vuDs/hKJcRiXwhqT6YAYMtxp1IMkCX4ePS/d xNucx91snpZsdpR0mGswEISymRIpM1A/jlueYmaU9D+FVk+fxKq8mjs14Q4m6NuIEoGRelfFXwRC jjQdsnROfWU1I6xWXM45yEPjbbxIZMYzBm1iGYwNoZ+RlXWo5pZZcPcKMmYtmeIDthJwKI+dxYSq TTbCmAcoRAlL598i+jBNNrQxI0EsRMHvs1KOwIZzu2zchQ6yPXk9yVYJnva4EOHBTO86wsCCoGuN 3nmtfV1E5Tsxn9O+AH2Cd/q3t93O+DBXtjsR6s61huz3ObOuDAY4BV+//GXYlFvHzNcvfwNuEDEG yBSCB6Hf/sn9uHu977JxB24SEtceg3u/E96FdUnscEJJsPfEZD/ZN090pOBcTZ6o9zCnfQpYZxjJ cNcFmvcg+34jNHvz/v8q8hSOxlfjyrA76A9foZI2gvGcLlEkywukCtY0dlaOJz/cDcQKuPSHt9By y+5M7tTcAXfWnwjd3PqqBzvXGsX9CnYDTgvF0KL3JNtxyfWMU8BYAfYqrAXiGCDCgMO3igV3Hm1A elA81n2rIH9QHyD8stCeZmJr0fpTCmXBoQHDXTEjq2M2O3Rzb50/g8wRhg8IlDtMsT/4PnME/P1N 9/DO/3o+HNL4nfpPKYCb7tWv3SdSsJ/5Q1AXe92rQT/EhzfvN2G/eNI7pQGHRj8br3sl+P3ht3x/ 2NbuHo8MYXIo50oc8m4sziI6jHtzw5vRH+32xVm9c96utGuNXqVxffGuctU7e1vpvT1tNDrt86vO affPCHVqjYRi2/HH9J/LURwXH42/GadGWTVxJ1RlcT5Hx1rdM6MVD6N0rVrM4+FwWb+on140atV6 OWCgl2H4Kb1FCOWITIX5hej+IjQRnPyxx+IhFZc0suQ7D4p+E/HYcbT+BwAA//8DAFBLAwQUAAYA CAAAACEApJdpWGkFAADVFgAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbMxYXVPbOBR935n9Dxo/ tTMJSYBSmgE6xIQuUwgZ4v4AxVaIprbkkZSv7ux/3yPZTuvUpNgss30gJLZ0de65n7pnH9dJTJZM aS7Fudc76HqEiVBGXDyee1+C6/apR7ShIqKxFOzc2zDtfbz484+ztK/jiGC30H167s2NSfudjg7n LKH6QKZM4N1MqoQa/FSPnUjRFaQmceew2z3pJJQLL9+vnrNfzmY8ZFcyXCRMmEyIYjE1QK7nPNWF tPQ50lLFNMS43SVIF9AsnMSR/a/TQDFmv4nlJ5VO0rFyr0fLsSI8Al8eETQBLV4nf5Evcz8FluFL Z2f7YyGJ9tczlVyc0T50I+tzD+Rv7Cc20T5bGxJmD8PvT8P5fcXacD6sWN0pDgCC7aFWq0yjn9U5 LNQJuIkZ6W21ypZSbL2V4VdNhISeVv1MvXC0LIRZna34dE7MJgUzxorK12UvHR/Feg1OHVlmPZDR xio+xX/3kPZjbSZmEzNHCGDTPoTjA/TH1HooE+0vE49EXBnHEdGJ8WNG4cs5jebCn2Mp04QL0u72 zsCKgVFyUUxEY6row5MSrYa0j7MBu8CIrxmJT1N5VFDpS2HgaGQc05DNZRwxRQ5fRiyP4BYF93U4 tdwJebkwcsZNplhGtn3xXK71Nxx+2oWvTl0A7OX+gS05WxE5Izu8V9uxluyAqYQLGcvHTU3heyG3 ylAz4zsPwId1k2Wcs/+UNzotTixD24OcA5uL4PlAy/ur/FqWgdZHM5NxLFeNpVRhGo8n48YCc5LG Sk5jljQWU4VrgkzPbN04KIv9b6xbeaJMGBHw/aYmz9mI2IwL7oocoVHEIvJmPBw+kNubSdAi/l9f Rp/JzVWLWObbwbhFJsNPd8NRkL1qeniVRi0SPFyOJpd+cHM/eqlaN1dvd0yBivdELq6Ip118r2fH ezNHxv7RColcwgpGkssUXU7E18Q/KPH8emAm1ql+xKJYhuaNkIYoNmMK3RvQodYZNBBvy8B+QbFL 6tuUtZfiX6XvJ6XY4hvMWQ33qSo129jQoeKpDQ5bYvz70WjoB3Vlb7HmUldUk0UaIWFEjUXtkmfV hseEMVV8tmksNkcIl4SFs+ba6q5YKJVNDejTiW2sDf7wc9r8pEoFcKxRNPyKgCg5/N7SU/aqXAPX uAPhips5GTMIRG5DS65xQ2iRWIauMXf6ND2pSgMaGr7kZkMSGdX2wV0/sTFW35O3Uqrw6RVVif6/ gna3n2MKFzPXZ1r3tVYaLZKm5sgNTxhKu+2Hm8qpog2OYxQPbcAiyChCYM2TRUKWNF4wmxmOuq/S 1VVhKc4Wi2QKt8bh0FZx3D8AbcoQq2ahbHDCfWjm+rdcmxIdr1dAcOiUC6o2JMseLefCCQKPPtYJ iHJ3mttW82/NZVRxOUVeAza8onFcK+lU4jO4CJJeDc8rSyHlePjMByWj7U2CZUk5Xzs+WUNAFVm4 0hlkz8yvXojMpmEMAAK/eTNfBTG1taPs6r9JS+LLJM0Sk42N57O3pzn5sUC/TGAVlaj6HJ2eQD1j JGEhXJvrRNeFvrcauevGb1KM8pC5T5nKJn5NeoPdAlcxLLqjApmQTnls24SadtvLpmZoPmA2pDS4 GmrVC5gFG1mN+Hko5WZTxdgSV4BbjWlX6qaJC8XPvb8Hgw8nh/7poD3oHV+3j68+vG9fXp+8a1+/ Ozo+9genl/7R8B8Pe3rH/VAxx/ZNMenFw5+mqwkPldRyZg6gWicb03ZSuWIqlWhFMantdfNxLwoy Oopu7+j9SffD0XE+FgRK6OMwOrT4Wkxgw1jd0fR+6e4bGCwbpnz3KEWGsixg6fclVndMbv8FAAD/ /wMAUEsDBBQABgAIAAAAIQCv6tdTqAQAAOIQAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTQueG1srFjt buI4FP2/0r6DlV8zUinQ0m7Llo4KhdlKnRYV5gGMY8CqY2dt86XVSvMguy83T7LHTtJZKKMSyp+Q OPbNueeee+3L1adlIsmcGyu0akX141pEuGI6FmrSir4Oe5WLiFhHVUylVrwVrbiNPl3/+stV2rQy JlitbJO2oqlzabNatWzKE2qPdcoV3o21SajDo5lUY0MXsJrI6kmtdl5NqFBRvt7ssl6Px4LxW81m CVcuM2K4pA7I7VSktrCW7mItNdzCTFi9BukanrGBjP2vTYeGc3+n5p9NOkj7Jrx+mPcNETH4ioii CWiJqvmLfFp4VJiGm+rG8klhiTaXY5NcX9EmfCPLVgTyV/6KRbTJl46wbJD9GGXTxy1z2bS7ZXa1 +AAQvHzUe5V59Nqdk8KdoXCSk/qLV9lUiqX3mj1bojT89O5n7rGHeWHM++zNp1PiVimYcd5UPi97 Gfgo5ltwGshyy7aOV97xEX7DIG1K6wZuJXkgBLBpE8ZxAf2SeoVyVfk6iEgsjAscEZu4juQUWs5p dNdP/M8Zt4584dbSCbdX4MUhLLkxruI+NfTppza9j7SJrwN4gRK3GY0/J/O0ILOjlYPUSF9Sxqda xtyQk/dRK2IIo2C/DKuePYWkvJk5PRaOjIFtwKhEoC7OajUIUKpByp54PGM+sVoRkhXDGQdZZLyN XQMzCjnyEh6/1Gop4p6QMjyYyagjDZlT2YoavYt6+zb/1v+m+Uh5VfmwdR4fHrqd4UYM31BFkI+7 bpKNZW+GflNOmQ6CGHDxipkDdwjEXtKcWR5vgtrNl8WUK0JJn0NMG169YWDTJ8/qWBgkyPdv/xg+ EdZhO/j+7d+SdnOSnSZuykuu3YbJrgAkIdh6iMkzGABpkGWApxWxC2oS+/saAYeOkRgTKg2n8Qo4 MnZ4fETgZwFrPDNw2Xj+9oUX6sFeEhqC7KCC1Oi5iLklwtkwUrm7PQr0+Xjc9QmNY2x6FjPAnJ8k UJfMGEXJkg93/XnjCLPm5x+P14O3nc9DAn7FG04aRBuSaMOzEH+wH3eI8fswDQ1lz6WzKVe94Uyb 2B5I+j6eiN6ay2+KI0dyRJhWijNXKbd8Wwo6kfCjdTXsCiM9TGFak205h3I+fP2QQj37U6ybbW7+ e9TK4zUY78mOHKHPYJeLD8dnf75a+8SblG8LHapWqArCkvtut/NHSZM5NCTh+6EMut1b1JoskzeK ZF5CsQv6OM3SmDpUo3LfzLH6Kldu4Tbe8tQraamAcKi9L2SPxE5sdyrG+x9AvPbKkZa7mnA31Yia lHpRNmDbeKfEcjYzwq32wyPpqnTt3oYD2/qIE7QLdAT+pxDmiLsFx2FrL5q8KEMeenkfRqH5PrWt DL1uUEKfUjSx6CjvLTqfNPSWILsV/dVuX56fdC7alXa90as0bi9/q9z0zs8qvbPTRqPTvrjpnHb/ jrCm3mgynIJ8U3BX9P0YfNVrJ4IZbfXYHTOdVLOmvZrqBTepxoEDfXu9ljf/4dBfb5yfNS5P61mP EaCFTqsACw+KdpxJ84Wmj/NQtPEvA04v6B0wlOJ/BejST/0xxbuONv4/AAAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQy LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxzhI/BCsIwEETvgv8Q 9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62 IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277 AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRk o+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLB RRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn 6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5y ZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvg NdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1I E+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoa pJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQ kaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4 Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9osp TlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP// AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0Ni54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tj BcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZ w5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMi n39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SP wQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB 3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOv Ipo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33ku alneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDg RfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSw b5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtka xPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwME FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnF ZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6d pTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhADTNuc4fAQAAxwcA ACwAAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBgG 4PPB7kG+88WYtukPNT0Zg8KORncBEr/8sESD2rHc/aQwSGBzFAKeCBp8ffIe6PH01XfkE41tteLA khQIqlLLVtUc3i8vTzsg1gklRacVchjRwql4fDi+YSec32SbdrDEpyjLoXFuOFBqywZ7YRM9oPJf Km164fzU1HQQ5YeokWZpmlMzzYBilknOkoM5S8aAXMbBH/1/uK6qtsRnXV57VO6XM6jtWomvYtRX 52OFqdFxSJLpup1OGEv8DwD9w5YtaXO+NJypbiv0NoYdSzLurijU0KIF3SvLQrJVzM5WIdk6pmwd km1iyjYhWR5Tlodk25iybUjmb/Z4F+suJNvHlO1DMubfx3ilsfTHRmfPb/ENAAD//wMAUEsDBBQA BgAIAAAAIQDNGFHG6wcAANQuAAAhAAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s 7FpbbttGFP0v0D0Q7GfBSHxTQuTAkq02gJsatbOAETmyWI9Idjhy7AQFsofuoLto+9elZCW9dx4U ZUuJDMuFFRgwJHJmeDlzz7lP6+Wr6zmzriiv87IY2O6Lrm3RIi2zvLgY2G/Px05iW7UgRUZYWdCB fUNr+9XBt9+8rPo1y34itaDcAhlF3ScDeyZE1e906nRG56R+UVa0gLlpyedEwC2/6GScvAPZc9bx ut2oMyd5Yevn+TbPl9NpntKjMl3MaSGUEE4ZEbD/epZXtZFWbSOt4rQGMfLplS0dwPnSM5bh9+RC ff5Cp1aeXYOWul3XPnhJ+vKcdMS4dUXYwJ5cuHbn4GUHH4HF+gofrqtzTileFVc/8OqsOuV4k765 OuUgE0TaVkHmoF8UICf0MnlbwDIleOXxCyOJ9K+nfI47AvVYsENA8QY/4SHSp9fCStVguhxNZz+v WZvOjtes7pgXwNGal+Kp1InuHsczxznPBaPWKSMpnZUsA65IFckTqsdAi9VJmV7WVlHCmVEV6qig HCMYz4+vqmaWuKlASwLF6nVqEnZWNOtrqV+z6UYrQRgD6aRqvDiI/GRVP4nn9SKcRy25buB34Qb3 shRU8Vr8QMu5hRcDm9NUSCKQq5NaqKVmiURfbaTqi+thmd0gGBP4BszB4uD5Wcnf2xZ7XdQDu+cG AbxbyBu5U9vi7ZnJyoxgoxIoB0+QIgU5AzsVXO6lAGs7XIhymusdqVfiy1ktzsQNo5IWAB7pg1rh AzbECBo8LZy3Z2DwczFilIBD0BQSByOWp5eWKC2a5cLSdi9hAPcAIlFLQupKiqRFdko4+eWWZK0i qRujE0BOEWkznfyGTsjlNps8BOihbEIF2dq0H0IqF9iDBJPqNVa3wqog9MJe5D99ViEt7kUksDiL XUlGyuM/kFioPcmreoVYQDJJW/VhXik9xj24fEbTssgsRq8o20K85Ng9xJ/Pcr69dEmGe0gflwsu ZltvPlBs3BqOcT5dKx3CyE5NOjAmfUTEaoCQCnmoSWcCvNh78LCETbVpSxhlmMBgcs94Efkh/N0y bc/1/SZg+FHoeuHTt+yVeCFN1UQFGSGumIumTNgFeH9m41hGp+jHUZ0uujccq0uWZ+OcMXmD6d4y DRLXKjsSeSFUYhSHy1Da5EwyWLTkgG2rN8kJ8CW4EXWtwxa+S1r+lGUya/oQJSMvjLpHzvHISxx/ GLhOEh0njpuM3dFx13Vh6HcIqjJpyIBpIp/TcX6x4PTnhQrd2wQ/v9vpxh3XXzoL2AHuZrc2ERqb GJclptXtQCft+KFWMYUUQeL424JweIO2DBWPMIHa1jJ81wtMKrXeNJIe4KJzqa/RNEy29fSMY7ec jAwnz8DgqfVmMZ/cYqb0eQ9lJtSSIHodOSXx7+W2ozD0P0/Or91vq0Lg6VGz8dteNwK3ER463SQY OUdecOz0Do88Jz4OxqPAPT6MvLjx2zUyrwB2oMfdxl1/+vjXd58+/r0Dby1rE1O6Q04KVR6WG5id Lng+sD8Mh73IGyVDZ+gGYyc46sXO4TgKnXHoB8FomByO/OPfYeOVG/RTTmWj4XWmGx4weKdJMc9T XtblVLxIy3lHdTs6VfmO8qqEeAoND7eruyay5+BHPT8J/NA1Thz2JrMbs1s4gmlkpIz/RCoL2hQQ 2gW0HCBSD+zsEq4mFx6OQd0uruEqu4QrkqbQG4EV+sKMwLwaadb4ZgQKNTUFB9MXZiQ0IxDl1FRk RsDHzFheXIIy8Mu2piX7UQ2YK8yrZMfphNyUC/E600iA3zAjMiPw3CAOen4Qgkzex84Kf53plsPG tXFrrS4oN66FdlgjV2eqG9f2Wmt1/N60NoJQ2cjVHnXjWsCrWRvd0cyKHiLAqFkbf2EtoNeslb2R FY2vyoX8vVnb+4JcQLxZ68oc+jOCV4AzvaCWKjTw4lp2MmqkhWxDyFv0EDpz1CksxmkLPOE5mZxB AmtaQFyo5gklJ8WQA/NAp9hELPQtwDGDjgh0Kk8XRQqtGt3wq9IhNvawaZWepjq9lUeC9BXG9Oxk 8Qa6pTK7bnlhaPCA3EvKsdO6bSYNQlB0O9+WG5VJ7RT6agP7+/mvDhMIAmSk5NYEJWoirW9NpDVO bMq6V7UKHU3okdxR8Zzwk4HtB14PD5YX4KZBVY4ZMEXEY+sfVAnv14pqYTAuoQDB3F+p6ZDnhCll TBajGeFWCh8D+9PHP9VoCyqVQDwGVMUmqApnA1SF81moJOM9LNoUHDHAAZXqEg4vCaEAA6+ra7on D8cfd+DwkseynB3CgRhoB+Qv4TCN5BYeXiJLo73B4655eI/myXaIB4Kg8QhaeOgm7R7jscY+0AE+ SmTZIR4IgsYjXOLhdcNYsqkJH95+2ce//9x1V/sAB2Kg4YhacIRuIL3TvsKxLppjgvDkzQNB0HjE LTx6sSuD3zMe2yTCO3RXCILGI1nioXLblfRqv9zV3toHgqDx6LXwSJJINvue7eN/tg8EAV65UhpW /VLMKG8KRaioThVqurZq/8ygqT71ElO4qzLmUQqWVoWnvOpeVnimibH7AmLf9LO+5JI/pXnmD9jT hhLIj/GnKo/REdg3Aq2vSdzES2TS9WxhG6oEmfM8MwhMbEPaHgeqhfjMoA15NCRtsux/VtCGxDYK 42cnLZvbTabZTi4h8Vz+Dwj/T2t+jX7wHwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAJPtGZgaBAAArwwAACIAAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0MTEueG1stFfdjuI2FL6v1Hew0utMfkhCiAZWEKCqNDszWti99yZmsNaJXcew sNVK+1rt4+yT9NiJmR2GqkyH3gRwzvl8zvedc2yu3+wqhrZENpTXQye48h1E6oKXtH4YOu+Xczd1 UKNwXWLGazJ09qRx3ox+/ulaZA0rb/CebxQCjLrJ8NBZKyUyz2uKNalwc8UFqeHdissKK/gpH7xS 4s+AXTEv9P3EqzCtnc5fnuPPVytakCkvNhWpVQsiCcMK4m/WVDQWTZyDJiRpAMZ4Pw1J7QVkC8So JVWMjOtyuXOQsZdbeBM4I6CgWLAS1biChQ9gSgvMkLFHwBhakp0yZo1YSkK0Q739VYqFuJfG+3Z7 LxEtNVqH4njdi87M/KzBDL54R+4PFglnu5WsRtc4A3bQbuiAiHv9BCecQRCoaBeLx9VifXfCtljP Tlh7dgOI4LAp6C/ajJ6nE9p0jkgJDum1PhgwbnjxqUE1h4Q1D22exe3Wourk9T5ijVpNlNbDQVxS UK6VqPNqTQ1N1rsxVNv4DwQlSTiI/JamsB8lvfQpV6Ef9817zVicxkEcxmYTiwSbtNAiU7sJL/ea 6Y/wCYLqohk6BOvkW1jWqIXaM2L0ANZwBinBA4wZ1o1Gavf9AhqtUjkjGBqx006NckaLT0hxREqq 0FvcKCKRoQDaEiCvQRwFtdFBkrq8xxK/O0LWrOIMdoa4bbwmBc3sP+vYe66jrqZ7hguy5qyEUEKd ITSCFew/SaqJO1IU2gJq1tbD+cpGcR8Gi6n/U8ImfjBI9fv/S1ioN8S27KDgK4XWdBudmydCt2Ia ReFhtzRsvaC2FqTgMKYY2RJ2BryR+gXwyzWV56P32lY5m68530i1Pjv46KXwdHUSHebpRVsssi02 xYo86SxDyGs7q1QwVb7AUYjZyul6yswWMyX1ZDVffhyXpp/tkLBDzUyu52NsBcefPr/+SNI8jBN/ 6s7yMHV7kyhw02SWukE6D/KZHwSw9NXpJngJqSpakTl92Ehyt9GH5HnTsOd7ft8Leo/VChFo58uK EltR5pzrefvjwDOF9FpZVkq2uvy+wRJ2sNL8y7x7iTSXZSSxjCwYLQm63VQfj3gx5+NreYErJUCf pMZMnwtXbegnSS+Ox66fRrk7DaOZOxhPQ7c/i+Z5FMzGSdg/VG2jM68hunOL9fu3P3/5/u2vC9Sq OartFRKOhJsGjnxhbnYbSaH9JpNBEubpxJ0E0dyNpoO+O54nsTuPe1GUT9Jx3pt9hcBFEGWFJOa+ +1vZ3bth8dlduaKF5A1fqauCV1576fYE/0yk4NTcuwO/u7xvMZx2YRT0B4MkSm0FQ5RmtthoIQV9 WTZ3BSbfYnG3heGDM/ibAPWfmyUBfwygxLXpo4nO3f7RGP0NAAD//wMAUEsDBBQABgAIAAAAIQAp RKOSFAUAADMSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1srFjbbuM2EH0v 0H8Q1GdFou424ixi2S4KZJOgzn4AI9GxsLqVoh17iwX2t9rP2S/pDCXaVuJ0Ha9eEpseHs71zJCX HzZ5pq0Zr9OyGOnkwtI1VsRlkhZPI/3Tw8wIda0WtEhoVhZspG9ZrX+4+vWXy2pYZ8kN3ZYroQFG UQ/pSF8KUQ1Ns46XLKf1RVmxAn5blDynAr7yJzPh9Bmw88y0Lcs3c5oWerufn7K/XCzSmE3KeJWz QjQgnGVUgP71Mq1qhVadglZxVgOM3N1VSWwrsLZK44eNrkkxvoYFol+B5fE8S7SC5rBwn8ZixZn2 nIqlFtEK9ZAydfXAGUPpYv07r+bVPZdbb9f3XEsThGohdLP9oRWTXwsQgw/mi+1PCokONwueX13S IXhE24x0CNwW/8ImOmQbocXNYrxfjZd3R2Tj5fSItKkOAA12h0LMq8ai1+bYypyHVGRMIzurGlEK W2/K+HOtFSXYieY35sW3awWGNiN8tdQa9wuEauWaH6U/lHwtfaoU3XmCBAPbDiFvwXI3hCyzXnjF c0PfhUUNfeP5fuCE8hCFBIc00NVQbMZlskWXPsJ/iBwt4mUJmfqIO+gwq8VcbDOIM3xeZwQ00mj2 BKWUQRbQYcIWf8JS/WWkQ77DkY/K8p08BLmLAy6mQ3AE/IGtGcVKZIXxaQ6VmIsoYxTgW5PEVZSl 8WdNlBpLUqF9pLVgXJOOg7oFzRBdyDMkJCuSe8opKnWIjLGgQzgZbFc2SzdgPN4OuqOCrsrgPqMx W5ZZAkrY6CIoFhXgs1IAKlCHcoFcVglzXiL4xA4Crwmaqo5OHriEYLKcmghvRj+n/EZWY1okQC34 EUP5uLoF/pS7DnLCgaRoT2yzB2Xho42J1EC5XoBS2il49t6CFqTFc/Z4A+LK5D8JDyWb3AA8BGnx 3D0ecQKCJXaaglgEO0BEaQG9A8AQqvc8QERpAf09ILABKHiWhojSAgYHgIErI3eGyYjSAoZ7QEQ7 PSgdHyJKCzg4APS94MygIMpxTuqXO1zFHQ9Yj4fE4WCG/CxxIF8DYQLxLmm2aDlEUpLsIdJGbK5z aa5ifNUCjjYTz4FW0fSKfYvtkEhoQWtpDlFI/9NMJBsc6yDv4hDSqVHsQG06nMkhpMNJCNLinckh pJOuPXDIoGcK6eD1wCAdvB4IpIPXA3908Hqgjw7e2+wBiaRBE9mNLjKtzp9wkDTkgFN3JpxzphhP MdGECtZhIrcPJkrEKx4iTRNE/jlKRJL/1BymZs8OXcgvclJcwF0E7xN/+2Fke741MaaRHRrO2CVG 6E9Dg4QzEk0tQmDpq96O1gmYKtKczdInuL7crYSOVX5KOBzLtAKTOHu3gwa4ud/24KugzMoSR9rD BiHnuJ9tEAvBm7j8taIcTlBj5g/mzPeEpl+PBMoj8yxNmHa7yh9f+MXvI13hWg/QR13zg/b5Htfs sta2fN/xvGvDCt3ImNju1BhcT2wjmLqzyCXTa98Odllbo+UFaHdqsn7/9s9v37/920Ouyj6urvRA Pjc13KoqedNe8RTKbzwe+HYUjo0xcWeGOxkExvXM94yZ57huNA6vI2f6FRSviDuMOZNvDn8k7dsH LL56r8jTmJd1uRAXcZmbzcOHWZXPjFdlKt8+iNU+oKwp8KrjE28QOsRqbrNSN3mhU9qCCfhyIWer jH+k1d1akjA81UD+R3KpgscZiCOK7kXQdvXYc/UfAAAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4A AAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc4SP wQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB 3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOv Ipo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33ku alneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhABSl6A6vBAAAGxEAACEAAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMWNtu4zYQfS/QfyDUZ63uFxuJF5YdFQWy2aDOfgAj0bGw 1KUU7bVbLLC/1X7OfklnSNF2sl4kWKSFX2yJGo7OzOGQZ3TxdltzsmGir9rm0vLeuBZhTdGWVfNw aX24y+3UIr2kTUl527BLa8d66+3k558uunHPy2u6a9eSgI+mH9NLayVlN3acvlixmvZv2o418GzZ ippKuBUPTinoJ/Bdc8d33dipadVYw3zxkvntclkVbN4W65o1UjsRjFMJ+PtV1fXGW/cSb51gPbhR sx9DkrsOopWV5MwiykxsYMCzJhB5seAlaWgNA3doQRa8Kpl61Hd3gjE0aja/im7R3Qo142ZzK0hV oodhpuUMDwYzdduAGVw4T6Y/GE90vF2KenJBx5AIsr20gK8d/sIkOmZbSQo9WBxGi9X7E7bF6uqE tWNeAAj2LwWqOx3Rt+H4JhydCG8flTalMPW6LT72pGkhTgxfh1fcbIwzjBnddyuis15IobwNpvq5 SomZ0qu0Gqz7ZMRplLo6I74XuKEfPc5LkiR+iAaYHS9MXFdbHEetXXdjuc3acodZvYd/xQod814u 5I4zlW3ICR0DcvgBbjnFimGN/WEBFVPLGWcUKmpgRk5mvCo+EtkSVlaSvKO9ZIJItXp6dHkBICQw P7hkTXlLBf39iWdMHh3DmyEdBiFcan6+z1JgWFqs7/U7/dcgql/fa6JgZcOyM9y+nDAvSLx4YCxI 0xj2hMeMxUCXolQxlkQ+Wusk6EJQwev1Y/JxkjGkiW+4BwuH1FRcq8qpmhKqX11S/gBswcqDKgYH 6xvY7RTLJVsCCTjYt1DlecW5usEtjs24IBvKYaPY4s4ADFaN1CNJ5O6hqv0QjRV7R36AS+MfLgd8 6Acu/QPUMEowM+T88CLIAW9wwDvyQlVm54cXQQ54wwPe/TI8P8CIcgAcHQFO/VSVxfkBRpQD4PgA 2PdTqNyzXMKIcgCcHAFOwuBMaw5RDoDTA2BEe6ZFhygHwKMjwHGUqL3//NYwolRbtTnvEf0rHPdw Xv5fJ35oTvw5lYzcclqwVctL0BzBa5z8pQSR8ydIbMqXcC6p018fzKhcVfbwYqESifpECaiDZjl5 Rh9U1RL0NYrlv9LpbJ4Fs5mdj1LfDt18ZKfzeWxns9lommd5GGbzz9agG0sIVVY100fx86JMg0LZ FbiOmzhecBBhgABJ/44MI2UlpFHYPyLIIkNP3rYoBI8JCl+DoCUoGcXQH2sq4A2GpGc0GlDwYpL+ q9zEJjeqqyI36/r+SYaUrIc2zPQQP9RlQPsKrk8mSYlj1XC83kqe5ml6NUpTO8/c0J5m4ZWdXUVT OxrlfuhP8yRPpvuV3GM/2QA6XIPPL2Q5+frl71++fvnnpetXK+iTbYQS1KaHhYbyuoeupFOt5VpU UJJZNor9WZrZmRfmdjgfJfY0jyM7j4IwnGVQscHVZwDeeeG4EEz11r+VQ48Pg9/05XVViLZvl/JN 0daObvCdrv3ERNeCnIYe33OHDwVKa3uJnwaRF6ax6gQUNtUQGbQQAnboCLvg4h3t3m/U+QOfJKAS QIbDUAcfITALj0wwdvNRY/IvAAAA//8DAFBLAwQUAAYACAAAACEA6HyNJ7QDAACYCwAAIQAAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbKxWXW7bOBB+X2DvQKjPin6tKELswpatxQJp EqzTAzAUFWlLiVqSVu0WBXqt3eP0JDukJHeTegGn9otsUTMfZ74Zfpzrt9uaoY4KWfFmankXroVo Q3heNU9T6/1DZscWkgo3OWa8oVNrR6X1dvbrL9dtIll+g3d8oxBgNDLBU6tUqk0cR5KS1lhe8JY2 8K3gosYKXsWTkwv8EbBr5viuGzk1rhpr8BfH+POiqAhdcrKpaaN6EEEZVhC/LKtWjmjtMWitoBJg jPfzkNSuhWz5458WMkaig1fPmkHeZM1y1OAaFh4qxSgCdlDKGwVIxkC2D4JSbdp0v4l23d4L43fb 3QtU5Rpn8Lec4cNgZl4bMIM/zgv3pxEJJ9tC1LNrnAAZaDu1oGY7/QQnnNCtQqRfJN9XSXl3wJaU qwPWzrgBRLDfFMrd9hn9mI4/ptPT4e2z6k0xuN5w8kGihkOeOv0+PXLbjWA6Zw3flqhnXmlmB7v+ o+FjtJfAqSFLbRc83+nEH+HXLOKESbVWO0YNIRA2TgAcHkA/w7qxaWO/X0Nj1yplFEPjD+SpWcoq 8gEpjmheKfQOS0UFMsHAMQDIa2BHQXEGSNrk91jgP14g6/xwAjtD0GOE8Len8P+JDEYih25C9wwT WnKWQxD+abRWOTTFyPwZGIUCINaxPXUnMqzb1hAsnzHcs2iohMe4pUnjFUVdU8LhjDLaUXYEvGH6 FfAPZSWORw90HV+BnvGNUOXRwYevha+Kg+igJGft7XDs7SVW9FljG0JAVkc1+Cm9yBUc50+g+ZgV FoisbnZzqI1saHE5ST8KkHyt3J+jOPUnkbu0V6kf28Ei9Ow4WsW2F2deunI9D5a+WIOI5ZCqqmqa VU8bQe82+nqAyr8Qi0MyFLiOe+l4wfduhQi083mLMhmLknGuhe6/emMa6dSyFEr0dflrgwXsMJbm jEJ0XkaikZE1q3KKbjf14wteJqfpcH+9wewE0AepMepz5q713SgKJpO57cZhai/9cGVfzZe+fbkK szT0VvPIv9x3rdSZNxDdsc367evfb759/ecMvWruyHF4givhRsJd25qZZiMqOH6LxVXkp/HCXnhh ZofLq0t7nkUTO5sEYZgu4nkarL5A4K0XJkRQM9j9ng8DJiz+MBTWFRFc8kJdEF47/XTptPwjFS2v zIDpucOU2mG47QLfd4PY9/fiAlEabRmjhRT0gKjDJky8w+1dB+KDE5iHof9Ts9TCBKxHhGcmOvdx op79CwAA//8DAFBLAwQUAAYACAAAACEAjsqTrM0DAADPCwAAIgAAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxMC54bWysVttu2zgQfV9g/4HQPiu6WlaE2IUt24sF0iSo3b6zFB0TpUQtSbt2 FwX6W7uf0y/ZISWmTeoCTuMX2aJmDs+cGQ7n6tW+5mhHpWKiGXnRRegh2hBRseZ+5L1dLfzcQ0rj psJcNHTkHajyXo1//+2qLRSvrvFBbDUCjEYVeORttG6LIFBkQ2usLkRLG/i2FrLGGl7lfVBJ/BGw ax7EYZgFNWaN1/vLU/zFes0InQmyrWmjOxBJOdbAX21YqxxaewpaK6kCGOv9mJI+tBAtCKNXew9Z O7mDlcgbQ+hkySvU4BoWVkxzikAg9A6MGcEcreheWzPVriSlxqHZ/SnbZXsnrffN7k4iVhm0HsUL +g+9mX1twAz+BE/c7x0SLvZrWY+vcAGqoP3Ig+QdzBOccAEkEOkWybdVsrk9Yks28yPWgdsAGDxs Cnlvu4h+DCd24XSiRA9RdaYYXK8F+aBQIyBOE34XHrnZOTATs4FvN6hLgTb69nbdR6uHs1egqRVL 76eiOpjA38OvXcQFV3qpD5xaQYA2LgAcHiA/x6bCaeO/XUKF17rkFMMJ6MXT45Iz8gFpgWjFNHqN laYSWTJwHgDyCtTRkJwekjbVHZb4zRNkEx8uYGcg7RjC307CnwuZOCEf1RS645jQjeAVUInPIa6R ykNCMjgEXbV7UJdQNC4zz1HctBFAodiQNuyO6Q/pQnzHH4R+YT5Mkdt0qEf56DS3wsPDbWmDekYJ LCkRcK453VF+ArzNyDPgVxsmT0dPOkVP1mshtlJvTiafPheerY+iQ98560lI3UmYYU0fHQArCLRi 1zt+qbtUGg7/J7gqMF+70rctwDYZ04pe1G3WcE2YPv9PlpfxIAtn/ryMcz+ZppGfZ/Pcj/JFVM7D KIKlz17f8ioIVbOaLtj9VtLbrblMTmtaSRiEwyBKvlUrMDDO503KwCVlIYRpi9/3JVtIL03LWssu L39vsYQdXGp+pS39pBGdV5HMKbLkrKLoZlu/f6LL4Bz9GkYugD4qje0+Z67aOMyyZDCY+GGelv4s Tuf+5WQW+8N5uijTaD7J4uFD1SoTeQPsTi3Wr1/+/ePrl//OUKv2RnWjFlwJ1wpu5tZOQFvJ4PhN p5dZXOZTfxqlCz+dXQ79ySIb+ItBkqblNJ+UyfwzEG+jtCCS2nnwr6qfS2Hxh1myZkQKJdb6gog6 6IbSoBUfqWwFs3NpFPbD7Q7DbZcM4ySJhvFlbsoA+AJL92vZwpIZKg1twuVr3N7uoPngAsZoqP/S LrUwOHfe35mY2N0gPv4fAAD//wMAUEsDBBQABgAIAAAAIQAhPX1U8gQAAGMRAAAhAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szFjbbttGEH0v0H8g2GeGF1EkRVgKTFlqAziOUTkf sCZXFpHlpcu1IrUIkN9qPydf0jNLUpIdF1Ftw/CLTe3Ozpw5M7M7uydvN4Uw1lw2eVWOTfeNYxq8 TKssL2/G5seruRWZRqNYmTFRlXxsbnljvp38/NNJHTciO2fb6lYZ0FE2MRubK6Xq2LabdMUL1ryp al5iblnJgin8lDd2Jtln6C6E7TlOYBcsL81uvTxmfbVc5ik/q9LbgpeqVSK5YAr4m1VeN722+hht teQN1OjVdyGpbQ1vG57+xllmGlpQrjHkmhP4ni5EZpSswMCCp2TcIEEu9WxTX0nOSa5c/yrrRX0p 9aKL9aU08oyUdItNu5voxPTPEmL4sO8tv+k1sXizlMXkhMVgw9iMTQRtS3+xiMV8o4y0HUz3o+nq wwOy6Wr2gLTdGwCCnVHEu249+t4dr3fnKleCG+7Oq1aUYel5lX5qjLKCn+R+6156se6Vkc+kvl4Z LfWKVHVy7aTmo5dvNKc90B0ToecN3IGmw/edYOTcIyUMQ8/HoEHUuIPAc8KhNtJrgpFWdR2rTVJl W6L0Gv8ROVamqwpZqmgFi0WjFmorEGd8r4ULRAYTNygjgSxgccaXv2Oo+XNswiRsXuvApwwMMCE6 s91KhPuuRpDNYlCCP1AiGNUjL62PC9RjoaaCMxjqvFOTqcjTT4aqDJ7lynjPGsWloSlE9QIjaVfa hlbJy+ySSUbwDjVTVFgMy2Ch914TQpH57/CD77YUrij3LgVL+aoSKAbDIydRLX2cH5UJxL6JskFO 94nzqITwRk4QIjl08PoquZsQQ8dxo7CLTFtkxyTEdavzoYQomDzXBZqXGXYa+qSYXt9eYDvVSA7S BFtiO91UIs/muRAkq3dTPhXSWDOB7NvQFoRw5qVqR0LA1pmA4O2EdSgP9GCutaQndlmnU9ej1G2R +sMQKED3EXDd6AXhEkZyG8gHe7gjF2V+LNzgBeESxg6uv4frDkKXUBxHL3mmE+AFsoFAdniHB3gj L6Igvz68BLLDG+zxel4Eel8jXgLZ4Q0P8Ib+4Phye8l8IJAd3miPl8AeX28viZdAdnhHB3iDYfg6 641AtjvxQRehz3xCj01ud7hrtx7fA9BBp1uA5k4P8Jhz3u/P+TOm+J1zXh+qTz3nM4XWBs3Sioll f963xxo1wpou+lho5to2TXcXfafS92n6VO3PYv1D87pEx06991/+6WgWJqORFU4Hc8tPpgMrCZPI CmfuPJqiJUw8/4vZtaEZXFV5wdsz98dhADhtUk0Gju2EtjvY0w4ElKLP23wN+6DMq4qavsP2y6e+ 5KlhWSrZxuWPWyZhoQ/ND3oxbfnI0DwvI0HPyAJNFDcubovre7zolv+pvOD6C9UPUqPbXjSOz5m1 I/d07iX+mRUkrmf5szNczcMksbxkOJzOpkkQuO4uaxvyvAQ6yrf/k7Tfvv79y7ev/zxDzuq+ub8G YxM6b3D/qPXt9FbmKMMkGQXeNEqsxPVRhmej0DqdB0NrPhz4/jSJTqeD2Rc4ULt+nEqu7+jvsu6t AIPf3e+LPJVVUy3Vm7Qq7PahwK6rz1zWFXplvBW4TvfgoBtp18VlceRHvt69gBco9dWnR4shuufr EhLyPas/rPVmjKcN1AEacgzVeMxAqpPoXoR87x9HJv8CAAD//wMAUEsDBBQABgAIAAAAIQBQpSvU 2gUAADkcAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1s7FndbqNGFL6v1HdA 9Jo1/2ArziomdlUpm0SN9wEmMI7pAkOHseO0Wmlfq32cfZKeMzA2/tslTi5Wam5sjD8+zs+cj8OZ s/erPNOWlFcpK4a69c7UNVrELEmLh6H+cToxQl2rBCkSkrGCDvUnWunvz3/+6awcVFlyRZ7YQmjA UVQDMtTnQpSDXq+K5zQn1TtW0gL+mzGeEwE/+UMv4eQRuPOsZ5um38tJWujN9bzL9Ww2S2N6yeJF TgtRk3CaEQH2V/O0rBRb2YWt5LQCGnn1tkniqQRvxSObrqaP7Ob+D12TYL6E05Z+Dv7Hd1miFSSH ExHLS8LTihXyn6qcckoRUyx/5eVdecvlBdfLW66lCRI0F+q95o8GJn8WAIOD3s7lD4qJDFYznp+f kQFEQ1sNdUjaE37CRWRAV0KL65Px5mw8vzmAjefjA+ieugFYsL4p5LusPdp3x1buTFORUc1ae1VD CVx6xeJPlVYw8BPdr92Lr5eKDH1G+nKuNaFHqgZX/ynjofAVxFQGS6xGLHlCx+/hW54kg6wSd+Ip gxTA8TKzZALIIKGz3+vQtk6Dt204OEkGYAp8QLIygnVAC+PjHdRBLqKMEqiTJtTiPMrS+JMmmEaT VGgfSCUo14SMQoUGnAG7gFQ2lLRIbgknYMQWM0aDDODO4KLyBw7rgB8Pu7MOO+b8NiMxnbMsAQvs 18gAxlOH5QprSSXsSCIwWjtL0vUCKHC5Li3P8SzLQZM2q9M1XdMKQVxwjfpOP/ClzRCGmki6Xy8J FRGVYY0U8ZyBWtzXlO3sNcnWcsKvZF2kRQIFjod49/vFNaiYNKReC1r111C3XbT0XrnZWhvy0IbV 0xAqrzqxmvusSIV2gJnOhrVvudKCLqxWuM+KVA2ru2G1nMDyEdyJViK3Q4BcDa3Xog3tUNpwKi1y NbT+hta2QzDhBdYiV0MbtGgD15Hr8FRrkauhDTe0yNk9ZQdii1wNbb9F63vBi1KGXFJL2jUhFQ1v AqtuLV3y7qcrHAqOFLhqS+FOUTFXqVjECgG1uiVkUjXgUaseFM98lGB1z0k2a2Sslhh8rMow4UH7 eYIJOS5jthW4YeB9Q8acvmdBcSCii45JGWonau9JtVGnmrIFgEMlJm0lwxJaYxUAsEoiWlipJGus AgBW1X0bi6tyjVUAwKpiPopVAMCqCj2KVQDAqrI7ilUAwKpaOopVAMDWBaI6ARlfKZJr336MCpLN AHyoopXP32e0JXc0ZkWiZXRJswMFuksv6+IZ9NN5yruzN0/+zoozYQsu5p2Nd+uK7E6fzg6yQ2/y qt2Zp3RtutudSYtPF7W6P667MxS4PxeEQ9vZaJyMtmyVO2uc73qmDeZCJ3asV7MCUL63Xm2ov/Vq 0C+/9WpD3fk/9mq+0rRDvZpsjU6XtX0pkzp5spQd69c2UvbWr2HMt/uft37tyEznm288uw3VW7+G I7T6bXA3Nj9qvxYobbskgm69hPrYYZ4ubHW/lggYIG6/jlr1O9XR91F5193pF5zcDCzlD/l+P4NZ NE6W//bDyPZ889IYR3ZoOCPXMkJ/HBpWOLGisQmDuJH7WW+GrAm4KtKcTtKHBac3C6Eje5exgGP2 zKBnOZu3C7AAL37dJhoGhPWEfcIYjlbbQ87gNdIyE9A47z96rO9MPJ+TmteNSF9F5C5LE6pdL/L7 nbjIAcRLlyts7gD1wdB8Z4rynNCsV61t+r7jeReGGbqRcWm7Y6N/cWkbwdidRK41vvDtYL1qK/S8 AOu6LtavX/755euXf19hrcqxtNrcgUfCVQXT/VLuuSx4CuU3GvV9OwpHxshyJ4Z72Q+Mi4nvGRPP cd1oFF5EzvgzGF5a7iDmVO48/ZY0O2Bwcm/XKk9jzio2E+9ilvfq7a9eyR4pL1kqd8Ass9lGWxKY 79lu6Ie26zpKXMBKubGgrAUXcOdKKlrGP5DyZglaTQawYQcVFslTJWzRQR4RuoGg72rL7/w/AAAA //8DAFBLAwQUAAYACAAAACEABbEKrnsEAABqEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQ0LnhtbOxYXW7jNhB+L9A7EOqzoh9LsizEXtiyXRTIJsHaewBGomN1KVElaSfeYoG9Vnuc PUmHlOgkjrO2mzzmJZGpj8OZb344mvMP9yVFa8JFwaq+5Z25FiJVxvKiuu1bn+dTO7aQkLjKMWUV 6VsbIqwPg19/Oa8TQfMLvGEriUBGJRLct5ZS1onjiGxJSizOWE0qeLdgvMQSfvJbJ+f4DmSX1PFd N3JKXFRWu58fs58tFkVGxixblaSSjRBOKJagv1gWtTDS6mOk1ZwIEKN3P1VJbmqwVt6xq5s/LaRx fA0rnjUA07MZzVGFS1iY3zGUskqCGP1K1HNOiAJV6995Pauvud5xub7mqMiVhHan5bQvWpj+WQEM Hpyd7bdGEk7uF7wcnOMEmED3fQsctlF/YRNOyL1EWbOYPaxmy6s92Gw52YN2zAGgwfZQ8HXdWPTc HN+YMy8kJcjbWtVAMWy9YNkXgSoGdirzG/Oyy7URpmxW4uslamlXolpc81LzYfACONVkyfsRyzfK 8Bv4rxdxQoWcyQ0lmhBQGycgHP4A/RSrqCaV/XkGUV3KlBIMUd+SJwcpLbIvSDJE8kKij1hIwpHU dgkl8hzYkeCcViSp8mvM8acdyco+nMDJoLTREB4bCl8msmOIbKMJXVOckSWjOSjhv45W8RWyAdOF BREI4WF88AK3iq6dKAvCLuSrDjUvcl31rPk1ARe4nRjWLaTCLgj9sBd1tAONJE1A42bDyV6vqbPp mno6bXCSk4WiV+nvx82hwO0jADz6e7DBY6wBALazB+s+xhoAYIPnWO+JDgYA2PAQ1gAAGx3CGgBg u4ewBgDY+BDWAADbO4RtAIrrNp2UY3Q2wU4EErZp88rsUhGkk0s8ya4mg3aP1IF7QkLPSMaqHFGy JvQI8TrLThA/Xxb8eOk6IU6QPmUrLpdHKx80GXm0O6bFYq90uEXetK4FP6trmhO4T81lcOJ1sVPX tP/0VaEqjX54fGfsq2tREL8XNrgR3gtb8l7Yto3Qe2E7omELTWEbY0medGu6FP//qtY0wbmEHnWn b9MOernAndIUL+ALRn2O/B3FqR9G7tiepH5sd0aBZ8fRJLa9eOqlE9fzYOmb1XbmOZgqi5JMi9sV J1cr9c0DV9pOB7yvt+64jtt1vM7DNQwaqM1ve9tExilTxlT3/riJDl/XRDduWUje+OWvFeZwgmmp D/TUp7jmbRnpGkZmtMgJulyVNzu8RG/BC0wDQPReag5cy6dQs41a342iThgObTcOUnvsBxO7Nxz7 dncSTNPAmwwjv7uNWqEsr0C7Y4P1x/d/fvvx/d83iFVdR8xEAHrdCwEfkLX+UF/xAtJvNOpFfhqP 7JEXTO1g3Ovaw2kU2tOwEwTpKB6mnck3ULz2giTjRI8q/sjbkQksPhtzlEXGmWALeZax0mnmJU7N 7givWaFHJp7bzl3WGNp4z4/csBdEnnETaKmbJ6MtmKDmHUrtjPKPuL5aQ3eFE5jwQPyneqmGmQ74 UUEfIMp2MyMa/AcAAP//AwBQSwMEFAAGAAgAAAAhAHQa8ezFBQAAhBMAACEAAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0OC54bWzMWN1u2zYYvR+wdxC0a9Wi/iwLSYraiYcBaRLM6QMwEh2r kUSNot1kRYG+1vY4fZIdUqJjO05sN7nYjS3Th0ff//eRR+/vy8JaMNHkvDq2yTvXtliV8iyvbo/t T9djJ7atRtIqowWv2LH9wBr7/cmvvxzVSVNk5/SBz6UFjqpJ6LE9k7JOer0mnbGSNu94zSr8N+Wi pBI/xW0vE/QLuMui57lu1CtpXtndfrHPfj6d5ik75em8ZJVsSQQrqIT8zSyvG8NW78NWC9aARu9e F0k+1NCW33y+vrctDRMLLBD7BJqnkyKzKlpiYcQrCQbrSy5n1ojWSg6NaeprwZhCV4vfRT2pr4Te erG4ElaeKaqOwu51f3Qw/bMCDA+9je23hokm91NRnhzRBBax7o9tOO5BfWITTdi9tNJ2MX1cTWeX W7Dp7GwLumdeAAmWL4XP61ajp+p4Rp3rXBbMIkutWijF1nOe3jVWxaGnUr9VL71YGDKls6KvZ1Zr fqmoOlz7p7aHwTfapkbQpSWCsI/Y0ubw+r4bbtjEd93YJ75tKcsQEnkdYlXjlrlO5P2QZw/Kojf4 huNolc44AvWmtXPRyIl8KOBmmhSLgkAgixa3yKQCQUCTjE3/xFLz97ENkSDTjVF8iYeP8bzCAwvT BHbAB7YWVCUiq5xPEyRiKUcFo6DvdJInoyJP7yzJLZbl0vpIG8mEpe2GtIVkil3qd2hKVmVXVFAl 1CqzcgVN8GbY1+iMx9bbz/scRlzPgquCpmzGiwxCeK+LgDxD/Jog2d/5ftgPlUNVMmzzfkgIAaL1 fhiHPkEotOq3CaXVbuPQWMJ4X6fWqqs6l2942lfR11KuAPDodfG6GhXxKtYAgPW3YINVrAEAG2zB qmhbymAAwIa7sAYAbLQLawDA9ndhDQDYeBfWAIAd7MK2gG05hJ0WGJbJ8sqcUjVVp1SzllNt3ujk wYd5pQ7cA9J4wlJeZVbBFqzYg17n1gH017Nc7M+uE+IA9jGfC3S/fYUPVGAeQp9Pt7Kjzb1pNQtM NbtWrl4tZdogaPumVf1UM1MdBCUcrWBGi6mNGQAFTjtSNzVVcvTDREe8Kr5q6aXuRgI/JG2eP7b8 tfYWRAPiRq8ucFZJxbkeMfIqw7SjHpVoN/MLDIXamys1jazVKdUTFRaZqMpbR2V69F58a/V0o0Z2 fAMSqLdae/Gt1caNOtrxEb9Pon0JBy/UWsMXe7Eq9XsJuMa3UY87Ps+LId7P8G3UbMPXD3TbOly+ jbre8SmyvR2ypu9G7Td8Udj/OX/8P/oDMttME3rAUGPu83NVaCrRKZVsrRLp2vnaSpTJJ3WItNOC Om1sLUTI8UcNts5Dugro2XWKw5E64HyN4pEXRu6pczbyYscfBsSJo7PYIfGYjM5cTF7D4JvdzfoZ VJV5ycb57Vywy7nUFWafEdh3e26/R/zHvgkJVMl52/YQGaeMOVdD9mqDCFVLe61bplK0fvlrTgXe 0LUIsmMIPsQ1b2uRvrHIpMgzZl3My5sNu0RvYRfcM4B6q2l2tM9DTLOMWm8UDcl4HDn+YDhwAncc OvEw6ju+P4r8MPjgnwbjZdQ2SvMK0ql4U8F6Ny/zkn/OdbdcPWI9PbypbsjoeTUUd+qkgwOZzKvu Jyr7DCc/3JRczasUDbcbKOXJj+///Pbj+78vBfvzMmS5kPo+QInbcAg/zotC/1BXNmxUCGtBMTLT NEWf97VazYzCu3oZJ6dlr9OXPGqHPjuukGEifoyz5w+Wug6aOxJMXOcNzqm1vrqYC9jv63A4iLxR PHSGJBg7wemg73wYR6EzDv0gGA3jDyP/7BskrEmQpILpS5w/su4yCYtPLoDKPBW84VP5LuVlr71J 6tX8CxM1z/VlEnG7GymtLfFI7HmuT3R6Q15IqYc0Iy2W1FWQTv1CfKT15QLWoAnuvpC/MA2WavgQ caigjxClu7k9O/kPAAD//wMAUEsDBBQABgAIAAAAIQDDf/CLQAMAALsIAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDYueG1srFbtbtMwFP2PxDtY4XeWj6ZpGq1FbdoipLFNdHsA47ht hGMb2y0tCGmvBY+zJ+HaSbYxhlSJ/snHzb3X95x77Jvzt/uaoR1VuhJ85EVnoYcoJ6Ks+Hrk3d4s /MxD2mBeYiY4HXkHqr2349evzmWuWXmBD2JrEOTgOscjb2OMzINAkw2tsT4TknL4thKqxgZe1Too Ff4KuWsWxGGYBjWuuNfGq2PixWpVEToTZFtTbpokijJsoH69qaTussljsklFNaRx0X+WZA4S0JrK MHrF2cFDzlXtwBh5Y0BPlqxEHNdguLFeyLnZL1reKErtE9+9U3Ipr5ULuNxdK1SVNkEb6AXth9bN vXJwg4fgWfi6y4Tz/UrV43OcAxdoP/KgZQd7hSCc071BpDGSRyvZXL3gSzbzF7yDbgGo4GFRi6pB 9DecuIPT8BA9oGpcMYReCPJZIy4Ap4XfwCOXuy6ZxWzTyw16Qnzr13x0fHT+Gjh1ZJn9VJQHC/wT 3J0R50ybpTkw6giBsnEOyeEC9DNsdU25f7sEXdemYBSD7lvyzLhgFfmMjEC0rAz6gLWhCjkVwC6A lOfAjoHmtCkpL6+xwh+fZbb4cA4rQ9FdhfDYUPhvInsdkTNsKLpmmNCNYCVUEJ+C09IA5G+wLTBb eSBEUEnkgDtqbQP+i+MV7Aer7u9pVsT9NJz58yLO/N40ifwsnWd+lC2iYh5GEZh+eG2jS4Bqqpou qvVW0aut8Y5tVS8MwkEQ9R5bAhXY4NM2JemashDCiuFpW3qnaMvKqKYvX7ZYwQpda7ptcgL5n5aR fsfIklUlRZfb+tMzXpJT8ALjBVK/SI3bDidWbRymaa/fn/hhlhT+LE7m/nAyi/3BPFkUSTSfpPHg QbXaIudQ3bFivb/7+eb+7tcJtOrOkW7AwGl/oeE8ku7c36oKtt90OkzjIpv60yhZ+MlsOPAni7Tv L/q9JCmm2aTozX9A4TJKcqKom33vy3YGg/GvuVlXRAktVuaMiDpoBnAgxVeqpKjcDI7CdpDvMLOH SpYMong4zKwMoF6osru7asFkp6ctmzD1AcurHRw+OIdfBtB/4UwSfhKa6CcuFnv30zH+DQAA//8D AFBLAwQUAAYACAAAACEASZSwig0DAABpBwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ3LnhtbKxVbW6bQBD9X6l3QPQ34dMYI9uRwVBVShOrTg6wgSVGgd3t7tq1W0XKtdrj5CQdFjZp k1SKVP+xYZiZnffe7Mz0dN82xg5zUVMyM90TxzQwKWhZk5uZeXWZW5FpCIlIiRpK8Mw8YGGezt+/ m7JYNOUZOtCtNCAHETGamRspWWzbotjgFokTyjCBbxXlLZLwym/skqNvkLttbM9xQrtFNTGHeP6W eFpVdYGXtNi2mMg+CccNklC/2NRM6GzsLdkYxwLSqOi/S5IHBmivG0RuTUO58R0YXHMOyIt1UxoE tWBIlEdnFOySY9w9kd1HztZsxZXv+W7FjbrsYocY0x4+DG7qlYAbPNjPwm90JhTvK97OpygGCoz9 zASlDt0vBKEY76VR9MbiyVpsLl7xLTbZK962PgAqeDy0Q9UjegnH03CWSGJj1aACb2hTYm64jwD7 KARZzmhxKwxCAXLHRI+0ON/pvB387iS2MXrqSwmN9x1ERE1lAn8AzlVgFUOds3rQ8QLoVjzKfULL Q8fJNfwrI4obIdfy0GDFFSBCcQUKdqL8CKPUG4XO0spSL7L8JHCtKMwiy41yN80c1wXTnamLAqiy bnFe32w5vthKaAcUcxAY2gAuDCbW1RrqbmXaYAQXapBHzn3Hdsa260+BZwm1qwqUcqRcIY6+PMvR EYRiKBVQakjw2Mvxb1F8LUpOqQQp/pTFO4YsleS9Ll+3iMMJWhotaa/jf0mDj8pIoBlZN3WJjfNt e/2MF/8YvMAwhNSvUqN4V4wcr2s9Jwz90WhhOVGQWksvyKzJYulZ4yzI08DNFqE3fuxa0SEnUN1b m/Xh/ueHh/tfR+hV1bJ6LsKQOhPQ/EyNqy2v4folyST00iixEjfIrWA5GVuLPBxZ+cgPgjSJFqmf 3UHhzA3igmM1qT+Vw8YA44sp39YFp4JW8qSgrd2vC5vRb5gzWquN4TrD2tmhBoaKF0w8LwjHuoOh SnXrdLUAoZv3XdlFwz8jdrGD4YNiWHDQ/6kyMVhpw0h7cumw6xU5/w0AAP//AwBQSwMEFAAGAAgA AAAhABV34QTcBgAAcR0AABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZz27bNhi/D9g7ELq3sR07 jYM6RezY7dqmDWK3Q4+0RFtsKFEg6SS+tk8wbPcdBuwydBuwDjs028tkG9bt0FfYR1KSxZhp3S7Y DksOrUX9vv9/+JG6eeskYeiICEl52gnq12sBImnII5pOO8Gj0eDaZoCkwmmEGU9JJ5gTGdza/vij m3hLxSQhCOhTuYU7QaxUtrW2JkNYxvI6z0gK7yZcJFjBo5iuRQIfA9+ErTVqtY21BNM0QClOgO3D yYSGBI00y2C7YN5n8JgqqRdCJoaaNXEoDDY6rGuEnMseE+gIs04AciJ+PCInKkAMSwUvOkHN/AVr 2zfX8FZOxNQFtBW6gfnL6XKC6LBhZIrpuBRaHzTbN3ZL/gbA1DKu3+/3+vWSnwHgMARLrS5Vns3B Zr1b8KyA7M9l3r1aq9Z08RX+60s6t7vdbqud62KZGpD92VzCb9Y2mjsNB29AFt9awje7O73ehoM3 IIvfWMIPbrQ3mi7egGJG08MltA7oYJBzLyETzu544ZsA36zl8AUKsqHMLi1iwlPlyTXUg0ySNESN QKMS/JSLAUD1A8OKpkjNMzLBIeTzjqCYaUF4i+DKul0K5dKSlolkKGimOsHdDENlLLi9OX3x5vQH 9Ob0+7NnL8+e/XT2/PnZs+8sL4fwDk6nVcI/f3z519enfqCsAl+/+uzXnz/3A6GEFqr89su3f7z6 8vcXXwHF62++8FDsCDyuUlRc4epKxmIV3CjGtIrrcRFRjB6QY4/wvood8IM5ZtiD6xLXUY8FNAwf 8PbsqaPlMBYzRT0c78WJA9zFs3SfpLEPqkVVfDqapVO/bDGr4g4wPvKJ7uHUCWZ/lkGjpD6WvZg4 Wu4znCo8JSlRSL/jh4R4NH5CqePWPRoKLvlEoScUdTH1emREx07qLIju0ATCMvcpCNF2fLP3GHU5 81m9S45cJOR+UXNOoo0Ic9x4G88UTnwsRzhhVYffxyr2KTmci7CK60slQDphHPUjIqWP5qEAeytB v4ehRXnDvsfmiYsUih76eN7HnFeRu/ywF+Mk82GHFHKxIv8Tecg5w2ifKx98j7sFop8hDji9MNyP KXHCfVHdP6JTR5FFWug3M6HTDzqy014Tml71Wk9dXvVas9te9dqrXludn656bT5IrtprF+0VOq/e PO34a4bhxDcLmwl4Qhkbqjkj96UZgiVsENEAFjWdOQeS8myUxfAzb+0ObiqwoUGCq0+piocxzmCA rhsJU5mznkqUcQlHOLPs5a2FwhCu7AGwpY8GtmNKrPZ4ZJfX9XJxAijZmA1nao6ZhaB1zWBVYes3 cqZg9ocIq2ulVpZWN6qZs4UjrTQZYrhsGiyW3oTJA8G8Al7egJO4Fg1HD8xIpP1ut98iLNqrxe9L DlFutTUkxhGxIXKWK96sm9gVKWSuAiClPKF7P2+WXgOnvVsJkxYX58+KTi4YFI41RpyvJpZWa4ul 6LgTtFuNVoBCnHWCCRw54WeSQdCkntUwm8INTqiEzdp31qIp0oXFbX9W1eE+4YKCcco4E1LtYhnb GJpXeahYqiVZ/Rutpk62yzHAJuoHaLG+CSnyn2kBOeKGlkwmJFTVYFdWtO/sY94J+UwRMYyjYzRm M3GAIfzgU21PRCXcHZiC1g9w4aW9bV65vTXvNNVrJoOz65hlMc67pb4wKSrOwk2qljqYp4p6YJtX d2Pc+5uiK/6yTKmm8f/MFL0dwAl/PdIRCOG+VWCk67UTcKFiDl0oi2k4ELDvm94B2QKXpvAanA+3 vuZ/QY70/7bmLA9T1nBkUwd0igSF7UTFgpB9aEsm+97BrJ5vPZYlyxmZjKqoKzOr9pgcETbSPXBD 9+AAxZDqppvkbcDgzuef+5xX0HiqZ5RqvTk9pNw6bQ3824OLLWYw6twsofO38H+povGWO7hYekNe 7JFVQ/SLxZTULKrC2fza7VzUB6qwygZc2Wttx1qyuNEqlIMoLlsMi+U8k8E9DdL/wP5HRcjsJwS9 oY74AfRWBF8ErP8QZPU13dUgg3SDtL/GMPfYRZtMmpV1bT6caq8Vm/UlT0Gl3HPO1pqtEu/3dHY5 RLninFq8TGfnHnZ8bdcudDVE9nyJwtKkOIeYwJhvT9XPQ3z8FAK9C9fvM2Y/GMkMnkwdZPvCZNeY R/P8J5N2w7VZp88wGsnSAzJBNDopzh+lJ2wJ2Y8WxYhs0JpMJ1pJuO47NLiEOV6T2t2yJLZfFt4q taQwkqFll8TmkswnHT5Z5Y1bH+0Ab5ustVoXV+Eplv4Tl62gvN9l3pPPqi6zB8XLdpk6ebvLck+B 85YTDz46CgxHk6Hpv7Dp2Ew3Kbv9NwAAAP//AwBQSwMEFAAGAAgAAAAhANCD0YTUAQAALAQAABEA AABwcHQvdmlld1Byb3BzLnhtbJRTTW/bMAy9D9h/EHRv/YE0S4w4xYZhuxTYgKS7axLjqLAlQVRS J79+lO06TeBDdyPpx8f3SGv12DY1O4JHbU3Js/uUMzDSKm2qkj9vf9wtOMMgjBK1NVDyEyB/XH/+ tHLFUcPrb8+IwGAhSr4PwRVJgnIPjcB768DQt531jQiU+ipRXrwScVMneZrOk0Zow4d+/5F+u9tp Cd+tPDRgQk/ioRaBxONeO3xjcx9hcx6QaLruK0lrMmei7PpPb3Fv/fmb8BvC0goa0epGn0HxCCSS YD2oJ9gFhueS5/nDYsmZOAT7Vb0cMJQ85cl76Na6Drlczh7mE8jkenxsxVor6NXEVG5qNWhDI9zW /vRaxTmsT3/9fQEZkA7aaZQD9kgepKjJQ1/HmKxXosCWxetnpJtosrQTTOXTRJnUDX2usF5X2rC2 5HfL2YyzEwVZlke7BBvGRsHVgfQ/YRhjRq20fLoT7ZYzZ0lsns2HTXXwobhYdEXiu5BE8nEF3ayb BRkbALfQhnc7u4S3vsnvlO/rMs2c8E2dZPpN4eiYwBMS0PoA/qJjhI/U4ylm06e4Lv+vpNv5Ff01 GyckvUkm6Yhf5vQuOZPkqA/7Ox67V7D+BwAA//8DAFBLAwQUAAYACAAAACEAXJxHFE4BAACJAgAA EQAAAHBwdC9wcmVzUHJvcHMueG1stJDNasMwEITvhb6D0V2RZDt2bGIHO3ah0EMO7QMIW04E1g+S 8lNK373CcUtDL7n0tssys9/MenMRY3BixnIlC0AWGARMdqrncl+At9cnuAKBdVT2dFSSFeCdWbAp Hx/WOteGWSYddV66M4E3kjanBTg4p3OEbHdggtqF0kz626CMoM6vZo96Q8/+gRhRiHGCBOUSzHpz j14NA+9Yo7qj8ABXE8PGicQeuLbfbvoet985bpBKH5Jd3It18xQcDS/AR5sm2zaLK5jgaAtjEoew ztoaJg2JUowJrsL0E3gNifOe246a/lnQPWt77hrq6BzVn//gCd4ZZdXgFp0S6JoTaXVmRis+RSV4 7utExwJggMo1mjBvGZuIVDgJK5hmqwrGUZjBqm4aWNfVapkkIV4S/MPIBnoc3cTYaP5feFfMqU0/ /m59Z8ovAAAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAHBwdC90YWJsZVN0eWxl cy54bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/ 4AESujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt 9WZR3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8A AAD//wMAUEsDBBQABgAIAAAAIQC39PEuHAcAAIkfAAATACgAY3VzdG9tWG1sL2l0ZW0yLnhtbCCi JAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0Wdtu2zgQfV+g/yBon2v5Fscx 6hRJnAIB2m7QBIt9KyiKirWVRJWkEufvd0iKFCX5qmS7D60pznAuZ2YOuZ8+b7LUeyaMJzRf+qPB 0PdIjmmU5E9LvxTxx7n/+fITFgtMc0Fy8fhakAe8JhnyYPHn0ve9DNm/nU3fUUaW/oriMgMxtcv5 erda+sPNcAT/DYer29n06vZ2tbq4Pr+ari4mZ9Ozq5vr24vz1XQ2OmvL/m2sHbe/rAjHLCmE8uWG ESSIh7ycvHhRZcegLfKAaQF2quUqDNK2eHoxHI7D8zmZoCk6H4Xz0ZSQeDpDF/PJfDTzPYhbzhdY LP21EMUiCLiKCh9kCWaU01gMMM0CGscJJsF4OJwFGREoQgIFTiCMogz1UVQwsJ6JhHCl/EoIloSl INy//PDHpw2PFtoqTyD2RITMCS8QBodPN7o+SwWLUQq+C1YS9TNOSBpxGbrJPJ5F4TiKhtEFGuJ4 huYRnpyHZDIOJ7Oz0PdyPtaI0TEEM609Ly8vg5fJgLInGbJR8M+3rxptJk4bfvzewm49ITeum9o+ MPeAIr5GjBQ0yUXwPAl0KGwGkqygTHj5kbHfqisw6SQpkeWktC19x1azATBXpGQjy9QscfK7hJq2 v5s6TGV8Qzl6Usqt5Vt0oTQ1ao0aRuKlr1L6IJAoOcAhyf/CuGSQqqHfMb3eXxXyNoFAYrc6TP27 ZYtaqyyQBqnfrqPHC6myNU71KpetKfMq675Qlq1IjMoUyuV3idIE8BHVcP6fsB9ldaEcRn8XBIEA BEEudQkU+EAFVG0uyWNaILGWxXse3CMmcsJuYHIwmtY96cSKcFvoTkMtzPop32+4VW4wL4t56f+0 gEeLJI/IZunPobslaYrCFL7b5hglvEjRqx6JjlBkcPGdCg/WmZDIgHkKnYSwHKVawpxjQQo+psQt 8TKHkedlJAsJk+uQewDA4pFshK1m3pFihMO8wHJceiHiYLEUullTmFhWjOQwwBlSm55RWsIu19o6 NN19K4Zi4TSA7o4f5DkhL+D0PjVyAERlemDXfRmmCYede3V9SSCqe3fcboqEGS2qizhhqltNI5hq m8rBvg1Ou5LdrYWluhlaMF0cBlNTqgEa82k3ahzHnPwr0Kh86Kba9dRxRG/p00KBuOTQXGJoj0hw NfGBmfyCGdQhS4x8dCbdocaKDAlqdN4yd3pvmFL8yzblP2HOVI2u0+X6W9mL2yTWgJ1E6GOSc4Fg nJveHNW9uShZqiIZ4aBKEg9Gg1FQ7wWIOJPBFVBf7E4KndYas32AmCYV0DCy7QLQsp3tuEe1bNPq v1Ksuow9NZIVDXcRRpRPlREBBJYHv8FDmDGTYDgNhuMgwgMoqbquj7LCOPwexytdTRua9S3duLds 3ffkeF36N48/Wx9sI3QIT8X2uptNae9iZRFeYHkLoqzFsWDGbAxFG9VhMyYrihZh5ZTWAA2xSeuO 07BIImCrkvGcaIEesI17UoNVNo+voim7qpxo+VM1RNVIhhstTNTGCJaMRLJoOSp3er8QiUjl5cZl s61z1ahWp0y7pzwqeZvQVnAXvAz/JVjsPWCncFTfdE9ToAP7i7y+UBa1uXrLO41RJ6o7zUlR/lRC 6+5jC1Q9eaLsda9sN8MdW7Rnz/px4H2UMaAn8mHkRG22LPOcwpUIFJgVQ1/Norfjz+M64Z5iWx4Q y0SGiHtiTTygUEDxPBp7HD3DGmWeMZIPvEfYgYoilQKS1IESmPEFzXkChNSDWeuVBbxAQIWANnsE sDTQSRBeW2WDD39sM03fs9pe6FXU8FYRgwryxntTATpTKeLiGzw0yevQ9Zuz32hZWaV2b952AKjq OZal76n+Tn10Gk2lRR2lInLoSqtnkQ7Ym95u9l9o3oFDvefFsLplHvW2U8WmiaV7qHoo0+qbMzpN JBtPIJZ6K9AUeLGq72ctyFxKbJv9raON9BXGtMzFXXtEniCrBlFz0nSkpSGtFw54lG289uy2VZdc w0+DXjMyOwfWjlcExHG0t7D29HTx69XNFecUJ9AKo1vgFOK1d7pBV6WhGXJ3/JV5CEmNgPd04tJO BMTJ3jmggcJrGEBKH/DdPPpVWuy+Ckr29xa5o0UeXrkg2V11LZBHHi1qQgrDYpec9PYgzGo/NNDa 3tvx3QSbFeuEo63GEGZZA5rh6bQc0rAlNj1taYfqSDXNPlUjr/K4FVnp3v5WpSPbKOQGQe2gFVQa G5rYNID5QWLC5Ptwj9anrbmLRm+QHb9BdvIGWcnY3eF+QuSis0Oy7R5xVBWZPLngb2T69LZZJajq DU6qe6uSue4vDMnuLwzZ7i8M6e4vDPk+XfhRPrX0HlJS+g6e01tI6zmjeuDPGtC3VUkFaqqcXmfq 7IN86h2KrLaxX34l6Tsoqey0b6TBtv+ZfvkfAAAA//8DAFBLAwQUAAYACAAAACEA6TPGCncEAABt KQAAKAAAAHBwdC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW7cWcFy0zAQDdzS 4RM4hNxjJaU0HcaEKU07ZCYFD0lhOHWErQaDY3lslRJ+hP/hy1jZkqw4sgkciu1Dp44srXf1VvtW uw87nc4D+Pv1uNOxX35fB71vJE58Gr7oj6xhv0dCl3p+uHrRv1peDE76LycH9pPp27PlR+e8FwV+ wnrO1av57KzXHyB0GkUBQWi6nPac+Wyx7IEMhM7f9Hv9z4xFzxG6u7uzMJ9luXTNJybIiWlEYraZ g7ABLLA85vXhM5n0LXVg1PNdNjno2l/JZgIihLAo9kNmOXhFLmi8xszK/jHQ3OGvSGwjvgIWCgFm Ccx3vxJmuTHBjKo1XTthIGWlffAL/ZTNtZF4d9CtFOkzsj6NY7yRinRtzH+CSrBQKlUiYx/DuBih SvLNfXY9Onw6vn71QdevRLowOmGYkYsAr5SGMJ/v3YrEk6GN5GOqMJIa20iaYcuxP2HjXL6msf+D hgwH70giP6c2wbheKFljZErM4riAOwWT8aGN0ge+gZW+co9IvI19AjgwOPHtwcFgFN9x6cCAg3ys ExQLFwcQZNoDQ8EgdRBGNTwH74GBfACgVfHIYJQCoZbRSCpc8JzmM0OJYQqNmhyJ5PbTMsuAIgw5 2bUf3tDrjHnNYcm5dJypw+eeUY+8wWsi52k5zd/wucph8tzOmGpV8udurqUnW5pmgoYrrOAIiaxq TliaR+b5Hn9pykNFrmKi8ZyFChlVV6VPIFTlVNpo+qVU02WMwyRIOXuR5qUpAI3e/D1Mqh0SS5+u cMO3vsQGba9DPAhq4Ph5ONi56jmXp96X24QRj1+T3hGXNTEG/ZuBHCh5/4Jn+CUz22J4qX6V3kuO h7Aov6HAiuzecrI9rEUn/sH7DYB7bhMQUssdoWghh2LbE1LwBscmSM2jx0Pj5PHJ9nDN8IeNmEGa YjmXZxAE6DqNyO2IANWmccRvcJAQlNaQanAUc30bTYu7MabKMA6DSAlry5W5/lchbiVZ7mVhSYwc WtsEJ3ivZHhcoEMxu0ietY2SugfArrWHJs0uUDSxxAfMjGgeLRKi8oBG8GQUecCVLQ3QZcZpQboO 1/giw4iCwakzg0IR777l+YugluHQOoQoldceqvJutom0OoxYU/xm6gE8c8oqPppsVYmo+saurpIF i6pWSdE1let3FZVdvaKmUlEbpb3CycFD6GT+fNSCTuaUurdraMxkFsN5XUSUBllTU/pGI6ui+xim HVbeKoayPG9Poci70ZyUT/rLq2fZ3Vi6EUhUhTc1ZvxI2lNeQFkE+jUJv3nQgMaLTehCL/vGD8hs 2miQ9jePoyArDqNnPDOSv/53Z413/bcQivymt5orTdpCos4wbOCwQPFaEVQjw9juCYmKdnFAWHwr b+fGOCJ439QoUMeqcKZUYPrnYHXhxwnjpdJWxagdq5pxIOa4hVgUjdKhOBwdjY9Onh4fjWsbpNI2 Ag5bdkB2rOKo6BVjFXGgGb3F4jnFl4OnEicu9b/lZSKe3uPdROfkP15PfgMAAP//AwBQSwMEFAAG AAgAAAAhADgUpS8QAQAAkgEAABMACAFkb2NQcm9wcy9jdXN0b20ueG1sIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnNBBb4MgFMDx+5J9B8Ld8rRSi1EbFZvstkO3u1FsTQSMUFez 7LsP022970ge/PLnJYebHNAsJtNrlWJ/AxgJ1ei2V+cUv52O3h4jY2vV1oNWIsWLMPiQPT8lr5Me xWR7YZAjlEnxxdoxJsQ0FyFrs3Fj5SadnmRt3XE6E911fSO4bq5SKEsCgB1prsZq6Y1/HL578Wz/ S7a6WevM+2kZXW6W/OAL6qTt2xR/clpyToF6QcVKzwe/8NiWRR7sAYIiKI8sr74wGtfLAUaqlu7r pVbWZa/oS+vU2cbD+GHslMENnAEAvNqFeVVxzoooDznb0pDmZVGxiIc7nybk8SYhv1VZQtbc+zKz bwAAAP//AwBQSwMEFAAGAAgAAAAhAN7/iD9+AgAAjwUAABAACAFkb2NQcm9wcy9hcHAueG1sIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFTdb9MwEH9H4n8weYKHNh3rgFauJ+g2 bRJdI5oN8WiSa2MtsY3P6zb+ei5xk7W0QmJ+uo+fz+ffffDTx6pka3CojJ5ER/1BxEBnJld6NYlu 0ovep4ihlzqXpdEwiZ4Ao1Px+hVPnLHgvAJkFELjJCq8t+M4xqyASmKf3Jo8S+Mq6Ul1q9gslyqD M5PdV6B9/H4w+BDDowedQ96zXcAoRByv/UuD5iar88Pb9MlSwoKnUNlSehAX1+cziR5ca7kwLqWE IXGwVvDQt9Y/8rj10k3jZZmqCsTJ8WhEnk7n343LUQxHQx4HkX+2tlSZ9ESmmKnMGTRLz2YyU9ob LFhiHsAlhjQeb2OJTUCipLlJGRFjYq57mDkAzRaFeWBvh+Pjdzw+AOSJdHLlpC1QnJwQ5Fnli1Ll gOIjjzcSvzaeDAMeB4FfqjwHvfGSeUfns9m0VLbBtyJfZLKEKdErlrJEoNCdgV+CrFsnkcqh4Gs/ XkPmjWOoflPzDCP2UyLURZlEa+mU1J6KU8OC0silRe9EUxQeky/ojbgN25bVUBw1ABL+CQyxmt+y VPkS8D+eIBYpnb0namP4Jr29S0B4Yr6kkvgDfNBsPfPRpBbYCFnOm2lhe0R0lCTJImFfiFCWOpnd gWPU9N5kptz+VAefFlKvaFyVZr1BoGtDbQdp77M5rYR6HA4G+ga/7gGprwFRUsSXg87r4a9XDzJa MeyKhpRGcTMHB8Om9Ik79sPcszfb/p0a/MX61FRW6icqTid9VfoOb2xqzuqdsGnjXSNfFNJBTsuq 9T8b+CV1sCvrIIHUvMXsO+qdcBv2qzga9gd0mtlvbfVIt5tU/AEAAP//AwBQSwMEFAAGAAgAAAAh AMpiDPeCAQAAygIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHyST2/UMBDF70h8h8j3rP8EAYqyrkRXe6II0VSg3ix7dmuROJY923T59NjJ bgii4uh5zz/Pm3Fz89J3xTOEaAe3JXzDSAFOD8a645Y8tPvyIykiKmdUNzjYkjNEciPfvmm0r/UQ 4GsYPAS0EItEcrHWfkueEH1NadRP0Ku4SQ6XxMMQeoXpGI7UK/1THYEKxt7THlAZhYpmYOkXIrkg jV6Q/hS6CWA0hQ56cBgp33D6x4sQ+vjqhUlZOXuLZ58yXdpds42excX9Eu1iHMdxM1ZTG6l/Tn/c fb6fopbW5VlpILIxukaLHci97eALjC30vlMIDV2U7NEBFA5B7qxyatKulTzhTkW8S8s4WDCfzvLb yRa34fSrof9q2R7g2eZFSi7E5FkK6akp/fwemCLlqef0V+V7dbtr90QKxlnJ3pVctKKquaiZeMyN /XU/55sL/aW9/xOrkn0oK9ZylomiWhGvADl/KYdpp/eo8BTlLqgDTkH0sK5fSuvfJ38DAAD//wMA UEsDBBQABgAIAAAAIQA7c82rAQEAAOwBAAATACgAY3VzdG9tWG1sL2l0ZW0xLnhtbCCiJAAooCAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc0U1rwzAMBuC/EnxvnLawjZCkh13XMSiM 3YZxlEQQS8ZWmv78OevHdhgb7ObL+7yyVO1ObsyOECIy1WqdFyoDstwi9bWapFs9qF1T+dIH9hAE IWYpQbH0tRpEfKl1tAM4E3OHNnDkTnLLTnPXoQW9KYo77UBMa8ToL0VdmFPEGzTPcz5vcw79Elvr t/3T4dNeIUUxZOGa8vYW+rUdqWNvZFi8e/1ighCERyYJPEbVVC3byQHJ3pDpYXk11fvreRvnAf/o iYMJ4BlJ9HGrO4SxjWnIiCXhWCsJE6QafTWTfhAj02WJ/8GbZ5YsIUGgTfCZSxU/fUV/v1vzAQAA //8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54 bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tc nc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/V FhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90 /m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XH f90LAAD//wMAUEsDBBQABgAIAAAAIQBcliciwwAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0 ZW0yLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BasMwDAbg e6HvYHRfnPYwSonTSxnkNkYLvRpHSUxjy1hKad9+pqcWBjtKQt8vNYd7mNUNM3uKBjZVDQqjo97H 0cD59PWxA8ViY29nimjggQyHdr1qfnC2UpZ48olVUSIbmETSXmt2EwbLFSWMZTJQDlZKmUedrLva EfW2rj91fjWgfTNV1xvIXb8BdXqkkvy/TcPgHR7JLQGj/BGh3cJC4RLm70yJi2zziGLAC4Zna1uV e0G3jX77r/0FAAD//wMAUEsDBBQABgAIAAAAIQCo/JlOFQEAAPMBAAAYACgAY3VzdG9tWG1sL2l0 ZW1Qcm9wczEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKSRzWrD MBCE74W+g9Hdkf+w4xAnpDWG3EppoVchr2KBpTXSOhRK371y00vaW3MSo0XfzI62+3czRmdwXqNt WLpKWARWYq/tqWGvL128ZpEnYXsxooWGWWT73f3dtvebXpDwhA6OBCYKFzqcx7ZhH9VD2WVVWcdV WhdxkaVVXOdtHueHLj8UVZFl6+yTRcHaBoxv2EA0bTj3cgAj/AonsGGo0BlBQboTR6W0hBblbMAS z5Kk5HIO9ubNjGy35Lm8fgblr+USbXb6j4vR0qFHRSuJ5sfgAjZAYtmOTy5EcaTBM34DVFuFk6Bh oVf8STiy4B7RksPxn2Q/CAcT6tDFOedKw9h/k/ivIhZ99VG7LwAAAP//AwBQSwMEFAAGAAgAAAAh AL2EYiOQAAAA2wAAABMAKABjdXN0b21YbWwvaXRlbTMueG1sIKIkACigIAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGyOOw7CMBAFr4LSky3o0OI0gQpR5QLGOIqlrNfyLh/fHgdBgZR6 nmYediS8dRzVRx1K8p3BE2caPKXZqpfNi+Yoh2ZSTXsAcZMnKy0Fl1l41NYxgUw2+8QhKjx28LVp tcFYXdIY7INUXzE9uzvV1Dlcs81lSSH8IB5vQdcnH4IX/1zHC0D4O27eAAAA//8DAFBLAwQUAAYA CAAAACEAOskWrfIAAABPAQAAGAAoAGN1c3RvbVhtbC9pdGVtUHJvcHMzLnhtbCCiJAAooCAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkkM1qwzAQhO+FvIPZuy3FCc0PtoODHci1tNCr kNexwNIaaR1aSt+9Mj2lPS2zw843bHH6sGNyRx8MuRLWmYQEnabOuFsJb6+XdA9JYOU6NZLDEhzB qVo9FV04dopVYPJ4ZbRJXJg4r00JX/tdk9frs0wvl02bbqU8pIetbNK6bWR73sm6zuU3JBHtYkwo YWCejkIEPaBVIaMJXTR78lZxlP4mqO+Nxob0bNGxyKV8FnqOePtuR6iWPr/XL9iHR7lUm735R7FG ewrUc6bJijAojxOZGH7fCE2OI4c/JxRLjQCiKsQfyKIfnlD9AAAA//8DAFBLAwQUAAYACAAAACEA e/MCo8MAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMy54bWwucmVscyCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwWrDMAwG4Hth72B0X5x0MEqJ08so5DZGB7saR3HM YstY6ljffqanFgY9SkLfL/WH37iqHywcKBnomhYUJkdTSN7A5+n4vAPFYtNkV0po4IIMh+Fp03/g aqUu8RIyq6okNrCI5L3W7BaMlhvKmOpkphKt1LJ4na37th71tm1fdbk1YLgz1TgZKOPUgTpdck1+ bNM8B4dv5M4Rk/wTod2ZheJXXN8LZa6yLR7FQBCM19ZLU+8FPfT67r/hDwAA//8DAFBLAwQUAAYA CAAAACEA2jvjCZIBAABNBAAAGAAoAGN1c3RvbVhtbC9pdGVtUHJvcHMyLnhtbCCiJAAooCAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsVNtq3DAQfQ/kH4zeba336oR4Q7IXCDQQ0gTy qsjjXVFLY0bjbErpv0d2UnIFL22fzFjMOWfOGenk9NFW0QOQN+hykSYDEYHTWBi3ycXtzTrORORZ uUJV6CAXDsXp/PDgpPDHhWLlGQkuGGwUfpjwvVjm4tdqPEzH2SSLZ9lkEY+H61l8vppO4+lysJod jY4m60X2W0SB2gUYn4stc30spddbsMonWIMLhyWSVRxK2kgsS6Nhibqx4FgOB4Op1E2gt3e2EvNW z3P3NZT+fdlKa8h8YrFGE3osOdFoXwiegS2waqeTGh0HupufNQj531BrCgMSG/CyZTpjJnPfMPg+ jt1ul+xGnR/BgFTeXX773lnW1/jH2D1GfhX3d6B+qwhqNCGkh5EsDVRF71z98oqX4C+VUxvoVoBD KP+GbFyJteJtG/pMXiliB7QIkRNWeyN/sau10j+Cyk+7RBDv727dUNUlXWgJVTeyl2mSyr5Y3jYy kPW9HV/bHxIEcqqSeF+0nPLDFWvrd0/A/AkAAP//AwBQSwECLQAUAAYACAAAACEArO3o/SECAACc EQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCy ynqBAwEAAOQCAAALAAAAAAAAAAAAAAAAAFoEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAb xECUgwMAAF4KAAAVAAAAAAAAAAAAAAAAAI4HAABwcHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAU AAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAABECwAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAABD DAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAEvH1xIYB AABBCQAAHwAAAAAAAAAAAAAAAABADQAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BL AQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAAsQAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQDnNSpnqQIAAKoHAAAVAAAAAAAAAAAA AAAAAAgRAABwcHQvc2xpZGVzL3NsaWRlNy54bWxQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAAAAAAAAAAAAAADkEwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAU AAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAADhFAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAbJAYbcEAAAA3AQAAIAAAAAAAAAAAAAAAAADe FQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8A AAA3AQAAIAAAAAAAAAAAAAAAAADdFgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHNQ SwECLQAUAAYACAAAACEArUY0ZYACAABxDQAAFAAAAAAAAAAAAAAAAADaFwAAcHB0L3ByZXNlbnRh dGlvbi54bWxQSwECLQAUAAYACAAAACEAR9cpnJkDAAB9CgAAFQAAAAAAAAAAAAAAAACMGgAAcHB0 L3NsaWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAM7XDaOgBQAArCAAABUAAAAAAAAAAAAA AAAAWB4AAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQItABQABgAIAAAAIQCVZYu2WQQAAHYQAAAV AAAAAAAAAAAAAAAAACskAABwcHQvc2xpZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEApJdp WGkFAADVFgAAFQAAAAAAAAAAAAAAAAC3KAAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAG AAgAAAAhAK/q11OoBAAA4hAAABUAAAAAAAAAAAAAAAAAUy4AAHBwdC9zbGlkZXMvc2xpZGU0Lnht bFBLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAC4zAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAAAAAAAAAAAAAADY0AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 Ny54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAD41AABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAEY2AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAA AAAAAE43AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABXOAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAABfOQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABnOgAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS 8b4AAAA3AQAALAAAAAAAAAAAAAAAAABvOwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDMueG1sLnJlbHNQSwECLQAUAAYACAAAACEANM25zh8BAADHBwAALAAAAAAAAAAAAAAAAAB3 PAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAzRhRxusHAADULgAAIQAAAAAAAAAAAAAAAADgPQAAcHB0L3NsaWRlTWFzdGVycy9zbGlk ZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAACkYA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAJPtGZgaBAAArwwAACIAAAAAAAAAAAAAAAAAEkcAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAKUSjkhQFAAAzEgAAIQAAAAAAAAAAAAAAAABsSwAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAAC0AAAAAAAAAAAAAAAAAv1AAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx MS54bWwucmVsc1BLAQItABQABgAIAAAAIQAUpegOrwQAABsRAAAhAAAAAAAAAAAAAAAAAMhRAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEA6HyNJ7QDAACY CwAAIQAAAAAAAAAAAAAAAAC2VgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1sUEsB Ai0AFAAGAAgAAAAhAI7Kk6zNAwAAzwsAACIAAAAAAAAAAAAAAAAAqVoAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEAIT19VPIEAABjEQAAIQAAAAAAAAAA AAAAAAC2XgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgAAAAh AFClK9TaBQAAORwAACEAAAAAAAAAAAAAAAAA52MAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ1LnhtbFBLAQItABQABgAIAAAAIQAFsQquewQAAGoSAAAhAAAAAAAAAAAAAAAAAABqAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEAdBrx7MUFAACEEwAA IQAAAAAAAAAAAAAAAAC6bgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0A FAAGAAgAAAAhAMN/8ItAAwAAuwgAACEAAAAAAAAAAAAAAAAAvnQAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQBJlLCKDQMAAGkHAAAhAAAAAAAAAAAAAAAA AD14AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWxQSwECLQAUAAYACAAAACEAFXfh BNwGAABxHQAAFAAAAAAAAAAAAAAAAACJewAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYA CAAAACEA0IPRhNQBAAAsBAAAEQAAAAAAAAAAAAAAAACXggAAcHB0L3ZpZXdQcm9wcy54bWxQSwEC LQAUAAYACAAAACEAXJxHFE4BAACJAgAAEQAAAAAAAAAAAAAAAACahAAAcHB0L3ByZXNQcm9wcy54 bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAAAXhgAAcHB0L3RhYmxl U3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQC39PEuHAcAAIkfAAATAAAAAAAAAAAAAAAAAPSGAABj dXN0b21YbWwvaXRlbTIueG1sUEsBAi0AFAAGAAgAAAAhAOkzxgp3BAAAbSkAACgAAAAAAAAAAAAA AAAAaY4AAHBwdC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW5QSwECLQAUAAYA CAAAACEAOBSlLxABAACSAQAAEwAAAAAAAAAAAAAAAAAmkwAAZG9jUHJvcHMvY3VzdG9tLnhtbFBL AQItABQABgAIAAAAIQDe/4g/fgIAAI8FAAAQAAAAAAAAAAAAAAAAAG+VAABkb2NQcm9wcy9hcHAu eG1sUEsBAi0AFAAGAAgAAAAhAMpiDPeCAQAAygIAABEAAAAAAAAAAAAAAAAAI5kAAGRvY1Byb3Bz L2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhADtzzasBAQAA7AEAABMAAAAAAAAAAAAAAAAA3JsAAGN1 c3RvbVhtbC9pdGVtMS54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAA AAA2nQAAY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAFyWJyLD AAAAKAEAAB4AAAAAAAAAAAAAAAAAPJ8AAGN1c3RvbVhtbC9fcmVscy9pdGVtMi54bWwucmVsc1BL AQItABQABgAIAAAAIQCo/JlOFQEAAPMBAAAYAAAAAAAAAAAAAAAAAEOhAABjdXN0b21YbWwvaXRl bVByb3BzMS54bWxQSwECLQAUAAYACAAAACEAvYRiI5AAAADbAAAAEwAAAAAAAAAAAAAAAAC2ogAA Y3VzdG9tWG1sL2l0ZW0zLnhtbFBLAQItABQABgAIAAAAIQA6yRat8gAAAE8BAAAYAAAAAAAAAAAA AAAAAJ+jAABjdXN0b21YbWwvaXRlbVByb3BzMy54bWxQSwECLQAUAAYACAAAACEAe/MCo8MAAAAo AQAAHgAAAAAAAAAAAAAAAADvpAAAY3VzdG9tWG1sL19yZWxzL2l0ZW0zLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANo74wmSAQAATQQAABgAAAAAAAAAAAAAAAAA9qYAAGN1c3RvbVhtbC9pdGVtUHJv cHMyLnhtbFBLBQYAAAAAOwA7AH4RAADmqAAAAAA= --Apple-Mail=_83D74ABC-09E5-4BB5-BAA2-278E42575BAE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

On 29/07/2013, at 08:14, yunfei zhang <hishigh@gmail.com> wrote:

Hi all,
Just to remind that please send the slides presented in PPSP session to Stefano and me by tommorrow afternoon, 17:00. Thanks and see you in Berlin.
BR
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

--Apple-Mail=_83D74ABC-09E5-4BB5-BAA2-278E42575BAE-- --Apple-Mail=_527C2ED0-07F4-4658-BCAB-55DF1425B2F6-- From a.bakker@vu.nl Tue Jul 30 03:25:20 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D72621F9644 for ; Tue, 30 Jul 2013 03:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GctDw7gqvib for ; Tue, 30 Jul 2013 03:25:12 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA621F9A30 for ; Tue, 30 Jul 2013 03:25:06 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 12:25:22 +0200 Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 12:25:05 +0200 Message-ID: <51F794A8.7080005@cs.vu.nl> Date: Tue, 30 Jul 2013 12:25:44 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <007601ce77b0$aae81910$00b84b30$@com> In-Reply-To: <007601ce77b0$aae81910$00b84b30$@com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.253.20] Subject: Re: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ppsp-bfbitmap-00=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:25:20 -0000 On 03/07/2013 07:46, 邓灵莉/Lingli Deng wrote: > Hi all, > > We have just submitted a new draft proposing to use bloom filters to compress the chunk bitmap information exchanged between peers and the tracker. > http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/ > > Besides the basic algorithms and high level message flow, it also provides an initial discussion on how to integrate with the current tracker and peer protocol. > > Your comments would be highly appreciated. > Hi all some initial comments: 1. The number of chunks in which a content item is divided will be large in PPSPP as they are at most 64 KiB (UDP limit) and most likely 1 KiB (small chance of loss due to fragmentation). Does your compression method still yield low errors for small m when the initial bitmap is large? 2. The peer protocol does not prescribe what chunk availability information is sent in HAVE messages, as this depends on the needs of the chunk picking algorithm. For example, when the chunk picker uses rarest first it may need more up-to-date information than in other designs. Typically, as Riccardo remarks, it will provide a more-or-less complete overview in the beginning (which may be easily compressed, see 3.) and then only updates. The latter are also small and easily expressed as chunk ranges. 3. The bitmap representation of the chunk availability will depend on the chunk picking policy. For video-on-demand, a peer will usually have all chunks of the initial parts of the content (or starting at the point in the content where it seek-ed to). So the bitmap starts with a large number of ones. How the part that follows looks depends on the chunk picker. When e.g. rarest first is used with 3 priorities (cf. BitOS) the following part will be sparser. For live, there will be a small dense window of 1s. It is not yet clear to me that your method is better at compressing these typical maps than the current chunk addressing methods, and that it is more efficient given most chunk-availability-exchanges are small updates. In this context, you may also want to look at the binmap datastructure for representing bitmaps: Grishchenko, V. and J. Pouwelse, "Binmaps: hybridizing bitmaps and binary trees", Technical Report PDS-2011-005, Parallel and Distributed Systems Group, Fac. of Electrical Engineering, Mathematics, and Computer Science, Delft University of Technology, The Netherlands, Apr 2009. Regards, Arno Bakker From rachel.huang@huawei.com Tue Jul 30 03:44:14 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BEF21E8056 for ; Tue, 30 Jul 2013 03:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[AWL=-2.146, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6yH6N4tKQlP for ; Tue, 30 Jul 2013 03:44:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49B21E8084 for ; Tue, 30 Jul 2013 03:44:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVO31582; Tue, 30 Jul 2013 10:44:01 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 11:43:51 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 11:43:58 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 18:43:51 +0800 From: "Huangyihong (Rachel)" To: "arno@cs.vu.nl" , "ppsp@ietf.org" Thread-Topic: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt Thread-Index: AQHOjQSU3nuf+AK/R0eACq2dSsOfPJl9BM4w Date: Tue, 30 Jul 2013 10:43:51 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> In-Reply-To: <51F78163.8050605@cs.vu.nl> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.168.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:44:14 -0000 SGkgQXJubywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5 IGlubGluZS4NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHBwc3AtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBcm5vIEJha2tlcg0Kt6LL zcqxvOQ6IDIwMTPE6jfUwjMwyNUgMTc6MDQNCsrVvP7IyzogcHBzcEBpZXRmLm9yZw0K1vfM4jog UmU6IFtwcHNwXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWFuZy1w cHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wtMDMudHh0DQoNCkhpIGFsbA0KDQpJIGhhdmUg c29tZSBjb21tZW50cyBvbiB0aGUgZXh0ZW5kZWQgdHJhY2tlciBwcm90b2NvbCdzIG1vdGl2YXRp b24uIFRoZSBkcmFmdCBsaXN0cyA0IHVzZSBjYXNlcyB0aGF0IHRoZSBiYXNlIHByb3RvY29sICJt YXkgbm90IGJlIGFibGUgdG8gZGVhbCB3aXRoIi4NCg0KIjEuIFRoZSBwZWVyIGxpc3Qgb2YgYSBz cGVjaWZpYyBzd2FybSBvYnRhaW5lZCBieSBhIHBlZXIgbWF5IGJlIG91dCBvZiBkYXRlIjoNCg0K CUkgYWx3YXlzIGFzc3VtZWQgdGhhdCB3aGVuIHRoZSBpbml0aWFsIHBlZXIgbGlzdCByZWNlaXZl ZCB2aWENCgl0aGUgYmFzZSBwcm90b2NvbCBpcyBvdXRkYXRlZCwgYSBwZWVyIHdvdWxkIHNlbmQg YSBuZXcgQ09OTkVDVA0KCW1lc3NhZ2Ugd2l0aCBhIFBlZXJOdW0gYXR0cmlidXRlIHRvIGdldCBh IG5ldyBsaXN0LiBTbyB3aHkgaXMNCglleHRyYSBzdXBwb3J0IG5lZWRlZD8NCg0KW1JhY2hlbF06 IEkgdGhpbmsgdGhlIHBlZXIgc2hvdWxkIGZpcnN0IGRpc2Nvbm5lY3QgZnJvbSB0aGUgc3dhcm0s IGFuZCB0aGVuIHNlbmQgYSBuZXcgQ09OTkVDVCBtZXNzYWdlIHRvIGdldCBhIG5ldyBsaXN0LiBB Y3R1YWxseSwgSSB0aGluayB0aGlzIHByb2NlZHVyZSBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4g aGF2aW5nIGEgbmV3IG1lc3NhZ2UgKCBpbiB0aGlzIHNwZWMsIHdlIGRlZmluZSBhIG5ldyBtZXNz YWdlIEZJTkQpIHRvIGRlYWwgd2l0aCBpdC4NCg0KIjIuIEEgcGVlciBtYXkgaGF2ZSB0aGUgcmVx dWlyZW1lbnQgdG8gaW5mb3JtIHRoZSB0cmFja2VyIGl0cyBuZXcgbmV0d29yayBhZGRyZXNzIHdo ZW4gdGhlIHBlZXIgaGFzIGNoYW5nZWQgaXRzIHByaW1hcnkgbmV0d29yayBhdHRhY2htZW50LiIN Cg0KCWEpIElzbid0IHRoaXMgdGhlIHJvbGUgb2YgbW9iaWxlIElQPyBhbmQgYikgY2FuJ3QgdGhl IGJhc2UgCQ0KCUNPTk5FQ1QgaGFuZGxlIHRoaXM/DQoNCltSYWNoZWxdOiBJIHRoaW5rIHRoaXMg Y2FzZSBpcyB0YWxraW5nIGFib3V0IHRoZSBwZWVyIHN3aXRjaGVzIGl0cyBuZXR3b3JrIGFkZHJl c3MgZHVyaW5nIHRoZSBzdHJlYW1pbmcuIEZvciBleGFtcGxlLCBhIHBlZXIgaXMgZmlyc3RseSB1 c2luZyBXSUZJIHRvIGNvbm5lY3QgdG8gdGhlIHRyYWNrZXIuIEJ1dCBkdXJpbmcgdGhlIHN0cmVh bWluZywgdGhlIFdJRkkgaGFzIHByb2JsZW0gYW5kIHRoZSBwZWVyIGRlY2lkZXMgdG8gc3dpdGNo IHRvIGEgd2lyZWQgbmV0d29yayBidXQgaXQgZG9lc24ndCB3YW50IHRvIHN0b3AgdGhlIHN0cmVh bWluZy4gQWN0dWFsbHksIEkgdGhpbmsgdGhlIGJhc2UgQ09OTkVDVCBjYW4ndCBoYW5kbGUgaXQu IEJlY2F1c2UgaXQgY2FuJ3QgIkNPTk5FQ1QiIHRvIHRoZSBzYW1lIHN3YXJtIHR3aWNlLCByaWdo dD8gDQoNCkl0IHNlZW1zIG1vc3Qgb2YgdGhlIHNwZWMgaXMgYWN0dWFsbHkgYWJvdXQgZmluZGlu ZyBwZWVycyBiYXNlZCBvbiB3aGF0IGNvbnRlbnQgdGhleSBoYXZlIGFuZCBub3QgdGhlc2UgdHdv IHNwZWNpZmljIHVzZSBjYXNlcywgc28gcGVyaGFwcyB0aGV5IGNhbiBiZSByZW1vdmVkPw0KDQpb UmFjaGVsXTogTm8uIEl0J3Mgbm90IGp1c3QgYWJvdXQgZmluZGluZyBwZWVycyBiYXNlZCBvbiBj b250ZW50LiBBcyBJIGV4cGxhaW5lZCBhYm92ZSwgYmFzZSBDT05ORUNUIGNhbid0IGRlYWwgd2l0 aCB0aGVzZSB0d28gY2FzZSwgdGhhdCdzIHdoeSBuZXcgbWVzc2FnZSBGSU5EIGlzIHJlcXVpcmVk Lg0KDQpSZWdhcmRzLA0KICAgICAgQXJubw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0K From a.bakker@vu.nl Tue Jul 30 04:30:32 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195C11E8100 for ; Tue, 30 Jul 2013 04:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNZBZSSvb4YF for ; Tue, 30 Jul 2013 04:30:25 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12411E81D9 for ; Tue, 30 Jul 2013 04:30:05 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 13:30:17 +0200 Received: from [130.37.193.73] (130.37.253.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 30 Jul 2013 13:29:59 +0200 Message-ID: <51F7A3DA.9@cs.vu.nl> Date: Tue, 30 Jul 2013 13:30:34 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Huangyihong (Rachel)" References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.253.20] Cc: "ppsp@ietf.org" Subject: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:30:33 -0000 Hi Rachel and all please see inline. On 30/07/2013 12:43, Huangyihong (Rachel) wrote: > > "1. The peer list of a specific swarm obtained by a peer may be out > of date": > > I always assumed that when the initial peer list received via the > base protocol is outdated, a peer would send a new CONNECT message > with a PeerNum attribute to get a new list. So why is extra support > needed? > > [Rachel]: I think the peer should first disconnect from the swarm, > and then send a new CONNECT message to get a new list. Actually, I > think this procedure is more complicated than having a new message ( > in this spec, we define a new message FIND) to deal with it. > I may have been misreading the base protocol spec for a long time then. Table 8 of the base protocol indeed does not list that a "CONNECT action=join" while in tracking state is a valid transition. IMHO, I think it should for both LEECH and SEED, retrieving a new set of peers for the swarm you are in is basic functionality. Or FIND must be moved into the base protocol spec. > "2. A peer may have the requirement to inform the tracker its new > network address when the peer has changed its primary network > attachment." > > a) Isn't this the role of mobile IP? and b) can't the base CONNECT > handle this? > > [Rachel]: I think this case is talking about the peer switches its > network address during the streaming. For example, a peer is firstly > using WIFI to connect to the tracker. But during the streaming, the > WIFI has problem and the peer decides to switch to a wired network > but it doesn't want to stop the streaming. Actually, I think the base > CONNECT can't handle it. Because it can't "CONNECT" to the same swarm > twice, right? > There are many IETF drafts to deal with IP-address change, and IMHO there is no need to add another one here. CU, Arno From rachel.huang@huawei.com Tue Jul 30 06:50:00 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3105A21F9DDB for ; Tue, 30 Jul 2013 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-3.853, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGdGTYIhEeYY for ; Tue, 30 Jul 2013 06:49:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC1521F9D11 for ; Tue, 30 Jul 2013 06:49:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVO46992; Tue, 30 Jul 2013 13:49:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 14:49:20 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 14:49:27 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 21:49:24 +0800 From: "Huangyihong (Rachel)" To: "arno@cs.vu.nl" Thread-Topic: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt Thread-Index: AQHOjRiEydnTgzFi10WvPhVg2BcEcJl9Oqmg Date: Tue, 30 Jul 2013 13:49:23 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> <51F7A3DA.9@cs.vu.nl> In-Reply-To: <51F7A3DA.9@cs.vu.nl> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.174.43] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ppsp@ietf.org" Subject: [ppsp] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24JZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90?= =?gb2312?b?b2NvbC0wMy50eHQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:50:00 -0000 SGkgQXJubywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClJhY2hlbA0K DQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogQXJubyBCYWtrZXIgW21haWx0bzphcm5vQGNz LnZ1Lm5sXSANCreiy83KsbzkOiAyMDEzxOo31MIzMMjVIDE5OjMxDQrK1bz+yMs6IEh1YW5neWlo b25nIChSYWNoZWwpDQqzrcvNOiBwcHNwQGlldGYub3JnDQrW98ziOiBSZTogW3Bwc3BdIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJh Y2tlci1wcm90b2NvbC0wMy50eHQNCg0KSGkgUmFjaGVsIGFuZCBhbGwNCg0KcGxlYXNlIHNlZSBp bmxpbmUuDQoNCk9uIDMwLzA3LzIwMTMgMTI6NDMsIEh1YW5neWlob25nIChSYWNoZWwpIHdyb3Rl Og0KPg0KPiAiMS4gVGhlIHBlZXIgbGlzdCBvZiBhIHNwZWNpZmljIHN3YXJtIG9idGFpbmVkIGJ5 IGEgcGVlciBtYXkgYmUgb3V0IG9mIA0KPiBkYXRlIjoNCj4NCj4gSSBhbHdheXMgYXNzdW1lZCB0 aGF0IHdoZW4gdGhlIGluaXRpYWwgcGVlciBsaXN0IHJlY2VpdmVkIHZpYSB0aGUgYmFzZSANCj4g cHJvdG9jb2wgaXMgb3V0ZGF0ZWQsIGEgcGVlciB3b3VsZCBzZW5kIGEgbmV3IENPTk5FQ1QgbWVz c2FnZSB3aXRoIGEgDQo+IFBlZXJOdW0gYXR0cmlidXRlIHRvIGdldCBhIG5ldyBsaXN0LiBTbyB3 aHkgaXMgZXh0cmEgc3VwcG9ydCBuZWVkZWQ/DQo+DQo+IFtSYWNoZWxdOiBJIHRoaW5rIHRoZSBw ZWVyIHNob3VsZCBmaXJzdCBkaXNjb25uZWN0IGZyb20gdGhlIHN3YXJtLCBhbmQgDQo+IHRoZW4g c2VuZCBhIG5ldyBDT05ORUNUIG1lc3NhZ2UgdG8gZ2V0IGEgbmV3IGxpc3QuIEFjdHVhbGx5LCBJ IHRoaW5rIA0KPiB0aGlzIHByb2NlZHVyZSBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gaGF2aW5n IGEgbmV3IG1lc3NhZ2UgKCBpbiB0aGlzIA0KPiBzcGVjLCB3ZSBkZWZpbmUgYSBuZXcgbWVzc2Fn ZSBGSU5EKSB0byBkZWFsIHdpdGggaXQuDQo+DQoNCkkgbWF5IGhhdmUgYmVlbiBtaXNyZWFkaW5n IHRoZSBiYXNlIHByb3RvY29sIHNwZWMgZm9yIGEgbG9uZyB0aW1lIHRoZW4uIA0KVGFibGUgOCBv ZiB0aGUgYmFzZSBwcm90b2NvbCBpbmRlZWQgZG9lcyBub3QgbGlzdCB0aGF0IGEgIkNPTk5FQ1Qg YWN0aW9uPWpvaW4iIHdoaWxlIGluIHRyYWNraW5nIHN0YXRlIGlzIGEgdmFsaWQgdHJhbnNpdGlv bi4gSU1ITywgSSB0aGluayBpdCBzaG91bGQgZm9yIGJvdGggTEVFQ0ggYW5kIFNFRUQsIHJldHJp ZXZpbmcgYSBuZXcgc2V0IG9mIHBlZXJzIGZvciB0aGUgc3dhcm0geW91IGFyZSBpbiBpcyBiYXNp YyBmdW5jdGlvbmFsaXR5LiBPciBGSU5EIG11c3QgYmUgbW92ZWQgaW50byB0aGUgYmFzZSBwcm90 b2NvbCBzcGVjLg0KDQpbUmFjaGVsXTogQWxsIHJpZ2h0LiBMZXQncyBzZWUgaG93IGl0IHdvcmtz IGluIHRoZSBtZWV0aW5nLg0KDQo+ICIyLiBBIHBlZXIgbWF5IGhhdmUgdGhlIHJlcXVpcmVtZW50 IHRvIGluZm9ybSB0aGUgdHJhY2tlciBpdHMgbmV3IA0KPiBuZXR3b3JrIGFkZHJlc3Mgd2hlbiB0 aGUgcGVlciBoYXMgY2hhbmdlZCBpdHMgcHJpbWFyeSBuZXR3b3JrIA0KPiBhdHRhY2htZW50LiIN Cj4NCj4gYSkgSXNuJ3QgdGhpcyB0aGUgcm9sZSBvZiBtb2JpbGUgSVA/IGFuZCBiKSBjYW4ndCB0 aGUgYmFzZSBDT05ORUNUIA0KPiBoYW5kbGUgdGhpcz8NCj4NCj4gW1JhY2hlbF06IEkgdGhpbmsg dGhpcyBjYXNlIGlzIHRhbGtpbmcgYWJvdXQgdGhlIHBlZXIgc3dpdGNoZXMgaXRzIA0KPiBuZXR3 b3JrIGFkZHJlc3MgZHVyaW5nIHRoZSBzdHJlYW1pbmcuIEZvciBleGFtcGxlLCBhIHBlZXIgaXMg Zmlyc3RseSANCj4gdXNpbmcgV0lGSSB0byBjb25uZWN0IHRvIHRoZSB0cmFja2VyLiBCdXQgZHVy aW5nIHRoZSBzdHJlYW1pbmcsIHRoZSANCj4gV0lGSSBoYXMgcHJvYmxlbSBhbmQgdGhlIHBlZXIg ZGVjaWRlcyB0byBzd2l0Y2ggdG8gYSB3aXJlZCBuZXR3b3JrIGJ1dCANCj4gaXQgZG9lc24ndCB3 YW50IHRvIHN0b3AgdGhlIHN0cmVhbWluZy4gQWN0dWFsbHksIEkgdGhpbmsgdGhlIGJhc2UgDQo+ IENPTk5FQ1QgY2FuJ3QgaGFuZGxlIGl0LiBCZWNhdXNlIGl0IGNhbid0ICJDT05ORUNUIiB0byB0 aGUgc2FtZSBzd2FybSANCj4gdHdpY2UsIHJpZ2h0Pw0KPg0KDQpUaGVyZSBhcmUgbWFueSBJRVRG IGRyYWZ0cyB0byBkZWFsIHdpdGggSVAtYWRkcmVzcyBjaGFuZ2UsIGFuZCBJTUhPIHRoZXJlIGlz IG5vIG5lZWQgdG8gYWRkIGFub3RoZXIgb25lIGhlcmUuDQoNCltSYWNoZWxdOiBJIHRoaW5rIHRo aXMgY2FzZSBpcyBzaW1pbGFyIHRvIHRoZSBmaXJzdCBjYXNlLCBiZWNhdXNlIGZpcnN0IGNhc2Ug aXMgYWJvdXQgZ2V0dGluZyB0aGUgdXBkYXRlIGluZm9ybWF0aW9uIGZyb20gdGhlIHRyYWNrZXIg dG8gcGVlciwgYW5kIHRoaXMgb25lIGlzIGFib3V0IHByb3ZpZGluZyB0aGUgdXBkYXRlZCBpbmZv cm1hdGlvbiBvZiB0aGUgcGVlciB0byB0aGUgdHJhY2tlci4gU28gdGhlIGNvbmNsdXNpb24gbWFk ZSB0byB0aGUgZmlyc3QgY2FzZSBjb3VsZCBhbHNvIGFwcGx5IHRvIHRoaXMgY2FzZS4NCg0KQ1Us DQogICAgIEFybm8NCg== From hishigh@gmail.com Wed Jul 31 00:33:17 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF34021E8051 for ; Wed, 31 Jul 2013 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpZ8Lp-jvZiF for ; Wed, 31 Jul 2013 00:33:16 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6021E80BE for ; Wed, 31 Jul 2013 00:33:16 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so810281oag.15 for ; Wed, 31 Jul 2013 00:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=LmbqBSP6cb9RA+uSD2Pqc90CXk386L3Q0mfD7DIWWCQ=; b=H5WAI8vGxOKkYe5nyETg9TdJBGiBVsoFyaIeE4Fv/pXmu8C/3HBcQM7+/Deozs2y3I wZR+39GZpHJI+tCGK5DTTLwc1j3RRqCRvYhrVkm9N9PJojPGTE8Lxe3T/JNTHw2EW2kj +cZs9FOZz4SmLre8CFDpXEhTS1gjm8Y1AnWTbVrGShv1lnvLoF/igjMWDYzrfkFMthJm l6Jcw2uCYp+eQohkSyTiPa+vmEJz39U1DBErBsK0VnlY/kChZW92JSVUbywS/kXgGxLL OyMcUg+l4vEmJ+SRw8cRgRv+q0HsDaR8LiM6syeHZM+4hg4jGZLtSSJcugdeU5llNP3j zxOg== MIME-Version: 1.0 X-Received: by 10.60.57.130 with SMTP id i2mr19559728oeq.51.1375255995654; Wed, 31 Jul 2013 00:33:15 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Wed, 31 Jul 2013 00:33:15 -0700 (PDT) Date: Wed, 31 Jul 2013 15:33:15 +0800 Message-ID: From: yunfei zhang To: "ppsp@ietf.org" Content-Type: multipart/alternative; boundary=089e013d0a6c18a6c704e2c9bd37 Subject: [ppsp] Slides for PPSP session are available now X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:33:17 -0000 --089e013d0a6c18a6c704e2c9bd37 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Please find the slides for the afternoon session in the IETF website. For the remote participants, the following is the means you can access the meeting: ----------------------------------------------------------------------------------------------------------- Topic: ppsp Date: Wednesday, July 31, 2013 Time: 3:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 967 786 633 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=208853667& UID=1363261052&PW=NMTg5MWViODQ1&RT=MiMyNQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=208853667&UID=1363261052&PW= NMTg5MWViODQ1&ORT=MiMyNQ%3D%3D Participants may also join from the http://www.ietf.org/meeting/ 87/remote-participation.html. Note that remote participants will need to listen to the audio stream (linked from both http://www.ietf.org/meeting/87/remote-participation.htmland http://tools.ietf.org/agenda/87/) to follow the discussion. See you in Berlin. BR Yunfei --089e013d0a6c18a6c704e2c9bd37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0=A0 Please find the slides for t= he afternoon session in the IETF website.
=A0 =A0For the remote p= articipants, the following is the means you can access the meeting:
------------------------------------------------------------------------= -----------------------------------
Topic: ppsp
Date: Wednesday, July 31, 2013 =
Time: 3:00 pm, Europe Summer Time (Berlin, GMT+02:00)
Meeting Num= ber: 967 786 633
Meeting Password: 1234


---------------= ----------------------------------------
To join the online meeting (Now from mobile devices!)
---------------= ----------------------------------------
= 1. Go to https://work= green.webex.com/workgreen/j.php?ED=3D208853667&UID=3D1363261052&PW=3DNMTg5MWViODQ1&RT=3DMiMyNQ%3D%3D =
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://workgreen.webex.com/workgree= n/j.php?ED=3D208853667&U= ID=3D1363261052&PW=3DNMT= g5MWViODQ1&ORT=3DMiMyNQ%3D%3D=A0
Participants may also join = from the http://w= ww.ietf.org/meeting/87/remote-participation.= html.

Note that remote participants will need to listen to the audio stream (= linked from both http://www.ietf.org/me= eting/87/remote-participation.html and http://tools.ietf.org/agenda/87/) to follow the discussion.
=A0=A0=A0 See you in Berlin.
= =A0
=A0
BR
Yunfei

=A0
--089e013d0a6c18a6c704e2c9bd37-- From zongning@huawei.com Wed Jul 31 05:25:58 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5E821F85F4 for ; Wed, 31 Jul 2013 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.212 X-Spam-Level: X-Spam-Status: No, score=-97.212 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuxI-fpPps+4 for ; Wed, 31 Jul 2013 05:25:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A521F9DCA for ; Wed, 31 Jul 2013 05:25:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVP34161; Wed, 31 Jul 2013 12:25:39 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 13:25:22 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 13:25:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 20:25:24 +0800 From: Zongning To: "Huangyihong (Rachel)" , "arno@cs.vu.nl" Thread-Topic: =?gb2312?B?W3Bwc3BdILTwuLQ6ICBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uCWZv?= =?gb2312?B?ciBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wt?= =?gb2312?Q?03.txt?= Thread-Index: AQHOjS0iSHE/8seGVE6I849HQwvH8Jl+tO6f Date: Wed, 31 Jul 2013 12:25:23 +0000 Message-ID: References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> <51F7A3DA.9@cs.vu.nl>, <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.231] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24JZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90?= =?gb2312?b?b2NvbC0wMy50eHQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:25:59 -0000 SGksIFJhY2hlbCBhbmQgQXJubywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHBwc3AtYm91bmNlc0BpZXRmLm9y ZyBbcHBzcC1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSHVhbmd5aWhvbmcgKFJhY2hl bCkgW3JhY2hlbC5odWFuZ0BodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAzMCwgMjAx MyA5OjQ5IFBNDQpUbzogYXJub0Bjcy52dS5ubA0KQ2M6IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6 IFtwcHNwXSC08Li0OiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAgICBmb3IgZHJh ZnQtaHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sLTAzLnR4dA0KDQpIaSBBcm5v LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQmVzdCByZWdhcmRzLA0KUmFjaGVsDQoNCi0tLS0t 08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBBcm5vIEJha2tlciBbbWFpbHRvOmFybm9AY3MudnUubmxd DQq3osvNyrG85DogMjAxM8TqN9TCMzDI1SAxOTozMQ0KytW8/sjLOiBIdWFuZ3lpaG9uZyAoUmFj aGVsKQ0Ks63LzTogcHBzcEBpZXRmLm9yZw0K1vfM4jogUmU6IFtwcHNwXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJv dG9jb2wtMDMudHh0DQoNCkhpIFJhY2hlbCBhbmQgYWxsDQoNCnBsZWFzZSBzZWUgaW5saW5lLg0K DQpPbiAzMC8wNy8yMDEzIDEyOjQzLCBIdWFuZ3lpaG9uZyAoUmFjaGVsKSB3cm90ZToNCj4NCj4g IjEuIFRoZSBwZWVyIGxpc3Qgb2YgYSBzcGVjaWZpYyBzd2FybSBvYnRhaW5lZCBieSBhIHBlZXIg bWF5IGJlIG91dCBvZg0KPiBkYXRlIjoNCj4NCj4gSSBhbHdheXMgYXNzdW1lZCB0aGF0IHdoZW4g dGhlIGluaXRpYWwgcGVlciBsaXN0IHJlY2VpdmVkIHZpYSB0aGUgYmFzZQ0KPiBwcm90b2NvbCBp cyBvdXRkYXRlZCwgYSBwZWVyIHdvdWxkIHNlbmQgYSBuZXcgQ09OTkVDVCBtZXNzYWdlIHdpdGgg YQ0KPiBQZWVyTnVtIGF0dHJpYnV0ZSB0byBnZXQgYSBuZXcgbGlzdC4gU28gd2h5IGlzIGV4dHJh IHN1cHBvcnQgbmVlZGVkPw0KPg0KPiBbUmFjaGVsXTogSSB0aGluayB0aGUgcGVlciBzaG91bGQg Zmlyc3QgZGlzY29ubmVjdCBmcm9tIHRoZSBzd2FybSwgYW5kDQo+IHRoZW4gc2VuZCBhIG5ldyBD T05ORUNUIG1lc3NhZ2UgdG8gZ2V0IGEgbmV3IGxpc3QuIEFjdHVhbGx5LCBJIHRoaW5rDQo+IHRo aXMgcHJvY2VkdXJlIGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBoYXZpbmcgYSBuZXcgbWVzc2Fn ZSAoIGluIHRoaXMNCj4gc3BlYywgd2UgZGVmaW5lIGEgbmV3IG1lc3NhZ2UgRklORCkgdG8gZGVh bCB3aXRoIGl0Lg0KPg0KDQpJIG1heSBoYXZlIGJlZW4gbWlzcmVhZGluZyB0aGUgYmFzZSBwcm90 b2NvbCBzcGVjIGZvciBhIGxvbmcgdGltZSB0aGVuLg0KVGFibGUgOCBvZiB0aGUgYmFzZSBwcm90 b2NvbCBpbmRlZWQgZG9lcyBub3QgbGlzdCB0aGF0IGEgIkNPTk5FQ1QgYWN0aW9uPWpvaW4iIHdo aWxlIGluIHRyYWNraW5nIHN0YXRlIGlzIGEgdmFsaWQgdHJhbnNpdGlvbi4gSU1ITywgSSB0aGlu ayBpdCBzaG91bGQgZm9yIGJvdGggTEVFQ0ggYW5kIFNFRUQsIHJldHJpZXZpbmcgYSBuZXcgc2V0 IG9mIHBlZXJzIGZvciB0aGUgc3dhcm0geW91IGFyZSBpbiBpcyBiYXNpYyBmdW5jdGlvbmFsaXR5 LiBPciBGSU5EIG11c3QgYmUgbW92ZWQgaW50byB0aGUgYmFzZSBwcm90b2NvbCBzcGVjLg0KDQpb UmFjaGVsXTogQWxsIHJpZ2h0LiBMZXQncyBzZWUgaG93IGl0IHdvcmtzIGluIHRoZSBtZWV0aW5n Lg0KDQpbWk9OR106IElmIEkgcmVjYWxsIGNvcnJlY3RseSwgd2UgZGVjaWRlZCB0byBrZWVwIGJh c2UgdHJhY2sgcHJvdG9jb2wgc2ltcGxlIC0gdGhlIHJlYXNvbiB3ZSBoYXZlIGV4dGVuZGVkIHRy YWNrZXIgcHJvdG9jb2wuIFNvIHdlIGhhdmUgYSBiYXNpYyBhbmQgc21hbGwgc2V0IG9mIGZ1bmN0 aW9uYWxpdGllcyBmb3IgQ09OTkVDVCBhbmQgZGVmaW5lIG90aGVyIGZ1bmN0aW9ucyBpbiBvdGhl ciBtZXNzYWdlcy4gSSB0ZW5kIHRvIGtlZXAgRklORCB3aXRoIGZ1bmN0aW9ucyBzdWNoIGFzIHBl ZXIgbGlzdCB1cGRhdGUgaW4gZXh0ZW5kZWQgZHJhZnQgdGhlbi4NCg0KPiAiMi4gQSBwZWVyIG1h eSBoYXZlIHRoZSByZXF1aXJlbWVudCB0byBpbmZvcm0gdGhlIHRyYWNrZXIgaXRzIG5ldw0KPiBu ZXR3b3JrIGFkZHJlc3Mgd2hlbiB0aGUgcGVlciBoYXMgY2hhbmdlZCBpdHMgcHJpbWFyeSBuZXR3 b3JrDQo+IGF0dGFjaG1lbnQuIg0KPg0KPiBhKSBJc24ndCB0aGlzIHRoZSByb2xlIG9mIG1vYmls ZSBJUD8gYW5kIGIpIGNhbid0IHRoZSBiYXNlIENPTk5FQ1QNCj4gaGFuZGxlIHRoaXM/DQo+DQo+ IFtSYWNoZWxdOiBJIHRoaW5rIHRoaXMgY2FzZSBpcyB0YWxraW5nIGFib3V0IHRoZSBwZWVyIHN3 aXRjaGVzIGl0cw0KPiBuZXR3b3JrIGFkZHJlc3MgZHVyaW5nIHRoZSBzdHJlYW1pbmcuIEZvciBl eGFtcGxlLCBhIHBlZXIgaXMgZmlyc3RseQ0KPiB1c2luZyBXSUZJIHRvIGNvbm5lY3QgdG8gdGhl IHRyYWNrZXIuIEJ1dCBkdXJpbmcgdGhlIHN0cmVhbWluZywgdGhlDQo+IFdJRkkgaGFzIHByb2Js ZW0gYW5kIHRoZSBwZWVyIGRlY2lkZXMgdG8gc3dpdGNoIHRvIGEgd2lyZWQgbmV0d29yayBidXQN Cj4gaXQgZG9lc24ndCB3YW50IHRvIHN0b3AgdGhlIHN0cmVhbWluZy4gQWN0dWFsbHksIEkgdGhp bmsgdGhlIGJhc2UNCj4gQ09OTkVDVCBjYW4ndCBoYW5kbGUgaXQuIEJlY2F1c2UgaXQgY2FuJ3Qg IkNPTk5FQ1QiIHRvIHRoZSBzYW1lIHN3YXJtDQo+IHR3aWNlLCByaWdodD8NCj4NCg0KVGhlcmUg YXJlIG1hbnkgSUVURiBkcmFmdHMgdG8gZGVhbCB3aXRoIElQLWFkZHJlc3MgY2hhbmdlLCBhbmQg SU1ITyB0aGVyZSBpcyBubyBuZWVkIHRvIGFkZCBhbm90aGVyIG9uZSBoZXJlLg0KDQpbUmFjaGVs XTogSSB0aGluayB0aGlzIGNhc2UgaXMgc2ltaWxhciB0byB0aGUgZmlyc3QgY2FzZSwgYmVjYXVz ZSBmaXJzdCBjYXNlIGlzIGFib3V0IGdldHRpbmcgdGhlIHVwZGF0ZSBpbmZvcm1hdGlvbiBmcm9t IHRoZSB0cmFja2VyIHRvIHBlZXIsIGFuZCB0aGlzIG9uZSBpcyBhYm91dCBwcm92aWRpbmcgdGhl IHVwZGF0ZWQgaW5mb3JtYXRpb24gb2YgdGhlIHBlZXIgdG8gdGhlIHRyYWNrZXIuIFNvIHRoZSBj b25jbHVzaW9uIG1hZGUgdG8gdGhlIGZpcnN0IGNhc2UgY291bGQgYWxzbyBhcHBseSB0byB0aGlz IGNhc2UuDQoNCltaT05HXTogSSBndWVzcyB3aGF0IEFybm8gbWVudGlvbmVkIGlzIHRoYXQgY3Vy cmVudCBJRVRGIE1JUCBtZWNoYW5pc21zIGhhbmRsZSBJUCBhZGRyZXNzIGNoYW5nZSB3aGlsZSBr ZWVwaW5nIHNlc3Npb24gdW50b3VjaGVkLiBJIGFncmVlIHRoYXQgdHJhY2tlciBwcm90b2NvbCBz aG91bGQgbm90IHJlLWludmVudCBuZXcgTUlQIHRlY2guIDopKSBJIHRoaW5rIHdoYXQgUmFjaGVs IHN0YXRlZCBpcyBhYm91dCBub3RpZnlpbmcgbmV3IElQIGFkZHJlc3MgdG8gdHJhY2tlciB1c2lu ZyB0cmFja2VyIHByb3RvY29sLCB3aGljaCBpcyBub3QgaGFuZGxlIG1vYmlsaXR5IGlzc3Vlcywg cmlnaHQ/DQoNCkNVLA0KICAgICBBcm5vDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA== From rui.cruz@ieee-pt.org Wed Jul 31 05:42:22 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E449D21F9EED for ; Wed, 31 Jul 2013 05:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=-2.318, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ME9cc6UMWug for ; Wed, 31 Jul 2013 05:42:15 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 46EDE21F9EDF for ; Wed, 31 Jul 2013 05:42:04 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u55so547691wes.41 for ; Wed, 31 Jul 2013 05:42:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=gnk6HQj2a5uFrGn3eUjonnlFTVp9JfPGzj/ePNsjDXM=; b=TrM0YhzdhniUmfz9yYxlXK5WFTJX++zEj4Y21hGPNq0z62YmZ70VqjmzIue8zXgN2m v0LsabiU9qddRlutbzOrimKHySDYAvSnRPbVfhz6QiO7KZepSp74PAP5+TAuhvE+es/M 0M5hdrr7kR6qSRSxMOv5Fxw3Ubqw1nfaWJAfwzWEl6NLqrRoxXipbTlIGjxUgx+n2xlq r+/0cCFRMG1NKKO+nyeUPVCw47P7so4hJRdeP0w8nowi7eMZxt6wE+kUPwO4O2lGFfMM hGsJwnQwbTWX81IwpFf+9lekvCDniMfZsmJBWqmqHM0CdeomulFh6UooBMffLdmy9ZZQ B3Lw== X-Received: by 10.180.24.197 with SMTP id w5mr4161739wif.25.1375274523976; Wed, 31 Jul 2013 05:42:03 -0700 (PDT) Received: from [192.168.1.216] ([89.180.107.19]) by mx.google.com with ESMTPSA id dt17sm29459131wic.1.2013.07.31.05.42.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 05:42:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D5629012-ABEA-41DF-B358-3C8B8430567B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Rui Cruz In-Reply-To: Date: Wed, 31 Jul 2013 13:42:00 +0100 Message-Id: <97A629B9-1576-4878-AAC4-41C7EFE65D6C@ieee-pt.org> References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> <51F7A3DA.9@cs.vu.nl>, <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> To: Zongning X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmnDH8xtBsFWtNhBXbgUK6smuTnaIazAXvPG1qE8n/+IcRf8l+a88UBRNMzXpawwkoxMV4R Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?utf-8?b?562U5aSNOiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv?= =?utf-8?q?n=09for_draft-huang-ppsp-extended-tracker-protocol-03=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:42:22 -0000 --Apple-Mail=_D5629012-ABEA-41DF-B358-3C8B8430567B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Please read inline. Regards, Rui Cruz On 31/07/2013, at 13:25, Zongning wrote: > Hi, Rachel and Arno, >=20 > Please see inline. >=20 > ________________________________________ > From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of = Huangyihong (Rachel) [rachel.huang@huawei.com] > Sent: Tuesday, July 30, 2013 9:49 PM > To: arno@cs.vu.nl > Cc: ppsp@ietf.org > Subject: [ppsp] =B4=F0=B8=B4: FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt >=20 > Hi Arno, >=20 > Please see inline. >=20 > Best regards, > Rachel >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Arno Bakker [mailto:arno@cs.vu.nl] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C230=C8=D5 19:31 > =CA=D5=BC=FE=C8=CB: Huangyihong (Rachel) > =B3=AD=CB=CD: ppsp@ietf.org > =D6=F7=CC=E2: Re: [ppsp] FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt >=20 > Hi Rachel and all >=20 > please see inline. >=20 > On 30/07/2013 12:43, Huangyihong (Rachel) wrote: >>=20 >> "1. The peer list of a specific swarm obtained by a peer may be out = of >> date": >>=20 >> I always assumed that when the initial peer list received via the = base >> protocol is outdated, a peer would send a new CONNECT message with a >> PeerNum attribute to get a new list. So why is extra support needed? >>=20 >> [Rachel]: I think the peer should first disconnect from the swarm, = and >> then send a new CONNECT message to get a new list. Actually, I think >> this procedure is more complicated than having a new message ( in = this >> spec, we define a new message FIND) to deal with it. >>=20 >=20 > I may have been misreading the base protocol spec for a long time = then. > Table 8 of the base protocol indeed does not list that a "CONNECT = action=3Djoin" while in tracking state is a valid transition. IMHO, I = think it should for both LEECH and SEED, retrieving a new set of peers = for the swarm you are in is basic functionality. Or FIND must be moved = into the base protocol spec. >=20 > [Rachel]: All right. Let's see how it works in the meeting. >=20 > [ZONG]: If I recall correctly, we decided to keep base track protocol = simple - the reason we have extended tracker protocol. So we have a = basic and small set of functionalities for CONNECT and define other = functions in other messages. I tend to keep FIND with functions such as = peer list update in extended draft then. [CRUZ] I fully agree with Zong. The Base Tracker Protocol was agreed in = consensus to be simple, and that other functionalities would be = expressed in extended versions. >=20 >> "2. A peer may have the requirement to inform the tracker its new >> network address when the peer has changed its primary network >> attachment." >>=20 >> a) Isn't this the role of mobile IP? and b) can't the base CONNECT >> handle this? >>=20 >> [Rachel]: I think this case is talking about the peer switches its >> network address during the streaming. For example, a peer is firstly >> using WIFI to connect to the tracker. But during the streaming, the >> WIFI has problem and the peer decides to switch to a wired network = but >> it doesn't want to stop the streaming. Actually, I think the base >> CONNECT can't handle it. Because it can't "CONNECT" to the same swarm >> twice, right? >>=20 >=20 > There are many IETF drafts to deal with IP-address change, and IMHO = there is no need to add another one here. >=20 > [Rachel]: I think this case is similar to the first case, because = first case is about getting the update information from the tracker to = peer, and this one is about providing the updated information of the = peer to the tracker. So the conclusion made to the first case could also = apply to this case. >=20 > [ZONG]: I guess what Arno mentioned is that current IETF MIP = mechanisms handle IP address change while keeping session untouched. I = agree that tracker protocol should not re-invent new MIP tech. :)) I = think what Rachel stated is about notifying new IP address to tracker = using tracker protocol, which is not handle mobility issues, right? [CRUZ] The obvious method relies on the STAT_REPORT request, that is = issued periodically or whenever required. When receiving such message = from a Registered Peer already tracked in one or more swarms, the = tracker updates the public IP address seen from the requesting peer. >=20 > CU, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_D5629012-ABEA-41DF-B358-3C8B8430567B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 zongning@huawei.com> = wrote:
Hi, Rachel and Arno,

Please see = inline.

________________________________________
From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on = behalf of Huangyihong (Rachel) [rachel.huang@huawei.com]
Se= nt: Tuesday, July 30, 2013 9:49 PM
To: arno@cs.vu.nl
Cc: ppsp@ietf.org
Subject: [ppsp] =B4=F0=B8= =B4:  FW: New Version Notification =       for = draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi = Arno,

Please see inline.

Best = regards,
Rachel

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE= =C8=CB: Arno Bakker [mailto:arno@cs.vu.nl]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2013=C4=EA7=D4=C230=C8=D5 19:31
=CA=D5=BC=FE=C8=CB: Huangyihong = (Rachel)
=B3=AD=CB=CD: ppsp@ietf.org
=D6=F7=CC=E2: Re: = [ppsp] FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel and = all

please see inline.

On 30/07/2013 12:43, Huangyihong = (Rachel) wrote:

"1. The peer list of a = specific swarm obtained by a peer may be out of
date":

I = always assumed that when the initial peer list received via the = base
protocol is outdated, a peer would send a new CONNECT message = with a
PeerNum attribute to get a new list. So why is extra support = needed?

[Rachel]: I think the peer should first disconnect from = the swarm, and
then send a new CONNECT message to get a new list. = Actually, I think
this procedure is more complicated than having a = new message ( in this
spec, we define a new message FIND) to deal = with it.


I may have been misreading the base = protocol spec for a long time then.
Table 8 of the base protocol = indeed does not list that a "CONNECT action=3Djoin" while in tracking = state is a valid transition. IMHO, I think it should for both LEECH and = SEED, retrieving a new set of peers for the swarm you are in is basic = functionality. Or FIND must be moved into the base protocol = spec.

[Rachel]: All right. Let's see how it works in the = meeting.

[ZONG]: If I recall correctly, we decided to keep base = track protocol simple - the reason we have extended tracker protocol. So = we have a basic and small set of functionalities for CONNECT and define = other functions in other messages. I tend to keep FIND with functions = such as peer list update in extended draft = then.

[CRUZ] I fully agree with Zong. The = Base Tracker Protocol was agreed in consensus to be simple, and that = other functionalities would be expressed in extended = versions.


"2. A peer may have the requirement to inform the tracker = its new
network address when the peer has changed its primary = network
attachment."

a) Isn't this the role of mobile IP? and = b) can't the base CONNECT
handle this?

[Rachel]: I think this = case is talking about the peer switches its
network address during = the streaming. For example, a peer is firstly
using WIFI to connect = to the tracker. But during the streaming, the
WIFI has problem and = the peer decides to switch to a wired network but
it doesn't want to = stop the streaming. Actually, I think the base
CONNECT can't handle = it. Because it can't "CONNECT" to the same swarm
twice, = right?


There are many IETF drafts to deal with = IP-address change, and IMHO there is no need to add another one = here.

[Rachel]: I think this case is similar to the first case, = because first case is about getting the update information from the = tracker to peer, and this one is about providing the updated information = of the peer to the tracker. So the conclusion made to the first case = could also apply to this case.

[ZONG]: I guess what Arno = mentioned is that current IETF MIP mechanisms handle IP address change = while keeping session untouched. I agree that tracker protocol should = not re-invent new MIP tech. :)) I think what Rachel stated is about = notifying new IP address to tracker using tracker protocol, which is not = handle mobility issues, right?

[CRUZ] The = obvious method relies on the STAT_REPORT request, that is issued = periodically or whenever required. When receiving such message from a = Registered Peer already tracked in one or more swarms, the tracker = updates the public IP address seen from the requesting = peer.


CU,
=     Arno
__________________________________________= _____
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp
_______________________________________________
= ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

= --Apple-Mail=_D5629012-ABEA-41DF-B358-3C8B8430567B-- From zongning@huawei.com Wed Jul 31 05:53:55 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CEA21F8F4A for ; Wed, 31 Jul 2013 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.212 X-Spam-Level: X-Spam-Status: No, score=-97.212 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BssYZJSNvCsj for ; Wed, 31 Jul 2013 05:53:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B8DD921F99B7 for ; Wed, 31 Jul 2013 05:53:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVP36512; Wed, 31 Jul 2013 12:53:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 13:53:30 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 13:53:40 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 20:53:29 +0800 From: Zongning To: Rui Cruz Thread-Topic: =?gb2312?B?W3Bwc3BdILTwuLQ6ICBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uCWZv?= =?gb2312?B?ciBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wt?= =?gb2312?Q?03.txt?= Thread-Index: AQHOjS0iSHE/8seGVE6I849HQwvH8Jl+tO6f//+BTgCAAIi7wA== Date: Wed, 31 Jul 2013 12:53:27 +0000 Message-ID: References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> <51F7A3DA.9@cs.vu.nl>, <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> , <97A629B9-1576-4878-AAC4-41C7EFE65D6C@ieee-pt.org> In-Reply-To: <97A629B9-1576-4878-AAC4-41C7EFE65D6C@ieee-pt.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.231] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667792577534Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24JZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90?= =?gb2312?b?b2NvbC0wMy50eHQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:53:55 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667792577534Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIENydXouDQoNCg0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpGcm9tOiBSdWkgQ3J1eiBbcnVpLmNydXpAaWVlZS1wdC5vcmdd DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMzEsIDIwMTMgODo0MiBQTQ0KVG86IFpvbmduaW5nDQpD YzogUnVpIENydXo7IEh1YW5neWlob25nIChSYWNoZWwpOyBhcm5vQGNzLnZ1Lm5sOyBwcHNwQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3Bwc3BdILTwuLQ6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMy50 eHQNCg0KUGxlYXNlIHJlYWQgaW5saW5lLg0KDQpSZWdhcmRzLA0KUnVpIENydXoNCg0KDQoNCk9u IDMxLzA3LzIwMTMsIGF0IDEzOjI1LCBab25nbmluZyA8em9uZ25pbmdAaHVhd2VpLmNvbTxtYWls dG86em9uZ25pbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSwgUmFjaGVsIGFuZCBBcm5vLA0K DQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogcHBzcC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwcHNwLWJvdW5jZXNA aWV0Zi5vcmc+IFtwcHNwLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBwc3AtYm91bmNlc0BpZXRm Lm9yZz5dIG9uIGJlaGFsZiBvZiBIdWFuZ3lpaG9uZyAoUmFjaGVsKSBbcmFjaGVsLmh1YW5nQGh1 YXdlaS5jb208bWFpbHRvOnJhY2hlbC5odWFuZ0BodWF3ZWkuY29tPl0NClNlbnQ6IFR1ZXNkYXks IEp1bHkgMzAsIDIwMTMgOTo0OSBQTQ0KVG86IGFybm9AY3MudnUubmw8bWFpbHRvOmFybm9AY3Mu dnUubmw+DQpDYzogcHBzcEBpZXRmLm9yZzxtYWlsdG86cHBzcEBpZXRmLm9yZz4NClN1YmplY3Q6 IFtwcHNwXSC08Li0OiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAgICBmb3IgZHJh ZnQtaHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sLTAzLnR4dA0KDQpIaSBBcm5v LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQmVzdCByZWdhcmRzLA0KUmFjaGVsDQoNCi0tLS0t 08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBBcm5vIEJha2tlciBbbWFpbHRvOmFybm9AY3MudnUubmw8 bWFpbHRvOmFybm9AY3MudnUubmw+XQ0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjMwyNUgMTk6MzENCsrV vP7IyzogSHVhbmd5aWhvbmcgKFJhY2hlbCkNCrOty806IHBwc3BAaWV0Zi5vcmc8bWFpbHRvOnBw c3BAaWV0Zi5vcmc+DQrW98ziOiBSZTogW3Bwc3BdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMy50eHQN Cg0KSGkgUmFjaGVsIGFuZCBhbGwNCg0KcGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIDMwLzA3LzIw MTMgMTI6NDMsIEh1YW5neWlob25nIChSYWNoZWwpIHdyb3RlOg0KDQoiMS4gVGhlIHBlZXIgbGlz dCBvZiBhIHNwZWNpZmljIHN3YXJtIG9idGFpbmVkIGJ5IGEgcGVlciBtYXkgYmUgb3V0IG9mDQpk YXRlIjoNCg0KSSBhbHdheXMgYXNzdW1lZCB0aGF0IHdoZW4gdGhlIGluaXRpYWwgcGVlciBsaXN0 IHJlY2VpdmVkIHZpYSB0aGUgYmFzZQ0KcHJvdG9jb2wgaXMgb3V0ZGF0ZWQsIGEgcGVlciB3b3Vs ZCBzZW5kIGEgbmV3IENPTk5FQ1QgbWVzc2FnZSB3aXRoIGENClBlZXJOdW0gYXR0cmlidXRlIHRv IGdldCBhIG5ldyBsaXN0LiBTbyB3aHkgaXMgZXh0cmEgc3VwcG9ydCBuZWVkZWQ/DQoNCltSYWNo ZWxdOiBJIHRoaW5rIHRoZSBwZWVyIHNob3VsZCBmaXJzdCBkaXNjb25uZWN0IGZyb20gdGhlIHN3 YXJtLCBhbmQNCnRoZW4gc2VuZCBhIG5ldyBDT05ORUNUIG1lc3NhZ2UgdG8gZ2V0IGEgbmV3IGxp c3QuIEFjdHVhbGx5LCBJIHRoaW5rDQp0aGlzIHByb2NlZHVyZSBpcyBtb3JlIGNvbXBsaWNhdGVk IHRoYW4gaGF2aW5nIGEgbmV3IG1lc3NhZ2UgKCBpbiB0aGlzDQpzcGVjLCB3ZSBkZWZpbmUgYSBu ZXcgbWVzc2FnZSBGSU5EKSB0byBkZWFsIHdpdGggaXQuDQoNCg0KSSBtYXkgaGF2ZSBiZWVuIG1p c3JlYWRpbmcgdGhlIGJhc2UgcHJvdG9jb2wgc3BlYyBmb3IgYSBsb25nIHRpbWUgdGhlbi4NClRh YmxlIDggb2YgdGhlIGJhc2UgcHJvdG9jb2wgaW5kZWVkIGRvZXMgbm90IGxpc3QgdGhhdCBhICJD T05ORUNUIGFjdGlvbj1qb2luIiB3aGlsZSBpbiB0cmFja2luZyBzdGF0ZSBpcyBhIHZhbGlkIHRy YW5zaXRpb24uIElNSE8sIEkgdGhpbmsgaXQgc2hvdWxkIGZvciBib3RoIExFRUNIIGFuZCBTRUVE LCByZXRyaWV2aW5nIGEgbmV3IHNldCBvZiBwZWVycyBmb3IgdGhlIHN3YXJtIHlvdSBhcmUgaW4g aXMgYmFzaWMgZnVuY3Rpb25hbGl0eS4gT3IgRklORCBtdXN0IGJlIG1vdmVkIGludG8gdGhlIGJh c2UgcHJvdG9jb2wgc3BlYy4NCg0KW1JhY2hlbF06IEFsbCByaWdodC4gTGV0J3Mgc2VlIGhvdyBp dCB3b3JrcyBpbiB0aGUgbWVldGluZy4NCg0KW1pPTkddOiBJZiBJIHJlY2FsbCBjb3JyZWN0bHks IHdlIGRlY2lkZWQgdG8ga2VlcCBiYXNlIHRyYWNrIHByb3RvY29sIHNpbXBsZSAtIHRoZSByZWFz b24gd2UgaGF2ZSBleHRlbmRlZCB0cmFja2VyIHByb3RvY29sLiBTbyB3ZSBoYXZlIGEgYmFzaWMg YW5kIHNtYWxsIHNldCBvZiBmdW5jdGlvbmFsaXRpZXMgZm9yIENPTk5FQ1QgYW5kIGRlZmluZSBv dGhlciBmdW5jdGlvbnMgaW4gb3RoZXIgbWVzc2FnZXMuIEkgdGVuZCB0byBrZWVwIEZJTkQgd2l0 aCBmdW5jdGlvbnMgc3VjaCBhcyBwZWVyIGxpc3QgdXBkYXRlIGluIGV4dGVuZGVkIGRyYWZ0IHRo ZW4uDQoNCltDUlVaXSBJIGZ1bGx5IGFncmVlIHdpdGggWm9uZy4gVGhlIEJhc2UgVHJhY2tlciBQ cm90b2NvbCB3YXMgYWdyZWVkIGluIGNvbnNlbnN1cyB0byBiZSBzaW1wbGUsIGFuZCB0aGF0IG90 aGVyIGZ1bmN0aW9uYWxpdGllcyB3b3VsZCBiZSBleHByZXNzZWQgaW4gZXh0ZW5kZWQgdmVyc2lv bnMuDQoNCg0KIjIuIEEgcGVlciBtYXkgaGF2ZSB0aGUgcmVxdWlyZW1lbnQgdG8gaW5mb3JtIHRo ZSB0cmFja2VyIGl0cyBuZXcNCm5ldHdvcmsgYWRkcmVzcyB3aGVuIHRoZSBwZWVyIGhhcyBjaGFu Z2VkIGl0cyBwcmltYXJ5IG5ldHdvcmsNCmF0dGFjaG1lbnQuIg0KDQphKSBJc24ndCB0aGlzIHRo ZSByb2xlIG9mIG1vYmlsZSBJUD8gYW5kIGIpIGNhbid0IHRoZSBiYXNlIENPTk5FQ1QNCmhhbmRs ZSB0aGlzPw0KDQpbUmFjaGVsXTogSSB0aGluayB0aGlzIGNhc2UgaXMgdGFsa2luZyBhYm91dCB0 aGUgcGVlciBzd2l0Y2hlcyBpdHMNCm5ldHdvcmsgYWRkcmVzcyBkdXJpbmcgdGhlIHN0cmVhbWlu Zy4gRm9yIGV4YW1wbGUsIGEgcGVlciBpcyBmaXJzdGx5DQp1c2luZyBXSUZJIHRvIGNvbm5lY3Qg dG8gdGhlIHRyYWNrZXIuIEJ1dCBkdXJpbmcgdGhlIHN0cmVhbWluZywgdGhlDQpXSUZJIGhhcyBw cm9ibGVtIGFuZCB0aGUgcGVlciBkZWNpZGVzIHRvIHN3aXRjaCB0byBhIHdpcmVkIG5ldHdvcmsg YnV0DQppdCBkb2Vzbid0IHdhbnQgdG8gc3RvcCB0aGUgc3RyZWFtaW5nLiBBY3R1YWxseSwgSSB0 aGluayB0aGUgYmFzZQ0KQ09OTkVDVCBjYW4ndCBoYW5kbGUgaXQuIEJlY2F1c2UgaXQgY2FuJ3Qg IkNPTk5FQ1QiIHRvIHRoZSBzYW1lIHN3YXJtDQp0d2ljZSwgcmlnaHQ/DQoNCg0KVGhlcmUgYXJl IG1hbnkgSUVURiBkcmFmdHMgdG8gZGVhbCB3aXRoIElQLWFkZHJlc3MgY2hhbmdlLCBhbmQgSU1I TyB0aGVyZSBpcyBubyBuZWVkIHRvIGFkZCBhbm90aGVyIG9uZSBoZXJlLg0KDQpbUmFjaGVsXTog SSB0aGluayB0aGlzIGNhc2UgaXMgc2ltaWxhciB0byB0aGUgZmlyc3QgY2FzZSwgYmVjYXVzZSBm aXJzdCBjYXNlIGlzIGFib3V0IGdldHRpbmcgdGhlIHVwZGF0ZSBpbmZvcm1hdGlvbiBmcm9tIHRo ZSB0cmFja2VyIHRvIHBlZXIsIGFuZCB0aGlzIG9uZSBpcyBhYm91dCBwcm92aWRpbmcgdGhlIHVw ZGF0ZWQgaW5mb3JtYXRpb24gb2YgdGhlIHBlZXIgdG8gdGhlIHRyYWNrZXIuIFNvIHRoZSBjb25j bHVzaW9uIG1hZGUgdG8gdGhlIGZpcnN0IGNhc2UgY291bGQgYWxzbyBhcHBseSB0byB0aGlzIGNh c2UuDQoNCltaT05HXTogSSBndWVzcyB3aGF0IEFybm8gbWVudGlvbmVkIGlzIHRoYXQgY3VycmVu dCBJRVRGIE1JUCBtZWNoYW5pc21zIGhhbmRsZSBJUCBhZGRyZXNzIGNoYW5nZSB3aGlsZSBrZWVw aW5nIHNlc3Npb24gdW50b3VjaGVkLiBJIGFncmVlIHRoYXQgdHJhY2tlciBwcm90b2NvbCBzaG91 bGQgbm90IHJlLWludmVudCBuZXcgTUlQIHRlY2guIDopKSBJIHRoaW5rIHdoYXQgUmFjaGVsIHN0 YXRlZCBpcyBhYm91dCBub3RpZnlpbmcgbmV3IElQIGFkZHJlc3MgdG8gdHJhY2tlciB1c2luZyB0 cmFja2VyIHByb3RvY29sLCB3aGljaCBpcyBub3QgaGFuZGxlIG1vYmlsaXR5IGlzc3Vlcywgcmln aHQ/DQoNCltDUlVaXSBUaGUgb2J2aW91cyBtZXRob2QgcmVsaWVzIG9uIHRoZSBTVEFUX1JFUE9S VCByZXF1ZXN0LCB0aGF0IGlzIGlzc3VlZCBwZXJpb2RpY2FsbHkgb3Igd2hlbmV2ZXIgcmVxdWly ZWQuIFdoZW4gcmVjZWl2aW5nIHN1Y2ggbWVzc2FnZSBmcm9tIGEgUmVnaXN0ZXJlZCBQZWVyIGFs cmVhZHkgdHJhY2tlZCBpbiBvbmUgb3IgbW9yZSBzd2FybXMsIHRoZSB0cmFja2VyIHVwZGF0ZXMg dGhlIHB1YmxpYyBJUCBhZGRyZXNzIHNlZW4gZnJvbSB0aGUgcmVxdWVzdGluZyBwZWVyLg0KDQpb Wk9OR106IFNvIEkgYXNzdW1pbmcgdGhhdCB5b3UgYXJlIGFncmVlIHdpdGggbWUgLSB3ZSBvbmx5 IGhhbmRsZSBJUCBhZGRyZXNzIHVwZGF0ZSByZXBvcnQsIHJhdGhlciB0aGFuIGRlYWxpbmcgd2l0 aCBJUCBtb2JpbGl0eSBpc3N1ZXMsIHJpZ2h0PyA6KSkNCg0KDQpDVSwNCiAgICBBcm5vDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5n IGxpc3QNCnBwc3BAaWV0Zi5vcmc8bWFpbHRvOnBwc3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3ANCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNwDQoNCg== --_000_B0D29E0424F2DE47A0B36779EC6667792577534Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Cruz.

 

Please see inline.

 

From: Rui Cruz [rui.cruz@ieee-pt.org]
Sent: Wednesday, July 31, 2013 8:42 PM
To: Zongning
Cc: Rui Cruz; Huangyihong (Rachel); arno@cs.vu.nl; ppsp@ietf.org
Subject: Re: [ppsp] =B4=F0=B8=B4: FW: New Version Notification for d= raft-huang-ppsp-extended-tracker-protocol-03.txt

Please read inline.

Regards,
Rui Cruz



On 31/07/2013, at 13:25, Zongning <zongning@huawei.com> wrote:

Hi, Rachel and Arno,

Please see inline.

________________________________________
From: ppsp-bounc= es@ietf.org [ppsp-bounces@ietf.org] on behalf of Huangyihong (Rachel) [rachel.huang@huawei.com]
Sent: Tuesday, July 30, 2013 9:49 PM
To: arno@cs.vu.nl Cc: ppsp@ietf.org Subject: [ppsp] =B4=F0=B8=B4:  FW: New Version Notification  &nbs= p;    for draft-huang-ppsp-extended-tracker-protocol-03= .txt

Hi Arno,

Please see inline.

Best regards,
Rachel

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Arno Bakker [mailto:arno@cs.vu.nl]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C230=C8=D5 19:31
=CA=D5=BC=FE=C8=CB: Huangyihong (Rachel)
=B3=AD=CB=CD: ppsp@ietf.= org
=D6=F7=CC=E2: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-= extended-tracker-protocol-03.txt

Hi Rachel and all

please see inline.

On 30/07/2013 12:43, Huangyihong (Rachel) wrote:

"1. The peer list of a specific swarm obtained by a peer may be out of=
date":

I always assumed that when the initial peer list received via the base
protocol is outdated, a peer would send a new CONNECT message with a
PeerNum attribute to get a new list. So why is extra support needed?

[Rachel]: I think the peer should first disconnect from the swarm, and
then send a new CONNECT message to get a new list. Actually, I think
this procedure is more complicated than having a new message ( in this
spec, we define a new message FIND) to deal with it.


I may have been misreading the base protocol spec for a long time then.
Table 8 of the base protocol indeed does not list that a "CONNECT acti= on=3Djoin" while in tracking state is a valid transition. IMHO, I thin= k it should for both LEECH and SEED, retrieving a new set of peers for the = swarm you are in is basic functionality. Or FIND must be moved into the base protocol spec.

[Rachel]: All right. Let's see how it works in the meeting.

[ZONG]: If I recall correctly, we decided to keep base track protocol simpl= e - the reason we have extended tracker protocol. So we have a basic and sm= all set of functionalities for CONNECT and define other functions in other = messages. I tend to keep FIND with functions such as peer list update in extended draft then.

[CRUZ] I fully agree with Zong. The Base Tracker Protocol was agreed in con= sensus to be simple, and that other functionalities would be expressed in e= xtended versions.


"2. A peer may have the requirement to infor= m the tracker its new
network address when the peer has changed its primary network
attachment."

a) Isn't this the role of mobile IP? and b) can't the base CONNECT
handle this?

[Rachel]: I think this case is talking about the peer switches its
network address during the streaming. For example, a peer is firstly
using WIFI to connect to the tracker. But during the streaming, the
WIFI has problem and the peer decides to switch to a wired network but
it doesn't want to stop the streaming. Actually, I think the base
CONNECT can't handle it. Because it can't "CONNECT" to the same s= warm
twice, right?


There are many IETF drafts to deal with IP-address change, and IMHO there i= s no need to add another one here.

[Rachel]: I think this case is similar to the first case, because first cas= e is about getting the update information from the tracker to peer, and thi= s one is about providing the updated information of the peer to the tracker= . So the conclusion made to the first case could also apply to this case.

[ZONG]: I guess what Arno mentioned is that current IETF MIP mechanisms han= dle IP address change while keeping session untouched. I agree that tracker= protocol should not re-invent new MIP tech. :)) I think what Rachel stated= is about notifying new IP address to tracker using tracker protocol, which is not handle mobility issues, ri= ght?

[CRUZ] The obvious method relies on the STAT_REPORT request, that is issued= periodically or whenever required. When receiving such message from a Regi= stered Peer already tracked in one or more swarms, the tracker updates the = public IP address seen from the requesting peer.
 
[ZONG]: So I assuming that you are agree with me - we only handle IP a= ddress update report, rather than dealing with IP mobility issues, rig= ht? :))


CU,
    Arno
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

--_000_B0D29E0424F2DE47A0B36779EC6667792577534Dnkgeml501mbschi_-- From rui.cruz@ieee-pt.org Wed Jul 31 06:03:08 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26421F9EF0 for ; Wed, 31 Jul 2013 06:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=-1.546, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuUxhPMAk8WV for ; Wed, 31 Jul 2013 06:03:03 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 29ADD11E8177 for ; Wed, 31 Jul 2013 06:02:56 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so576308wes.4 for ; Wed, 31 Jul 2013 06:02:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Rp3vwJmM8JeWOHlOs8Rxg+uk6H8HNP2lOfkmkrt2YpU=; b=KwE/KVml6Eq2FBc+MSa19HIezuX38/+YK+wrMQDZgxFEPj2qQhXovXSurAKCsDtOUv pko81/quAzQdfnbRjl0na3UaRufXlZEgXvkHPvi6wnm6FBruRWBSk/YK8tE2Ls4jJmBx oIkvZ5rr+1bCnLbdyXJ286wqe4RPfaIN1eBJEHIqc9zlpePjEA0mhWwlBg/TUKbMuXN7 FYVYX2o3toSOAyqCvlJ/53ZKCNskexPSg4Oam3QsI7lU44K7jcisBg0Mxj6v3PMNqN3t A8+ANFVG3eYTP+vNxlygvKdzgTaZZbFaQTF2hWu7ddB7kwNtWymxfSR0Vv5jB0oakzs5 Ly2g== X-Received: by 10.180.36.74 with SMTP id o10mr4195932wij.23.1375275773954; Wed, 31 Jul 2013 06:02:53 -0700 (PDT) Received: from [192.168.1.216] ([89.180.107.19]) by mx.google.com with ESMTPSA id a8sm5517794wie.6.2013.07.31.06.02.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 06:02:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB1AFA53-F3D8-4CE5-9614-175C51D47311" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Rui Cruz In-Reply-To: Date: Wed, 31 Jul 2013 14:02:49 +0100 Message-Id: References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> <51F7A3DA.9@cs.vu.nl>, <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> , <97A629B9-1576-4878-AAC4-41C7EFE65D6C@ieee-pt.org> To: Zongning X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQki7x6mKXQpGJno/AMcd4CW1TJ0n18yYX77Cbqzv16rqWX960Zr61ie0gReVu/UlUApEDk8 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?utf-8?b?562U5aSNOiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv?= =?utf-8?q?n=09for_draft-huang-ppsp-extended-tracker-protocol-03=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:03:08 -0000 --Apple-Mail=_DB1AFA53-F3D8-4CE5-9614-175C51D47311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On 31/07/2013, at 13:53, Zongning wrote: > Hi, Cruz. > =20 > Please see inline. > =20 > From: Rui Cruz [rui.cruz@ieee-pt.org] > Sent: Wednesday, July 31, 2013 8:42 PM > To: Zongning > Cc: Rui Cruz; Huangyihong (Rachel); arno@cs.vu.nl; ppsp@ietf.org > Subject: Re: [ppsp] =B4=F0=B8=B4: FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt >=20 > Please read inline. >=20 > Regards, > Rui Cruz >=20 >=20 >=20 > On 31/07/2013, at 13:25, Zongning wrote: >=20 >> Hi, Rachel and Arno, >>=20 >> Please see inline. >>=20 >> ________________________________________ >> From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of = Huangyihong (Rachel) [rachel.huang@huawei.com] >> Sent: Tuesday, July 30, 2013 9:49 PM >> To: arno@cs.vu.nl >> Cc: ppsp@ietf.org >> Subject: [ppsp] =B4=F0=B8=B4: FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt >>=20 >> Hi Arno, >>=20 >> Please see inline. >>=20 >> Best regards, >> Rachel >>=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Arno Bakker [mailto:arno@cs.vu.nl] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C230=C8=D5 19:31 >> =CA=D5=BC=FE=C8=CB: Huangyihong (Rachel) >> =B3=AD=CB=CD: ppsp@ietf.org >> =D6=F7=CC=E2: Re: [ppsp] FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt >>=20 >> Hi Rachel and all >>=20 >> please see inline. >>=20 >> On 30/07/2013 12:43, Huangyihong (Rachel) wrote: >>>=20 >>> "1. The peer list of a specific swarm obtained by a peer may be out = of >>> date": >>>=20 >>> I always assumed that when the initial peer list received via the = base >>> protocol is outdated, a peer would send a new CONNECT message with a >>> PeerNum attribute to get a new list. So why is extra support needed? >>>=20 >>> [Rachel]: I think the peer should first disconnect from the swarm, = and >>> then send a new CONNECT message to get a new list. Actually, I think >>> this procedure is more complicated than having a new message ( in = this >>> spec, we define a new message FIND) to deal with it. >>>=20 >>=20 >> I may have been misreading the base protocol spec for a long time = then. >> Table 8 of the base protocol indeed does not list that a "CONNECT = action=3Djoin" while in tracking state is a valid transition. IMHO, I = think it should for both LEECH and SEED, retrieving a new set of peers = for the swarm you are in is basic functionality. Or FIND must be moved = into the base protocol spec. >>=20 >> [Rachel]: All right. Let's see how it works in the meeting. >>=20 >> [ZONG]: If I recall correctly, we decided to keep base track protocol = simple - the reason we have extended tracker protocol. So we have a = basic and small set of functionalities for CONNECT and define other = functions in other messages. I tend to keep FIND with functions such as = peer list update in extended draft then. >=20 > [CRUZ] I fully agree with Zong. The Base Tracker Protocol was agreed = in consensus to be simple, and that other functionalities would be = expressed in extended versions. >=20 >>=20 >>> "2. A peer may have the requirement to inform the tracker its new >>> network address when the peer has changed its primary network >>> attachment." >>>=20 >>> a) Isn't this the role of mobile IP? and b) can't the base CONNECT >>> handle this? >>>=20 >>> [Rachel]: I think this case is talking about the peer switches its >>> network address during the streaming. For example, a peer is firstly >>> using WIFI to connect to the tracker. But during the streaming, the >>> WIFI has problem and the peer decides to switch to a wired network = but >>> it doesn't want to stop the streaming. Actually, I think the base >>> CONNECT can't handle it. Because it can't "CONNECT" to the same = swarm >>> twice, right? >>>=20 >>=20 >> There are many IETF drafts to deal with IP-address change, and IMHO = there is no need to add another one here. >>=20 >> [Rachel]: I think this case is similar to the first case, because = first case is about getting the update information from the tracker to = peer, and this one is about providing the updated information of the = peer to the tracker. So the conclusion made to the first case could also = apply to this case. >>=20 >> [ZONG]: I guess what Arno mentioned is that current IETF MIP = mechanisms handle IP address change while keeping session untouched. I = agree that tracker protocol should not re-invent new MIP tech. :)) I = think what Rachel stated is about notifying new IP address to tracker = using tracker protocol, which is not handle mobility issues, right? >=20 > [CRUZ] The obvious method relies on the STAT_REPORT request, that is = issued periodically or whenever required. When receiving such message = from a Registered Peer already tracked in one or more swarms, the = tracker updates the public IP address seen from the requesting peer. > =20 > [ZONG]: So I assuming that you are agree with me - we only handle IP = address update report, rather than dealing with IP mobility issues, = right? :)) [CRUZ] Yes, that is correct. >=20 >>=20 >> CU, >> Arno >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_DB1AFA53-F3D8-4CE5-9614-175C51D47311 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

On = 31/07/2013, at 13:53, Zongning <zongning@huawei.com> = wrote:

Hi, Cruz.

Please = see inline.

From: Rui Cruz [rui.cruz@ieee-pt.org]
Sent:=  Wednesday, July = 31, 2013 8:42 PM
To: Zongning
Cc: Rui Cruz; Huangyihong = (Rachel); arno@cs.vu.nl; ppsp@ietf.org
Subject: Re: [ppsp] =B4=F0=B8=B4: = FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt

Please read inline.

Regards,
Rui = Cruz



On 31/07/2013, at 13:25, = Zongning <zongning@huawei.com> wrote:

Hi, Rachel = and Arno,

Please see = inline.

________________________________________
From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of Huangyihong = (Rachel) [rachel.huang@huawei.com]
Sent: Tuesday, July = 30, 2013 9:49 PM
To: arno@cs.vu.nl
Cc: ppsp@ietf.org
Subject: [ppsp] =B4=F0=B8=B4: =  FW: New Version Notification =       for = draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi = Arno,

Please see inline.

Best = regards,
Rachel

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE= =C8=CB: Arno Bakker [mailto:arno@cs.vu.nl]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2013=C4=EA7=D4=C230=C8=D5 19:31
=CA=D5=BC=FE=C8=CB: Huangyihong = (Rachel)
=B3=AD=CB=CD: ppsp@ietf.org
=D6=F7= =CC=E2: Re: [ppsp] FW: New Version Notification for = draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel and = all

please see inline.

On 30/07/2013 12:43, Huangyihong = (Rachel) wrote:

"1. The peer list of a = specific swarm obtained by a peer may be out of
date":

I = always assumed that when the initial peer list received via the = base
protocol is outdated, a peer would send a new CONNECT message = with a
PeerNum attribute to get a new list. So why is extra support = needed?

[Rachel]: I think the peer should first disconnect from = the swarm, and
then send a new CONNECT message to get a new list. = Actually, I think
this procedure is more complicated than having a = new message ( in this
spec, we define a new message FIND) to deal = with it.


I may have been misreading the base = protocol spec for a long time then.
Table 8 of the base protocol = indeed does not list that a "CONNECT action=3Djoin" while in tracking = state is a valid transition. IMHO, I think it should for both LEECH and = SEED, retrieving a new set of peers for the swarm you are in is basic = functionality. Or FIND must be moved into the base protocol = spec.

[Rachel]: All right. Let's see how it works in the = meeting.

[ZONG]: If I recall correctly, we decided to keep base = track protocol simple - the reason we have extended tracker protocol. So = we have a basic and small set of functionalities for CONNECT and define = other functions in other messages. I tend to keep FIND with functions = such as peer list update in extended draft = then.

[CRUZ] I fully agree with Zong. The = Base Tracker Protocol was agreed in consensus to be simple, and that = other functionalities would be expressed in extended = versions.


"2. A peer may have the requirement to inform the tracker = its new
network address when the peer has changed its primary = network
attachment."

a) Isn't this the role of mobile IP? and = b) can't the base CONNECT
handle this?

[Rachel]: I think this = case is talking about the peer switches its
network address during = the streaming. For example, a peer is firstly
using WIFI to connect = to the tracker. But during the streaming, the
WIFI has problem and = the peer decides to switch to a wired network but
it doesn't want to = stop the streaming. Actually, I think the base
CONNECT can't handle = it. Because it can't "CONNECT" to the same swarm
twice, = right?


There are many IETF drafts to deal with = IP-address change, and IMHO there is no need to add another one = here.

[Rachel]: I think this case is similar to the first case, = because first case is about getting the update information from the = tracker to peer, and this one is about providing the updated information = of the peer to the tracker. So the conclusion made to the first case = could also apply to this case.

[ZONG]: I guess what Arno = mentioned is that current IETF MIP mechanisms handle IP address change = while keeping session untouched. I agree that tracker protocol should = not re-invent new MIP tech. :)) I think what Rachel stated is about = notifying new IP address to tracker using tracker protocol, which is not = handle mobility issues, right?

[CRUZ] The = obvious method relies on the STAT_REPORT request, that is issued = periodically or whenever required. When receiving such message from a = Registered Peer already tracked in one or more swarms, the tracker = updates the public IP address seen from the requesting = peer.
 
[ZONG]: So I assuming that you are = agree with me - we only handle IP address update report, rather = than dealing with IP mobility issues, right? = :))

[CRUZ] = Yes, that is correct.

CU,
    Arno
_________________= ______________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp
______________________________________________= _
ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

= --Apple-Mail=_DB1AFA53-F3D8-4CE5-9614-175C51D47311-- From rachel.huang@huawei.com Wed Jul 31 06:34:33 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55821F9ED1 for ; Wed, 31 Jul 2013 06:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-2.890, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEKpTOegWPa0 for ; Wed, 31 Jul 2013 06:34:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2B21F9E99 for ; Wed, 31 Jul 2013 06:34:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATY87364; Wed, 31 Jul 2013 13:34:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 14:33:41 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 14:33:51 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 21:33:41 +0800 From: "Huangyihong (Rachel)" To: Zongning , "arno@cs.vu.nl" Thread-Topic: =?gb2312?B?W3Bwc3BdILTwuLQ6ICBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uCWZv?= =?gb2312?B?ciBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wt?= =?gb2312?Q?03.txt?= Thread-Index: AQHOjekLk+kQxR5c7E2UaldvnLHdfpl+yEjg Date: Wed, 31 Jul 2013 13:33:39 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4585B39D@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <51F78163.8050605@cs.vu.nl> <51E6A56BD6A85142B9D172C87FC3ABBB4585ACAC@nkgeml501-mbs.china.huawei.com> <51F7A3DA.9@cs.vu.nl>, <51E6A56BD6A85142B9D172C87FC3ABBB4585AE31@nkgeml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.170.57] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ppsp@ietf.org" Subject: [ppsp] =?gb2312?b?tPC4tDogILTwuLQ6ICBGVzogTmV3IFZlcnNpb24gTm90?= =?gb2312?b?aWZpY2F0aW9uCWZvciBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNr?= =?gb2312?b?ZXItcHJvdG9jb2wtMDMudHh0?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:34:33 -0000 SGkgTmluZywNCg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBab25nbmluZyANCrei y83KsbzkOiAyMDEzxOo31MIzMcjVIDIwOjI1DQrK1bz+yMs6IEh1YW5neWlob25nIChSYWNoZWwp OyBhcm5vQGNzLnZ1Lm5sDQqzrcvNOiBwcHNwQGlldGYub3JnDQrW98ziOiBSRTogW3Bwc3BdILTw uLQ6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0 ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMy50eHQNCg0KSGksIFJhY2hlbCBhbmQgQXJubywNCg0K UGxlYXNlIHNlZSBpbmxpbmUuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbcHBzcC1ib3VuY2VzQGlldGYub3Jn XSBvbiBiZWhhbGYgb2YgSHVhbmd5aWhvbmcgKFJhY2hlbCkgW3JhY2hlbC5odWFuZ0BodWF3ZWku Y29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAzMCwgMjAxMyA5OjQ5IFBNDQpUbzogYXJub0Bjcy52 dS5ubA0KQ2M6IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFtwcHNwXSC08Li0OiAgRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAgICBmb3IgZHJhZnQtaHVhbmctcHBzcC1leHRlbmRlZC10 cmFja2VyLXByb3RvY29sLTAzLnR4dA0KDQpIaSBBcm5vLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4N Cg0KQmVzdCByZWdhcmRzLA0KUmFjaGVsDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBB cm5vIEJha2tlciBbbWFpbHRvOmFybm9AY3MudnUubmxdDQq3osvNyrG85DogMjAxM8TqN9TCMzDI 1SAxOTozMQ0KytW8/sjLOiBIdWFuZ3lpaG9uZyAoUmFjaGVsKQ0Ks63LzTogcHBzcEBpZXRmLm9y Zw0K1vfM4jogUmU6IFtwcHNwXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wtMDMudHh0DQoNCkhpIFJhY2hl bCBhbmQgYWxsDQoNCnBsZWFzZSBzZWUgaW5saW5lLg0KDQpPbiAzMC8wNy8yMDEzIDEyOjQzLCBI dWFuZ3lpaG9uZyAoUmFjaGVsKSB3cm90ZToNCj4NCj4gIjEuIFRoZSBwZWVyIGxpc3Qgb2YgYSBz cGVjaWZpYyBzd2FybSBvYnRhaW5lZCBieSBhIHBlZXIgbWF5IGJlIG91dCBvZg0KPiBkYXRlIjoN Cj4NCj4gSSBhbHdheXMgYXNzdW1lZCB0aGF0IHdoZW4gdGhlIGluaXRpYWwgcGVlciBsaXN0IHJl Y2VpdmVkIHZpYSB0aGUgYmFzZSANCj4gcHJvdG9jb2wgaXMgb3V0ZGF0ZWQsIGEgcGVlciB3b3Vs ZCBzZW5kIGEgbmV3IENPTk5FQ1QgbWVzc2FnZSB3aXRoIGEgDQo+IFBlZXJOdW0gYXR0cmlidXRl IHRvIGdldCBhIG5ldyBsaXN0LiBTbyB3aHkgaXMgZXh0cmEgc3VwcG9ydCBuZWVkZWQ/DQo+DQo+ IFtSYWNoZWxdOiBJIHRoaW5rIHRoZSBwZWVyIHNob3VsZCBmaXJzdCBkaXNjb25uZWN0IGZyb20g dGhlIHN3YXJtLCBhbmQgDQo+IHRoZW4gc2VuZCBhIG5ldyBDT05ORUNUIG1lc3NhZ2UgdG8gZ2V0 IGEgbmV3IGxpc3QuIEFjdHVhbGx5LCBJIHRoaW5rIA0KPiB0aGlzIHByb2NlZHVyZSBpcyBtb3Jl IGNvbXBsaWNhdGVkIHRoYW4gaGF2aW5nIGEgbmV3IG1lc3NhZ2UgKCBpbiB0aGlzIA0KPiBzcGVj LCB3ZSBkZWZpbmUgYSBuZXcgbWVzc2FnZSBGSU5EKSB0byBkZWFsIHdpdGggaXQuDQo+DQoNCkkg bWF5IGhhdmUgYmVlbiBtaXNyZWFkaW5nIHRoZSBiYXNlIHByb3RvY29sIHNwZWMgZm9yIGEgbG9u ZyB0aW1lIHRoZW4uDQpUYWJsZSA4IG9mIHRoZSBiYXNlIHByb3RvY29sIGluZGVlZCBkb2VzIG5v dCBsaXN0IHRoYXQgYSAiQ09OTkVDVCBhY3Rpb249am9pbiIgd2hpbGUgaW4gdHJhY2tpbmcgc3Rh dGUgaXMgYSB2YWxpZCB0cmFuc2l0aW9uLiBJTUhPLCBJIHRoaW5rIGl0IHNob3VsZCBmb3IgYm90 aCBMRUVDSCBhbmQgU0VFRCwgcmV0cmlldmluZyBhIG5ldyBzZXQgb2YgcGVlcnMgZm9yIHRoZSBz d2FybSB5b3UgYXJlIGluIGlzIGJhc2ljIGZ1bmN0aW9uYWxpdHkuIE9yIEZJTkQgbXVzdCBiZSBt b3ZlZCBpbnRvIHRoZSBiYXNlIHByb3RvY29sIHNwZWMuDQoNCltSYWNoZWxdOiBBbGwgcmlnaHQu IExldCdzIHNlZSBob3cgaXQgd29ya3MgaW4gdGhlIG1lZXRpbmcuDQoNCltaT05HXTogSWYgSSBy ZWNhbGwgY29ycmVjdGx5LCB3ZSBkZWNpZGVkIHRvIGtlZXAgYmFzZSB0cmFjayBwcm90b2NvbCBz aW1wbGUgLSB0aGUgcmVhc29uIHdlIGhhdmUgZXh0ZW5kZWQgdHJhY2tlciBwcm90b2NvbC4gU28g d2UgaGF2ZSBhIGJhc2ljIGFuZCBzbWFsbCBzZXQgb2YgZnVuY3Rpb25hbGl0aWVzIGZvciBDT05O RUNUIGFuZCBkZWZpbmUgb3RoZXIgZnVuY3Rpb25zIGluIG90aGVyIG1lc3NhZ2VzLiBJIHRlbmQg dG8ga2VlcCBGSU5EIHdpdGggZnVuY3Rpb25zIHN1Y2ggYXMgcGVlciBsaXN0IHVwZGF0ZSBpbiBl eHRlbmRlZCBkcmFmdCB0aGVuLg0KDQo+ICIyLiBBIHBlZXIgbWF5IGhhdmUgdGhlIHJlcXVpcmVt ZW50IHRvIGluZm9ybSB0aGUgdHJhY2tlciBpdHMgbmV3IA0KPiBuZXR3b3JrIGFkZHJlc3Mgd2hl biB0aGUgcGVlciBoYXMgY2hhbmdlZCBpdHMgcHJpbWFyeSBuZXR3b3JrIA0KPiBhdHRhY2htZW50 LiINCj4NCj4gYSkgSXNuJ3QgdGhpcyB0aGUgcm9sZSBvZiBtb2JpbGUgSVA/IGFuZCBiKSBjYW4n dCB0aGUgYmFzZSBDT05ORUNUIA0KPiBoYW5kbGUgdGhpcz8NCj4NCj4gW1JhY2hlbF06IEkgdGhp bmsgdGhpcyBjYXNlIGlzIHRhbGtpbmcgYWJvdXQgdGhlIHBlZXIgc3dpdGNoZXMgaXRzIA0KPiBu ZXR3b3JrIGFkZHJlc3MgZHVyaW5nIHRoZSBzdHJlYW1pbmcuIEZvciBleGFtcGxlLCBhIHBlZXIg aXMgZmlyc3RseSANCj4gdXNpbmcgV0lGSSB0byBjb25uZWN0IHRvIHRoZSB0cmFja2VyLiBCdXQg ZHVyaW5nIHRoZSBzdHJlYW1pbmcsIHRoZSANCj4gV0lGSSBoYXMgcHJvYmxlbSBhbmQgdGhlIHBl ZXIgZGVjaWRlcyB0byBzd2l0Y2ggdG8gYSB3aXJlZCBuZXR3b3JrIGJ1dCANCj4gaXQgZG9lc24n dCB3YW50IHRvIHN0b3AgdGhlIHN0cmVhbWluZy4gQWN0dWFsbHksIEkgdGhpbmsgdGhlIGJhc2Ug DQo+IENPTk5FQ1QgY2FuJ3QgaGFuZGxlIGl0LiBCZWNhdXNlIGl0IGNhbid0ICJDT05ORUNUIiB0 byB0aGUgc2FtZSBzd2FybSANCj4gdHdpY2UsIHJpZ2h0Pw0KPg0KDQpUaGVyZSBhcmUgbWFueSBJ RVRGIGRyYWZ0cyB0byBkZWFsIHdpdGggSVAtYWRkcmVzcyBjaGFuZ2UsIGFuZCBJTUhPIHRoZXJl IGlzIG5vIG5lZWQgdG8gYWRkIGFub3RoZXIgb25lIGhlcmUuDQoNCltSYWNoZWxdOiBJIHRoaW5r IHRoaXMgY2FzZSBpcyBzaW1pbGFyIHRvIHRoZSBmaXJzdCBjYXNlLCBiZWNhdXNlIGZpcnN0IGNh c2UgaXMgYWJvdXQgZ2V0dGluZyB0aGUgdXBkYXRlIGluZm9ybWF0aW9uIGZyb20gdGhlIHRyYWNr ZXIgdG8gcGVlciwgYW5kIHRoaXMgb25lIGlzIGFib3V0IHByb3ZpZGluZyB0aGUgdXBkYXRlZCBp bmZvcm1hdGlvbiBvZiB0aGUgcGVlciB0byB0aGUgdHJhY2tlci4gU28gdGhlIGNvbmNsdXNpb24g bWFkZSB0byB0aGUgZmlyc3QgY2FzZSBjb3VsZCBhbHNvIGFwcGx5IHRvIHRoaXMgY2FzZS4NCg0K W1pPTkddOiBJIGd1ZXNzIHdoYXQgQXJubyBtZW50aW9uZWQgaXMgdGhhdCBjdXJyZW50IElFVEYg TUlQIG1lY2hhbmlzbXMgaGFuZGxlIElQIGFkZHJlc3MgY2hhbmdlIHdoaWxlIGtlZXBpbmcgc2Vz c2lvbiB1bnRvdWNoZWQuIEkgYWdyZWUgdGhhdCB0cmFja2VyIHByb3RvY29sIHNob3VsZCBub3Qg cmUtaW52ZW50IG5ldyBNSVAgdGVjaC4gOikpIEkgdGhpbmsgd2hhdCBSYWNoZWwgc3RhdGVkIGlz IGFib3V0IG5vdGlmeWluZyBuZXcgSVAgYWRkcmVzcyB0byB0cmFja2VyIHVzaW5nIHRyYWNrZXIg cHJvdG9jb2wsIHdoaWNoIGlzIG5vdCBoYW5kbGUgbW9iaWxpdHkgaXNzdWVzLCByaWdodD8NCg0K W1JhY2hlbF06IHllcCwgbm90IG1vYmlsaXR5IGlzc3Vlcy4gSXQncyBqdXN0IGFib3V0IHRoZSB1 cGRhdGVkIGluZm9ybWF0aW9uIG9mIHBlZXIgc2hvdWxkIGJlIG5vdGlmaWVkIHRvIHRoZSB0cmFj a2VyLiBJdCBzZWVtcyB0aGUgYmFzZSB0cmFja2VyIHByb3RvY29sIGFscmVhZHkgaGFzIHRoZSBh YmlsaXR5IHRvIGRvIHN1Y2ggdGhpbmcuIFNvIEknbSBva2F5IHRvIHJlbW92ZSB0aGlzIGlzc3Vl IG91dCBvZiB0aGUgZXh0ZW5kZWQgdHJhY2tlciBwcm90b2NvbC4NCg0KQ1UsDQogICAgIEFybm8N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1h aWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wcHNwDQo= From wes@mti-systems.com Wed Jul 31 08:48:02 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966DD21F9C78 for ; Wed, 31 Jul 2013 08:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs+riYssth-7 for ; Wed, 31 Jul 2013 08:47:55 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8F21F935A for ; Wed, 31 Jul 2013 08:47:55 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6VFlsMH002652 for ; Wed, 31 Jul 2013 11:47:54 -0400 Received: (qmail 31298 invoked by uid 0); 31 Jul 2013 15:47:54 -0000 X-TCPREMOTEIP: 130.129.18.105 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?130.129.18.105?) (wes@mti-systems.com@130.129.18.105) by 0 with ESMTPA; 31 Jul 2013 15:47:54 -0000 Message-ID: <51F93161.10801@mti-systems.com> Date: Wed, 31 Jul 2013 11:46:41 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "ppsp@ietf.org" Content-Type: multipart/mixed; boundary="------------030608080108010602040405" Subject: [ppsp] minutes from meeting X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:48:02 -0000 This is a multi-part message in MIME format. --------------030608080108010602040405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here are the minutes I took today. -- Wes Eddy MTI Systems --------------030608080108010602040405 Content-Type: text/plain; charset=windows-1252; name="ppsp-ietf87.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ppsp-ietf87.txt" PPSP @ IETF 87 WG Chairs presented on status - first RFC on problem statement was published - peer protocol getting ready for IESG review Arno Bakker presented on the peer protocol (PPSPP) - discussed updates since IETF 85 (3 revisions) - still addressing AD review points now - reviewed basic set of messages (about 3 new people in room asked for this) - Merkle hash trees are mandatory - LEDBAT as congestion control - no formal protocol message definition (to be added) - removing implicit use of default values - introduced concept of channels - discussed live-streaming integrity protection - much discussion about chuck size and MTU - no way to discover MTU - default chunk size intended not to cause fragmentation - Wes suggests looking at PLPMTUD - not sure it's necessary though - Michael T. suggests that there's per-peer state to track for this Dave C. presented on implementation he's been doing - BitTorrent didn't seem like what he needed for work with CouchDB - talked about CouchDB replication using P2P - PPSP looks like a match - implementing in Erlang/OTP - good for low-latency + cuncurrency - parser code matches the spec really well - Martin asked about whether LEDBAT is implemented? - answer - NO, doesn't feel it's needed here, doesn't use UDP, uses a native Erlang cluster protocol Ning Z summarized the status on the PPSP survey draft - asked about next steps - already had a WGLC, substantial modifications, chairs would like to proceed with the AD review after a couple of weeks Lingli D. gave presentation on the latest tracker protocol draft - Arno commented that it's explained in person much better than in draft - binary versus text encodings are still confusing (multiple comments Arno & Martin) - fitting in a single TCP packet comment is confusing - Arno - base protocol doesn't allow a refresh after initial exchange - BitTorrent allows new peer lists, PPSP base protocol should - peer can contact the tracker after registered, it is true that base protocol doesn't allow getting a fresh peer list, desire was to keep as simple as possible - Arno does not agree, and he was one of original proponents to simplify tracker - Martin supports what Arno said - Dave gave the same feedback - Stefano called consensus to put this back - Martin asked about HTTP/2.0 ... Rui had mentioned this ... agreement that it doesn't make sense Rachel H. presented on extended tracker protocol - discussed motivations - Arno questions whether some functionalities should be included in any tracker protocol - switching connections / mobility is out of scope - Dave asked about whether these issues are all special cases of a peer no longer being available - overview of extended tracker protocol - enhancement of 2 messages + 2 optional messages - Martin asked if there was a requirement that peer for FIND be a leecher - seeder does not have peer list information - will take this to list - Arno has specifically asked about this in the past - Rui on webex seems to agree to allow seeders to requiest peer list - Stefano asked if WG believes functions present in base & extended tracker protocols are okay? - Stefano thinks maybe it needs a little more work - Ning agrees with need to check current alignment of functions - Was ability to get peer list updates the only issue? is deeper review needed? - Ricardo P. thinks base protocol should just get peers (no register) - Arno is fine with base, given the addition of peer list refresh Lingli D. discussed bloom fliter for chunk availability compression - uncompressed bitmap can be several KB and frequently exchanged - Ricardo does not think this is a problem : the peer protocol does not use bitmaps - Arno suggests looking at average case and not worst case - Lingli says worst case is relevant to operators - Ricardo says it has to do with fragmentation and there's tendency to move too much responsibility to the tracker - Lingli is focusing mainly on tracker ... but it has to communicate with peer - problem is only applicable to partial caches with holes, not to full caches that would be seeders or cases where continuous ranges are cached - Ricardo agrees transmission of bitmaps has been a problem - even though inefficient, it proved to work - in streaming you have contiguous range, and don't need to send entire bitmap - normally tracker communication is not as frequent as peer - only requirement should be for tracker to give list of peers - Dave thinks someone somewhere is keeping state; it is expensive, need to make it clear where this is done and also if the window of interest is sliding along (like with video) there's less of an issue - Stefano suggests to take this to the mailing list before deciding; discuss if there is data that can help in determining --------------030608080108010602040405-- From hishigh@gmail.com Wed Jul 31 23:55:15 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D7021F9D8A for ; Wed, 31 Jul 2013 23:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prrXyGoOorYp for ; Wed, 31 Jul 2013 23:55:15 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1257C21F9D83 for ; Wed, 31 Jul 2013 23:55:14 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n12so3489443oag.39 for ; Wed, 31 Jul 2013 23:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KqI1BeZGRg05//RORNFeVUoo6PBbtz6ICXOW30ZGll4=; b=Q76lm438amlIKP1BK4uNoydm6tLfdhxvOrLTfNMCE0DFDRzXTf99LwGuHRDfjbhxgg pLRNJzWWb8DhudT3X3soXAx9IXsaKkdnoWxp2dpp6Z3iNEbHBKQcotsavRCmbthN2w1w wq+AeaUtnN9GnNqVeexzxynrofy/wmxls8O8qJmPLwdPB4a4kGZOkfEWjMUNCoSkvpDr 6hcGwlPu+QFYo34SW/wWuWguLh+VQPvDzHRoXKrKH05qfQ6kXWmoXEXvMsAFOlzor7nd +PDv1VP0O+1wl5p99SfZVREGa5IHqJZb4BZs/xhf2p0bjInpi8j3+gDchTG/7Te8M5LV MdQw== MIME-Version: 1.0 X-Received: by 10.182.199.74 with SMTP id ji10mr31840obc.69.1375340114551; Wed, 31 Jul 2013 23:55:14 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Wed, 31 Jul 2013 23:55:14 -0700 (PDT) In-Reply-To: <51F93161.10801@mti-systems.com> References: <51F93161.10801@mti-systems.com> Date: Thu, 1 Aug 2013 14:55:14 +0800 Message-ID: From: yunfei zhang To: Wesley Eddy Content-Type: multipart/alternative; boundary=e89a8ff1c024f92aa904e2dd52ca Cc: "ppsp@ietf.org" Subject: Re: [ppsp] minutes from meeting X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:55:15 -0000 --e89a8ff1c024f92aa904e2dd52ca Content-Type: text/plain; charset=ISO-8859-1 Thanks Wes for taking the notes . Yunfei 2013/7/31 Wesley Eddy > Here are the minutes I took today. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > --e89a8ff1c024f92aa904e2dd52ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Wes for taking the notes=A0.
=A0
Yunfei


2013/7/31 Wesley Eddy <wes@mti-systems.com>
Here are the minutes I took today.

--
Wes Eddy
MTI Systems

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp


--e89a8ff1c024f92aa904e2dd52ca--