From internet-drafts@ietf.org Tue May 1 19:44:10 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570D21E80AB; Tue, 1 May 2012 19:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZqSC1LD8LZCI; Tue, 1 May 2012 19:44:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9D21E8011; Tue, 1 May 2012 19:44:09 -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.02 Message-ID: <20120502024409.10841.10865.idtracker@ietfa.amsl.com> Date: Tue, 01 May 2012 19:44:09 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 02:44:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architecture for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-13.txt Pages : 29 Date : 2012-05-01 This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guideline established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ From magnus.westerlund@ericsson.com Wed May 2 07:34:29 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B9521F862B for ; Wed, 2 May 2012 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.136 X-Spam-Level: X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 WYqR0K23aC12 for ; Wed, 2 May 2012 07:34:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8186221F85D9 for ; Wed, 2 May 2012 07:34:28 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-92-4fa145f3e5a7 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FE.60.26681.3F541AF4; Wed, 2 May 2012 16:34:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 16:34:26 +0200 Message-ID: <4FA145F2.9060601@ericsson.com> Date: Wed, 2 May 2012 16:34:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: avt@ietf.org References: <20120418035830.6280.33835.idtracker@ietfa.amsl.com> <4F96A6FF.3000302@ericsson.com> In-Reply-To: <4F96A6FF.3000302@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 14:34:29 -0000 On 2012-04-24 15:13, Magnus Westerlund wrote: > WG, Colin and Charles > > This version intends to address the WG last call comments. I would > recommend that people review the changes. I will give people a week to > review this. Please provide any feedback on the changes no later than > 1st of May. The time is up for comments. I have prepared a write-up for the document, but I am awaiting confirmation from the authors that IPR disclosure that is required by BCP78 and BCP79 has been done. I will try to remember to do this earlier in parallel with the WG last call in the future. I will send out the writeup when I request publication. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu May 3 07:09:04 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C003221F84C2 for ; Thu, 3 May 2012 07:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 JVIipnrVNDq9 for ; Thu, 3 May 2012 07:09:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 06D8F21F8494 for ; Thu, 3 May 2012 07:09:03 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-7a-4fa2917f2f71 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.5A.03534.F7192AF4; Thu, 3 May 2012 16:09:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 16:09:02 +0200 Message-ID: <4FA2917D.4040608@ericsson.com> Date: Thu, 3 May 2012 16:09:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Publication Requested for draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:09:04 -0000 WG, I have now requested publication for Informational RFC for draft-ietf-avtcore-monarch-13. The writeup is available here: https://datatracker.ietf.org/wg/avtcore/management/shepherds/draft-ietf-avtcore-monarch/writeup/ Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kevin.gross@avanw.com Sat May 5 21:17:45 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18D421F84FB for ; Sat, 5 May 2012 21:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.354 X-Spam-Level: X-Spam-Status: No, score=0.354 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 an4-LvCuFTBL for ; Sat, 5 May 2012 21:17:44 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 9F27421F84EB for ; Sat, 5 May 2012 21:17:44 -0700 (PDT) Received: (qmail 681 invoked by uid 0); 6 May 2012 04:17:42 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy3.bluehost.com with SMTP; 6 May 2012 04:17:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=ZlZcgk/2yGqASkouecS4kGjZIYRISp8FRG40YPa3E8A=; b=Pg8edL+ZLoTx7KDyayFX17l+ngKyKUJm34xz2vr+mJi7jjWNAraHOdC7daHSdQ5fD5b99AyMQ1Ko5jkL9X/l5Jw9WjdrmlokIQVuTIEdKe4BvH7Z1j+Sam7ebfxih311; Received: from mail-wg0-f44.google.com ([74.125.82.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SQsuk-0002I9-2W for avt@ietf.org; Sat, 05 May 2012 22:17:42 -0600 Received: by wgbdr13 with SMTP id dr13so2739020wgb.13 for ; Sat, 05 May 2012 21:17:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.85.70 with SMTP id f6mr25183868wiz.5.1336277860682; Sat, 05 May 2012 21:17:40 -0700 (PDT) Received: by 10.223.88.140 with HTTP; Sat, 5 May 2012 21:17:40 -0700 (PDT) In-Reply-To: <4F980E4D.1040205@ericsson.com> References: <4F980E4D.1040205@ericsson.com> Date: Sat, 5 May 2012 22:17:40 -0600 Message-ID: From: Kevin Gross To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d04182558350b0404bf566f42 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 04:17:45 -0000 --f46d04182558350b0404bf566f42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support creating a WG item for this. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Apr 25, 2012 at 8:46 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > In Paris we took a hum on adopting a WG item for RTP Stream Duplication. > The problem this tries to address is described in > https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ > > The result in the meeting room was minuted as: A fair amount of people > supporting a WG item, none against. > > See more about this item (Agenda Item 10) in the minutes > http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm > > Thus I would like to ask the rest of the WG if they support or oppose > the creation of a WG item for defining how to best perform RTP stream > Duplication. > > Cheers > > Magnus Westerlund > (WG Chair) > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d04182558350b0404bf566f42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support creating a WG item for this.

Kevin Gross
+1-= 303-447-0517
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Wed, Apr 25, 2012 at 8:46 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wro= te:
WG,

In Paris we took a hum on adopting a WG item for RTP Stream Duplication. The problem this tries to address is described in
https://datatracker.ietf.org/doc/draft-begen-avtco= re-rtp-duplication/

The result in the meeting room was minuted as: A fair amount of people
supporting a WG item, none against.

See more about this item (Agenda Item 10) in the minutes
http://www.ietf.org/proceedings/83/minutes/minutes-83-= avtcore.htm

Thus I would like to ask the rest of the WG if they support or oppose
the creation of a WG item for defining how to best perform RTP stream
Duplication.

Cheers

Magnus Westerlund
(WG Chair)

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d04182558350b0404bf566f42-- From kevin.gross@avanw.com Tue May 8 08:39:18 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EBA11E809A for ; Tue, 8 May 2012 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 UE5wmTJTEghs for ; Tue, 8 May 2012 08:39:17 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 439C911E8080 for ; Tue, 8 May 2012 08:39:17 -0700 (PDT) Received: (qmail 10399 invoked by uid 0); 8 May 2012 15:39:16 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 8 May 2012 15:39:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=CBR2Qc85MCrP544SD19oFb5AqtKMuLPJ9LC9Ext1Yf8=; b=HAXQaeOjo9xE5lhP3rHC/5vwgPn0fuxlxLOF/pG+ksRYiufwGP3JGaqMXyOI9w37LKapwOmCz9ypvwqI6OJMyJgaNdv0bXSHK+34kKsrldZT3cbNJYo2vGlWrmN6ybjK; Received: from mail-wg0-f42.google.com ([74.125.82.42]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SRmVQ-0004JO-EM for avt@ietf.org; Tue, 08 May 2012 09:39:16 -0600 Received: by wgbds11 with SMTP id ds11so738589wgb.1 for ; Tue, 08 May 2012 08:39:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.100.2 with SMTP id eu2mr12528055wib.1.1336491555010; Tue, 08 May 2012 08:39:15 -0700 (PDT) Received: by 10.223.2.13 with HTTP; Tue, 8 May 2012 08:39:14 -0700 (PDT) In-Reply-To: <20120508144517.1168.92198.idtracker@ietfa.amsl.com> References: <20120508144517.1168.92198.idtracker@ietfa.amsl.com> Date: Tue, 8 May 2012 09:39:14 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=f46d044283d461b96e04bf883018 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.42 authed with kevin.gross@avanw.com} Subject: [AVTCORE] Fwd: New Version Notification for draft-gross-leap-second-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:39:18 -0000 --f46d044283d461b96e04bf883018 Content-Type: text/plain; charset=ISO-8859-1 This is the RTP leap-second text pulled out of the IDMS draft and reworked as a stand-alone RFC as requested in Paris. I'm interested in comments and discussion on whether this should be written as a recommendation or requirement. The more I think about it, it probably needs to be a requirement. I don't see how things can work reliably a against a leap-second-bearing reference clock without at least senders having leap-second awareness. A leap second has been scheduled for 30 June. Your prompt attention is requested :) Kevin Gross ---------- Forwarded message ---------- From: Date: Tue, May 8, 2012 at 8:45 AM Subject: New Version Notification for draft-gross-leap-second-00.txt To: kevin.gross@avanw.com Cc: ray.vanbrandenburg@tno.nl A new version of I-D, draft-gross-leap-second-00.txt has been successfully submitted by Kevin Gross and posted to the IETF repository. Filename: draft-gross-leap-second Revision: 00 Title: RTP and Leap Seconds Creation date: 2012-05-07 WG ID: Individual Submission Number of pages: 6 Abstract: This document discusses issues that arise when RTP sessions span (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. The IETF Secretariat --f46d044283d461b96e04bf883018 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is the RTP leap-second text pulled out of the IDMS draft and reworked = as a stand-alone RFC as requested in Paris.

I'm inte= rested in comments and discussion on whether this should be written as a re= commendation or requirement. The more I think about it, it probably needs t= o be a requirement. I don't see how things can work reliably a=A0agains= t=A0a leap-second-bearing reference clock without at least senders having l= eap-second awareness.

A leap second has been scheduled for 30 June. Your=A0pr= ompt=A0attention is=A0requested=A0:)

Kevin Gross<= br>

---------- Forwarded message -= ---------
From: <internet-drafts@ietf.org>
= Date: Tue, May 8, 2012 at 8:45 AM
Subject: New Version Notification for = draft-gross-leap-second-00.txt
To: kevin.gross@avanw.com
C= c: ray.vanbrandenburg@tno.nl


A new version of I-D, draft-gross-leap-second-00.txt has been= successfully submitted by Kevin Gross and posted to the IETF repository.
Filename: =A0 =A0 =A0 =A0draft-gross-leap-second
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 RTP and Leap Seconds
Creation date: =A0 2012-05-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6

Abstract:
=A0 This document discusses issues that arise when RTP sessions span
=A0 (UTC) leap seconds. =A0It updates RFC 3550 to describe how RTP senders=
=A0 and receivers should behave in the presence of leap seconds.




The IETF Secretariat

--f46d044283d461b96e04bf883018-- From kevin.gross@avanw.com Tue May 8 08:54:35 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C131021F863B for ; Tue, 8 May 2012 08:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.316 X-Spam-Level: X-Spam-Status: No, score=0.316 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 LMiMojX-kZ7j for ; Tue, 8 May 2012 08:54:34 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 2BB9D11E80B0 for ; Tue, 8 May 2012 08:54:33 -0700 (PDT) Received: (qmail 31459 invoked by uid 0); 8 May 2012 15:54:32 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 8 May 2012 15:54:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=IPwEhwLTwbY8NWFqreM+WS8mW1pes0Hh28OLJxajll0=; b=YwYeppbcgwsmQlNxlB+Lb4aG2lmnodtiuS2/1WXprGjlMGJxC9aFOl0uKyVVxMXyBEO0mmxZsWmy1fkSMTONVz13vzyEimf7H78/fBu74q+vBabxaACtNbBeIGHFVmbj; Received: from mail-we0-f172.google.com ([74.125.82.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SRmkC-0007Kw-9D for avt@ietf.org; Tue, 08 May 2012 09:54:32 -0600 Received: by werf13 with SMTP id f13so3578961wer.31 for ; Tue, 08 May 2012 08:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.194.195 with SMTP id m45mr4533152wen.8.1336492469128; Tue, 08 May 2012 08:54:29 -0700 (PDT) Received: by 10.223.2.13 with HTTP; Tue, 8 May 2012 08:54:29 -0700 (PDT) In-Reply-To: References: <20120508144517.1168.92198.idtracker@ietfa.amsl.com> Date: Tue, 8 May 2012 09:54:29 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=0016e6d77ee2de0d0104bf88667e X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Subject: Re: [AVTCORE] New Version Notification for draft-gross-leap-second-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:54:35 -0000 --0016e6d77ee2de0d0104bf88667e Content-Type: text/plain; charset=ISO-8859-1 Sorry, a link would be helpful. https://datatracker.ietf.org/doc/draft-gross-leap-second/ Kevin Gross On Tue, May 8, 2012 at 9:39 AM, Kevin Gross wrote: > This is the RTP leap-second text pulled out of the IDMS draft and reworked > as a stand-alone RFC as requested in Paris. > > I'm interested in comments and discussion on whether this should be > written as a recommendation or requirement. The more I think about it, it > probably needs to be a requirement. I don't see how things can work > reliably a against a leap-second-bearing reference clock without at least > senders having leap-second awareness. > > A leap second has been scheduled for 30 June. Your prompt attention > is requested :) > > Kevin Gross > > > ---------- Forwarded message ---------- > From: > Date: Tue, May 8, 2012 at 8:45 AM > Subject: New Version Notification for draft-gross-leap-second-00.txt > To: kevin.gross@avanw.com > Cc: ray.vanbrandenburg@tno.nl > > > A new version of I-D, draft-gross-leap-second-00.txt has been successfully > submitted by Kevin Gross and posted to the IETF repository. > > Filename: draft-gross-leap-second > Revision: 00 > Title: RTP and Leap Seconds > Creation date: 2012-05-07 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This document discusses issues that arise when RTP sessions span > (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders > and receivers should behave in the presence of leap seconds. > > > > > The IETF Secretariat > > --0016e6d77ee2de0d0104bf88667e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, a link would be helpful.


Kevin Gross=

On Tue, May 8, 2012 at 9:39 AM, K= evin Gross <kevin.gross@avanw.com> wrote:
This is the RTP leap-second text pulled out of the IDMS draft and reworked = as a stand-alone RFC as requested in Paris.

I'm inte= rested in comments and discussion on whether this should be written as a re= commendation or requirement. The more I think about it, it probably needs t= o be a requirement. I don't see how things can work reliably a=A0agains= t=A0a leap-second-bearing reference clock without at least senders having l= eap-second awareness.

A leap second has been scheduled for 30 June. Your=A0pr= ompt=A0attention is=A0requested=A0:)

Kevin Gross


---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Tue, May 8, 2012 at 8:45 AM
Subject: New Version= Notification for draft-gross-leap-second-00.txt
To: kevin.gross@= avanw.com
Cc: ray.vanbrandenburg@tno.nl


A new version of I-D, dra= ft-gross-leap-second-00.txt has been successfully submitted by Kevin Gross = and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-gross-leap-second
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 RTP and Leap Seconds
Creation date: =A0 2012-05-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6

Abstract:
=A0 This document discusses issues that arise when RTP sessions span
=A0 (UTC) leap seconds. =A0It updates RFC 3550 to describe how RTP senders=
=A0 and receivers should behave in the presence of leap seconds.




The IETF Secretariat


--0016e6d77ee2de0d0104bf88667e-- From versteb@cisco.com Tue May 8 13:54:09 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27B21F0C6E for ; Tue, 8 May 2012 13:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 wkU9hkQ0Bs7A for ; Tue, 8 May 2012 13:54:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C27EF1F0C6A for ; Tue, 8 May 2012 13:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=versteb@cisco.com; l=8006; q=dns/txt; s=iport; t=1336510449; x=1337720049; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ma59DsIYsgHCIeV+erTVnPe3OVJNJELbS0kDcfHKlhQ=; b=NvlCkerdAyKfLJ4lxcp+ztyO0LEWf3CmBt/sa+6MNgV8RAW9jLH0tGkH 327Krq3I9KiH68J/7+w4/t0zHMNzR2QX8YYqUanYwFcoWHSJUZHvmMDWP 9OFR4iB6tGnBW/cQ7nkjyz9DxtppR5HTk3q4XCNDIxYyaQGaebM95d/nU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOKGqU+tJV2d/2dsb2JhbABBA4JGsGeBB4IMAQEBBAEBAQkGAQkRAxkwDgICAQgHCgQBAQsGFwEGARoMHwkIAQEEARIIARmHbAubB6AbBIp/gmeCSGMEiDA0m3OBaYMH X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208,217";a="81438074" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 08 May 2012 20:54:08 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q48Ks8ml007107; Tue, 8 May 2012 20:54:08 GMT Received: from xmb-rcd-312.cisco.com ([72.163.63.27]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 15:54:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2D5C.B5DCE60E" Date: Tue, 8 May 2012 15:54:07 -0500 Message-ID: <117602CF2B17DB4F9001427FA6D9053901BC12A4@XMB-RCD-312.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Adopting a WG item for RTP stream duplication? Thread-Index: Ac0rPzQF3zDGYRdFSGCmLIFBLrZW4wCHXAUA References: <4F980E4D.1040205@ericsson.com> From: "Bill Ver Steeg (versteb)" To: "Kevin Gross" , "Magnus Westerlund" X-OriginalArrivalTime: 08 May 2012 20:54:08.0213 (UTC) FILETIME=[B6499850:01CD2D5C] Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:54:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2D5C.B5DCE60E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support it also =20 Bill VerSteeg =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Kevin Gross Sent: Sunday, May 06, 2012 12:18 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? =20 I support creating a WG item for this. =20 Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Wed, Apr 25, 2012 at 8:46 AM, Magnus Westerlund = wrote: WG, In Paris we took a hum on adopting a WG item for RTP Stream Duplication. The problem this tries to address is described in https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ The result in the meeting room was minuted as: A fair amount of people supporting a WG item, none against. See more about this item (Agenda Item 10) in the minutes http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm Thus I would like to ask the rest of the WG if they support or oppose the creation of a WG item for defining how to best perform RTP stream Duplication. Cheers Magnus Westerlund (WG Chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 = =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 = =20 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt =20 ------_=_NextPart_001_01CD2D5C.B5DCE60E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I support it also

 

Bill VerSteeg

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Kevin Gross
Sent: Sunday, May 06, 2012 12:18 = AM
To: Magnus Westerlund
Cc: IETF AVTCore = WG
Subject: Re: [AVTCORE] Adopting a WG item for RTP stream = duplication?

 

I support = creating a WG item for this.

 

Kevin = Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com, www.X192.org

 

On Wed, Apr 25, 2012 at 8:46 AM, Magnus Westerlund = <magnus.westerlund@ericsson.com> = wrote:

WG,

In Paris we took a = hum on adopting a WG item for RTP Stream Duplication.
The problem = this tries to address is described in
https://datatracker.ietf.org/doc/draft-begen-avtcore-rt= p-duplication/

The result in the meeting room was minuted as: = A fair amount of people
supporting a WG item, none = against.

See more about this item (Agenda Item 10) in the = minutes
http://www.ietf.org/proceedings/83/minutes/minutes-83-a= vtcore.htm

Thus I would like to ask the rest of the WG if = they support or oppose
the creation of a WG item for defining how to = best perform RTP stream
Duplication.

Cheers

Magnus = Westerlund
(WG = Chair)

-----------------------------------------------------------= -----------
Multimedia Technologies, Ericsson Research = EAB/TVM
--------------------------------------------------------------= --------
Ericsson AB               =  | Phone  +46 10 = 7148287
F=E4r=F6gatan 6             =    | Mobile +46 73 = 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson= .com
-------------------------------------------------------------= ---------

_______________________________________________
Audio= /Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

 

------_=_NextPart_001_01CD2D5C.B5DCE60E-- From vsingh.ietf@gmail.com Tue May 8 13:56:20 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D381D21F84FB for ; Tue, 8 May 2012 13:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179, 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 1p-2GJCaH6AD for ; Tue, 8 May 2012 13:56:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95D2F21F84F8 for ; Tue, 8 May 2012 13:56:19 -0700 (PDT) Received: by werf13 with SMTP id f13so3840764wer.31 for ; Tue, 08 May 2012 13:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=zEfmQ0xjy5T451u/cOA3PLYqNb8kw6snkXBLMbmOBE4=; b=jxW9oUElcDjWmyqjMqcmk4enrf6jnrFJg322HKHIkLprWLFg/ikOQgIGYB9Sa6OD3w cRCsHbhzpHYDUPGWS1UtsGJT3Fd0kTpfczaAu2UwsWzUYdFrNtL7DeY3Txhz4hY4d8zB R2zNyGrUEKGtj2N1Hl2O/SnZl4wTQFoqlFYTsF/+AFNfiN+2CbFevzZkILUicjBuOyca NEvpnJWzRlrNkvihhoWGhU/Ia6awu4kY8oHjDb/k6492iFuCtQnHXy1ud5BoR3hAWE5J 9gttkeRx+EZaTc2oPkgl9i1NIozpudGaEPBRFUQ4KnEr8Vw/DZGTXjAgRk6/G9PomiAh 9k6Q== Received: by 10.216.134.145 with SMTP id s17mr4940781wei.22.1336510578598; Tue, 08 May 2012 13:56:18 -0700 (PDT) References: <4F980E4D.1040205@ericsson.com> <117602CF2B17DB4F9001427FA6D9053901BC12A4@XMB-RCD-312.cisco.com> From: Varun Singh In-Reply-To: <117602CF2B17DB4F9001427FA6D9053901BC12A4@XMB-RCD-312.cisco.com> Mime-Version: 1.0 (1.0) Date: Tue, 8 May 2012 23:56:15 +0300 Message-ID: <3972705608442588076@unknownmsgid> To: IETF AVTCore WG Content-Type: multipart/alternative; boundary=0016e6de006e46a29804bf8c9e4f Cc: Magnus Westerlund Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:56:20 -0000 --0016e6de006e46a29804bf8c9e4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support it too. Varun. On 8.5.2012, at 23.54, "Bill Ver Steeg (versteb)" wrote= : I support it also Bill VerSteeg *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf Of *K= evin Gross *Sent:* Sunday, May 06, 2012 12:18 AM *To:* Magnus Westerlund *Cc:* IETF AVTCore WG *Subject:* Re: [AVTCORE] Adopting a WG item for RTP stream duplication? I support creating a WG item for this. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Apr 25, 2012 at 8:46 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: WG, In Paris we took a hum on adopting a WG item for RTP Stream Duplication. The problem this tries to address is described in https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ The result in the meeting room was minuted as: A fair amount of people supporting a WG item, none against. See more about this item (Agenda Item 10) in the minutes http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm Thus I would like to ask the rest of the WG if they support or oppose the creation of a WG item for defining how to best perform RTP stream Duplication. Cheers Magnus Westerlund (WG Chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --0016e6de006e46a29804bf8c9e4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support it too.=A0

Varun.=A0

On 8.5.2012, at 23.54, "B= ill Ver Steeg (versteb)" <vers= teb@cisco.com> wrote:

I support it also

=A0

Bill VerSteeg

<= p class=3D"MsoNormal">=A0

From: avt-bounces@ietf.org [mailto:= avt-bounces@ietf.org] On Beh= alf Of Kevin Gross
Sent: Sunday, May 06, 2012 12:18 AM
To: Magnus Westerlund<= br>Cc: IETF AVTCore WG
Subject: Re: [AVTCORE] Adopting a W= G item for RTP stream duplication?

=A0

I support creating a WG item for this.

=A0

Kevin Gross

=

+1-303-447-0517

Media Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

=A0

On Wed, Apr 25, 2012 at 8:46 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wrote:

WG,

In Paris we took a hum on adopting a WG item for RTP Stream Duplication= .
The problem this tries to address is described in
https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplicatio= n/

The result in the meeting room was minuted as: A fair amount of people<= br>supporting a WG item, none against.

See more about this item (Age= nda Item 10) in the minutes
http://www.ietf.org/pro= ceedings/83/minutes/minutes-83-avtcore.htm

Thus I would like to ask the rest of the WG if they support or opposethe creation of a WG item for defining how to best perform RTP stream
= Duplication.

Cheers

Magnus Westerlund
(WG Chair)

----------------------------------------------------------------------
M= ultimedia Technologies, Ericsson Research EAB/TVM
----------------------= ------------------------------------------------
Ericsson AB =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 = 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto= : magnus.westerlund@erics= son.com
------------------------------------------------------------= ----------

_______________________________________________
Audio/Video Transpor= t Core Maintenance
avt@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/avt" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/avt

=A0

________________________________________= _______
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.iet= f.org/mailman/listinfo/avt
--0016e6de006e46a29804bf8c9e4f-- From internet-drafts@ietf.org Mon May 14 01:50:40 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4540421F85D6; Mon, 14 May 2012 01:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, 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 P7lqhq07CeEC; Mon, 14 May 2012 01:50:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85A21F85D2; Mon, 14 May 2012 01:50:39 -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.02 Message-ID: <20120514085039.26506.63607.idtracker@ietfa.amsl.com> Date: Mon, 14 May 2012 01:50:39 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:50:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Explicit Congestion Notification (ECN) for RTP over UDP Author(s) : Magnus Westerlund Ingemar Johansson Colin Perkins Piers O'Hanlon Ken Carlberg Filename : draft-ietf-avtcore-ecn-for-rtp-08.txt Pages : 57 Date : 2012-05-14 This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ From magnus.westerlund@ericsson.com Mon May 14 06:16:37 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B8A21F86B1 for ; Mon, 14 May 2012 06:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.148 X-Spam-Level: X-Spam-Status: No, score=-106.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 MNemaCiFQRfF for ; Mon, 14 May 2012 06:16:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9968421F86BE for ; Mon, 14 May 2012 06:16:36 -0700 (PDT) X-AuditID: c1b4fb25-b7b48ae0000025b3-79-4fb105b3cd18 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.28.09651.3B501BF4; Mon, 14 May 2012 15:16:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 15:16:34 +0200 Message-ID: <4FB105B2.60907@ericsson.com> Date: Mon, 14 May 2012 15:16:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF AVTCore WG References: <20120514085039.26506.63607.idtracker@ietfa.amsl.com> In-Reply-To: <20120514085039.26506.63607.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:16:37 -0000 WG, This version is intended to address the discuss and comments from IESG. A Diff is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-ecn-for-rtp-08 The main technical change is for the ABNF for future extension of the ecn-capable-rtp attribute which now allows escaping in the quoted list. Cheers Magnus On 2012-05-14 10:50, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Author(s) : Magnus Westerlund > Ingemar Johansson > Colin Perkins > Piers O'Hanlon > Ken Carlberg > Filename : draft-ietf-avtcore-ecn-for-rtp-08.txt > Pages : 57 > Date : 2012-05-14 > > This memo specifies how Explicit Congestion Notification (ECN) can be > used with the Real-time Transport Protocol (RTP) running over UDP, > using RTP Control Protocol (RTCP) as a feedback mechanism. It > defines a new RTCP Extended Report (XR) block for periodic ECN > feedback, a new RTCP transport feedback message for timely reporting > of congestion events, and a Session Traversal Utilities for NAT > (STUN) extension used in the optional initialization method using > Interactive Connectivity Establishment (ICE). Signalling and > procedures for negotiation of capabilities and initialization methods > are also defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-08.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rjsparks@nostrum.com Mon May 14 11:20:57 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ADB21F8555 for ; Mon, 14 May 2012 11:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, SPF_PASS=-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 R4xdFlzriH82 for ; Mon, 14 May 2012 11:20:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 29EBD21F854B for ; Mon, 14 May 2012 11:20:52 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4EIKmgK066527 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 May 2012 13:20:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4FB14D00.7050902@nostrum.com> Date: Mon, 14 May 2012 13:20:48 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <20120514085039.26506.63607.idtracker@ietfa.amsl.com> <4FB105B2.60907@ericsson.com> In-Reply-To: <4FB105B2.60907@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:20:57 -0000 There are also a number of editorial changes, and the removal of 2119 keywords from the requirements section. Please review the changes carefully. All the discusses have cleared. I'll send in the approval notice Wednesday unless I hear from the list otherwise. RjS On 5/14/12 8:16 AM, Magnus Westerlund wrote: > WG, > > This version is intended to address the discuss and comments from IESG. > > A Diff is available here: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-ecn-for-rtp-08 > > The main technical change is for the ABNF for future extension of the > ecn-capable-rtp attribute which now allows escaping in the quoted list. > > Cheers > > Magnus > > > On 2012-05-14 10:50, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. >> >> Title : Explicit Congestion Notification (ECN) for RTP over UDP >> Author(s) : Magnus Westerlund >> Ingemar Johansson >> Colin Perkins >> Piers O'Hanlon >> Ken Carlberg >> Filename : draft-ietf-avtcore-ecn-for-rtp-08.txt >> Pages : 57 >> Date : 2012-05-14 >> >> This memo specifies how Explicit Congestion Notification (ECN) can be >> used with the Real-time Transport Protocol (RTP) running over UDP, >> using RTP Control Protocol (RTCP) as a feedback mechanism. It >> defines a new RTCP Extended Report (XR) block for periodic ECN >> feedback, a new RTCP transport feedback message for timely reporting >> of congestion events, and a Session Traversal Utilities for NAT >> (STUN) extension used in the optional initialization method using >> Interactive Connectivity Establishment (ICE). Signalling and >> procedures for negotiation of capabilities and initialization methods >> are also defined. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-08.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-08.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > From internet-drafts@ietf.org Tue May 15 01:01:56 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D362E21F894A; Tue, 15 May 2012 01:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, 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 prgWsJwZdEzZ; Tue, 15 May 2012 01:01:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6521F8600; Tue, 15 May 2012 01:01:55 -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.02 Message-ID: <20120515080155.12625.2920.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 01:01:55 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 08:01:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : The ARIA Algorithm and Its Use with the Secure Real-time= Transport Protocol(SRTP) Author(s) : Woo-Hwan Kim Jungkeun Lee Dong-Chan Kim Je-Hong Park Daesung Kwon Filename : draft-ietf-avtcore-aria-srtp-00.txt Pages : 10 Date : 2012-05-15 This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-aria-srtp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-aria-srtp-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ From woohwankim@gmail.com Tue May 15 01:31:59 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA58621F8935 for ; Tue, 15 May 2012 01:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c4dmiyQcKQC1 for ; Tue, 15 May 2012 01:31:59 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2265A21F8946 for ; Tue, 15 May 2012 01:31:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7050166vbb.31 for ; Tue, 15 May 2012 01:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=VL+co95mAowljjV/NWPbwR30yTSsnFptrdnxUv+Vf9Y=; b=VO1SGHtBkn8XZaMpEielcEL4OjW64xWvmQz1jd4uFG8f0/+HmcWgDrbiLriQ37SL+a PefP0fVCWGn2JobuWKZwAjX5J2NVAx5No999qFSW9/CKz1kXsya92tVELbUx6gY3/IK1 57EznCOUSf/k0DEpsQr4O90/LwcMr6CkdKEnLP9+F2IVJ+R5Hmyz8EWQ6ptTfGdJHhmc vPpHyYEIwjzAcSSQZIjjMyR7tg2UWbbiRqFiiiPmIoUwKz0lZnap2bKfc3hdXBBNwakl n4i9jpQG2OyHC8BQ2t4OwWKzN+mSHRrBvMSafeZIyZb6YVuBE4Ukyk6SP8H3M0fpdYU5 go7Q== MIME-Version: 1.0 Received: by 10.52.95.203 with SMTP id dm11mr5382032vdb.70.1337070718658; Tue, 15 May 2012 01:31:58 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.52.95.12 with HTTP; Tue, 15 May 2012 01:31:58 -0700 (PDT) Date: Tue, 15 May 2012 17:31:58 +0900 X-Google-Sender-Auth: 2Jve-cqc49YLgMIm_TdWJDFMR-8 Message-ID: From: Woo-Hwan Kim To: avt@ietf.org Content-Type: multipart/alternative; boundary=bcaec50162a139aa9b04c00f0918 Cc: magnus.westerlund@ericsson.com, Daesung Kwon , dongchan@ensec.re.kr, Je Hong Park , Jungkeon Lee Subject: [AVTCORE] Request for review: The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 08:32:00 -0000 --bcaec50162a139aa9b04c00f0918 Content-Type: text/plain; charset=ISO-8859-1 AVT experts, Let me make a request for review on the draft " The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) ". Any comments would be appreciated. http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-00 Woo-Hwan Kim ---------- Forwarded message ---------- From: Date: 2012/5/15 Subject: New Version Notification for draft-ietf-avtcore-aria-srtp-00.txt To: whkim5@ensec.re.kr Cc: ds_kwon@ensec.re.kr, dongchan@ensec.re.kr, jhpark@ensec.re.kr, jklee@ensec.re.kr A new version of I-D, draft-ietf-avtcore-aria-srtp-00.txt has been successfully submitted by Woo-Hwan Kim and posted to the IETF repository. Filename: draft-ietf-avtcore-aria-srtp Revision: 00 Title: The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) Creation date: 2012-05-15 WG ID: avtcore Number of pages: 10 Abstract: This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. The IETF Secretariat --bcaec50162a139aa9b04c00f0918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
AVT experts,

Let me make a request for review= =A0
on the draft " The ARIA Algorithm and Its Use with the S= ecure Real-time Transport Protocol(SRTP) ".

Any comments would be appreciated.


Woo-Hw= an Kim

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: 2012/5/15
Subject: New Version Notification for draft-ietf-avtcore-aria-srtp-00.txtTo: whkim5@ensec.re.kr
Cc: <= a href=3D"mailto:ds_kwon@ensec.re.kr">ds_kwon@ensec.re.kr, dongchan@ensec.re.kr, jhpark@ensec.re.kr, jklee@ensec.re.kr


A new version of I-D, draft-ietf-avtcore-aria-srtp-00.txt has been = successfully submitted by Woo-Hwan Kim and posted to the IETF repository.
Filename: =A0 =A0 =A0 =A0draft-ietf-avtcore-aria-srtp
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 The ARIA Algorithm and Its Use with the Secure R= eal-time Transport Protocol(SRTP)
Creation date: =A0 2012-05-15
WG ID: =A0 =A0 =A0 =A0 =A0 avtcore
Number of pages: 10

Abstract:
=A0 This document describes the use of the ARIA block cipher algorithm
=A0 within the Secure Real-time Transport Protocol (SRTP) for providing =A0 confidentiality for the Real-time Transport Protocol (RTP) traffic
=A0 and for the control traffic for RTP, the Real-time Transport Control =A0 Protocol (RTCP). =A0It details three modes of operation (CTR, CCM, GCM= )
=A0 and a SRTP Key Derivation Function for ARIA.




The IETF Secretariat

--bcaec50162a139aa9b04c00f0918-- From rjsparks@nostrum.com Tue May 15 16:13:49 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EAA11E80B0 for ; Tue, 15 May 2012 16:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 L7BdwRvXQ2e7 for ; Tue, 15 May 2012 16:13:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 42A0611E80A1 for ; Tue, 15 May 2012 16:13:48 -0700 (PDT) Received: from unexplicable.local (pool-71-244-61-199.dllstx.fios.verizon.net [71.244.61.199]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4FNDgRx036026 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 May 2012 18:13:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4FB2E323.3090406@nostrum.com> Date: Tue, 15 May 2012 18:13:39 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , draft-ietf-avtcore-monarch@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.244.61.199 is authenticated by a trusted mechanism) Subject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 23:13:49 -0000 Summary: There are issues to resolve with a revised ID before progressing to IETF LC. It's a struggle to see the _architecture_ this document is supposed to describe. I suspect most of the working group energy went into Section 5 (the guidelines for writing XR block definitions) - the rest of the document needs a similar level of attention to detail. There are two major issues that I've tagged with a (*). I followed a mostly document-order flow instead of grouping the major issues at the top. (*) Given the document's title, it should be very easy to answer "What is the monitoring architecture?" for people who are reading this draft for the first time. The key message is that the monitoring architecture consists of Monitors that exchange information using RTCP Metric Blocks. The text should say that. There is a lot of prose in section 3 and visual detail in the diagram in Figure 1 that makes that extremely difficult to see. Simplifying the figure by removing the details about applications and transports, or at least moving them to a second figure, making the Monitor boxes stand out, and making the types of information flows (the arrows) visually distinctive would help. Simplify the prose (much of it could be removed) to focus on that key message. In the definition of Composed metrics, the sentence "An example is a metric calculated based on derived metrics that have been measured." makes little sense. Did you mean something like "An example is a metric derived by algorithmically combining measured metrics."? The definitions of Interval, Cumulative, and Sampled metrics are not clear. If the discussion at the end of section 3.1 is kept, the reference to RFC5760 should be a real reference, and RFC5760 should appear in the reference section. The point of section 3.2 is not obvious. How does it contribute to the description of the architecture. It mixes talking about what report blocks are with occasionally needing to send them more frequently. Those points could be made separately and more simply. Section 3.3 is not clear - it starts off saying that the location of the sender and receiver may change what metrics are meaningful. It's not clear what you mean by location. You certainly don't mean geospatial coordinates. Do you mean anything other than whether the element is trusted or untrusted by the operations network? If so, say that. The rest of the paragraph only speaks to what element collects the metrics. It's not clear that the set of meaningful metrics is changed at all - just where you collect them. If the set of meaningful metrics does in fact change, there needs to be additional discussion here. Section 4's first paragraph: Is "probably" the best the working group can say? The last two sentences of the second bullet in section 4 do not parse. Please simplify them. The first full sentence of the third bullet in section 4 does not make sense. The whole bullet could be clarified. The fourth bullet in section 4 and section 5.5 should call out that RFC3611 already set Block Type 255 aside for future extensions, anticipating the potential need to extend the block type space. In section 5, consider naming the subsections with the actual guideline instead of the problem the guideline is trying to address. 5.1. Metric blocks should contain a single metric 5.2. Include the payload type and format parameters in the metric block 5.3. Use RTCP SDES to correlate XR reports with non-RTP data 5.4. Don't repeat measurement information across metric blocks This points out a structural problem with the section. Why is 5.5 here? It's not a guideline. (*) And it raises a question about what the document is trying to achieve with section 5.4. That section claims the document is proposing a new XR block type to help avoid duplication, but it doesn't actually define the new block type. Is the guideline saying simply don't repeat measurements or its the guideline saying "use this new XR block type we haven't defined yet"? The section needs more clarity. If it really is trying to define a new type, there's more work to be done. The Security Considerations section, particularly the third paragraph, needs to be clearer. What exactly do you mean by "monitoring should be prohibited", and how is the fact that third party monitors don't send RTCP relevant? Did you intend those to be separate points? Editorial Nits and Suggestions: The first paragraph of the introduction is overly complex, and won't age well. I suggest replacing it with: "Multimedia services using the Real-Time Protocol (RTP) are seeing increased use. Standard methods for gathering RTP performance metrics from these applications are needed to manage uncertainties in the behavior and availability of their services." Then replace "These rapidly emerging standards," with "Standards". Introduction paragraph 3 sentence 2 should start "The RTCP Guidelines [RFC5968]". It would be even better to use the full title from 5968: 'The "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968]' This may become moot as section 3 is modified to make its main point more obvious, but RFC3550 does not characterize Monitors as "a source of information". That could be misunderstood. Please choose another word. Perhaps "repository"? In bullet lists, starting an entry with "or" or "and" is unnecessary. It should be clear from the introduction to the list whether the individual entries should be combined or selected from. In section 3.1 where you say "RTP may be used to multicast groups" did you mean "RTP may be sent to multicast groups" or "RTP may be used with multicast groups"? In section 3.2 "The following are four use cases but are not limited to:" does not parse. The bullets aren't really use cases as much as they are mechanisms. Would it make more sense to say "Here are four mechanisms that have been created to address the need for more frequent reporting. This list is not intended to be exhaustive." The third bullet in that list should say "RTCP and RTCP XR are" instead of "RTCP or RTCP XR is". The bullets in section 4 would be better as subsections with titles (taken from the first phrase of the bullet). I suggest this alternative for the first full sentence in the first bullet of section 4 : "A compound metrics block is designed to contain a large number of parameters from different classes for a specific application in a single block." Section 5's title should be "Guidelines for reporting" instead of "Guideline for reporting" In section 5.1 I suggest "justify the overhead," instead of "justify the overheads," Section 7 - the last sentence of the first paragraph does not parse. The second paragraph (which is a single sentence) should be clarified - an MCU is not a topology. The last two sentences of the first paragraph of the security considerations section add nothing to the document. I suggest deleting them. From iesg-secretary@ietf.org Wed May 16 14:25:58 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E270F21F8758; Wed, 16 May 2012 14:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nz8vlhIH2mxE; Wed, 16 May 2012 14:25:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440FE21F8775; Wed, 16 May 2012 14:25:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120516212558.388.16643.idtracker@ietfa.amsl.com> Date: Wed, 16 May 2012 14:25:58 -0700 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Explicit Congestion Notification (ECN) for RTP over UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:25:59 -0000 The IESG has approved the following document: - 'Explicit Congestion Notification (ECN) for RTP over UDP' (draft-ietf-avtcore-ecn-for-rtp-08.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ Technical Summary This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. Working Group Summary There were no controversy about the proposed solution and there was consensus on all discussion points Document Quality There is at least one research implementation and there is fairly strong commercial interest. There was interest in this work by other standard bodies like 3GPP and ITU-T SG16 who need to reference it. The SDP attributes and ICE options defined in the document were sent to review in MMUSIC on September 30, 2011 Personnel Roni Even is the document shepherd. Robert Sparks is the responsible area director. From bill.wu@huawei.com Fri May 18 03:40:22 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6187621F86AA for ; Fri, 18 May 2012 03:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 E8pdkj0nZBxE for ; Fri, 18 May 2012 03:40:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B60B21F86A3 for ; Fri, 18 May 2012 03:40:20 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH61329; Fri, 18 May 2012 06:40:19 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 03:37:57 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 03:38:03 -0700 Received: from w53375 (10.138.41.149) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 18:37:58 +0800 Message-ID: From: Qin Wu To: Robert Sparks , IETF AVTCore WG , References: <4FB2E323.3090406@nostrum.com> Date: Fri, 18 May 2012 18:37:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:40:22 -0000 SGksUm9iZXJ0Og0KVGhhbmsgZm9yIHlvdXIgdmFsdWFibGUgcmV2aWV3LiBwbGVhc2Ugc2VlIG15 IHJlcGxpZXMgaW5saW5lIGJlbG93cy4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUm9iZXJ0IFNwYXJrcyIgPHJqc3BhcmtzQG5vc3RydW0u Y29tPg0KVG86ICJJRVRGIEFWVENvcmUgV0ciIDxhdnRAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1h dnRjb3JlLW1vbmFyY2hAdG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIE1heSAxNiwg MjAxMiA3OjEzIEFNDQpTdWJqZWN0OiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzDQoNCg0KPiBTdW1tYXJ5OiBUaGVyZSBhcmUgaXNz dWVzIHRvIHJlc29sdmUgd2l0aCBhIHJldmlzZWQgSUQgYmVmb3JlIA0KPiBwcm9ncmVzc2luZyB0 byBJRVRGIExDLg0KPiANCj4gSXQncyBhIHN0cnVnZ2xlIHRvIHNlZSB0aGUgX2FyY2hpdGVjdHVy ZV8gdGhpcyBkb2N1bWVudCBpcyBzdXBwb3NlZCB0byANCj4gZGVzY3JpYmUuIEkgc3VzcGVjdCBt b3N0IG9mIHRoZSB3b3JraW5nIGdyb3VwIGVuZXJneSB3ZW50IGludG8gU2VjdGlvbiA1IA0KPiAo dGhlIGd1aWRlbGluZXMgZm9yIHdyaXRpbmcgWFIgYmxvY2sgZGVmaW5pdGlvbnMpIC0gdGhlIHJl c3Qgb2YgdGhlIA0KPiBkb2N1bWVudCBuZWVkcyBhIHNpbWlsYXIgbGV2ZWwgb2YgYXR0ZW50aW9u IHRvIGRldGFpbC4NCj4gDQo+IFRoZXJlIGFyZSB0d28gbWFqb3IgaXNzdWVzIHRoYXQgSSd2ZSB0 YWdnZWQgd2l0aCBhICgqKS4gSSBmb2xsb3dlZCBhIA0KPiBtb3N0bHkgZG9jdW1lbnQtb3JkZXIg ZmxvdyBpbnN0ZWFkIG9mIGdyb3VwaW5nIHRoZSBtYWpvciBpc3N1ZXMgYXQgdGhlIHRvcC4NCj4g DQo+ICgqKSBHaXZlbiB0aGUgZG9jdW1lbnQncyB0aXRsZSwgaXQgc2hvdWxkIGJlIHZlcnkgZWFz eSB0byBhbnN3ZXIgIldoYXQgDQo+IGlzIHRoZSBtb25pdG9yaW5nIGFyY2hpdGVjdHVyZT8iIGZv ciBwZW9wbGUgd2hvIGFyZSByZWFkaW5nIHRoaXMgZHJhZnQgDQo+IGZvciB0aGUgZmlyc3QgdGlt ZS4NCj4gVGhlIGtleSBtZXNzYWdlIGlzIHRoYXQgdGhlIG1vbml0b3JpbmcgYXJjaGl0ZWN0dXJl IGNvbnNpc3RzIG9mIE1vbml0b3JzIA0KPiB0aGF0IGV4Y2hhbmdlIGluZm9ybWF0aW9uIHVzaW5n IFJUQ1AgTWV0cmljIEJsb2Nrcy4gDQoNCltRaW5dOiBBZ3JlZS4NCg0KPlRoZSB0ZXh0IHNob3Vs ZCBzYXkgDQo+IHRoYXQuDQoNCltRaW5dOiBPa2F5Lg0KDQo+IFRoZXJlIGlzIGEgbG90IG9mIHBy b3NlIGluIHNlY3Rpb24gMyBhbmQgdmlzdWFsIGRldGFpbCBpbiB0aGUgDQo+IGRpYWdyYW0gaW4g RmlndXJlIDEgdGhhdCBtYWtlcyB0aGF0IGV4dHJlbWVseSBkaWZmaWN1bHQgdG8gc2VlLiANCj4g U2ltcGxpZnlpbmcgdGhlIGZpZ3VyZSBieSByZW1vdmluZyB0aGUgZGV0YWlscyBhYm91dCBhcHBs aWNhdGlvbnMgYW5kIA0KPiB0cmFuc3BvcnRzLCBvciBhdCBsZWFzdCBtb3ZpbmcgdGhlbSB0byBh IHNlY29uZCBmaWd1cmUsIG1ha2luZyB0aGUgDQo+IE1vbml0b3IgYm94ZXMgc3RhbmQgb3V0LCBh bmQgbWFraW5nIHRoZSB0eXBlcyBvZiBpbmZvcm1hdGlvbiBmbG93cyAodGhlIA0KPiBhcnJvd3Mp IHZpc3VhbGx5IGRpc3RpbmN0aXZlIHdvdWxkIGhlbHAuIFNpbXBsaWZ5IHRoZSBwcm9zZSAobXVj aCBvZiBpdCANCj4gY291bGQgYmUgcmVtb3ZlZCkgdG8gZm9jdXMgb24gdGhhdCBrZXkgbWVzc2Fn ZS4NCg0KW1Fpbl06IEFncmVlLCBJIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZSBmaWd1cmUgMSBhbmQg c3F1ZWV6ZSB0aGUgc2VjdGlvbiAzLjEgYXMgZm9sbG93czoNCg0KIg0KDQozLjEuICBPdmVydmll dw0KDQogDQoNCiAgIFRoZSBSVFAgbW9uaXRvcmluZyBhcmNoaXRlY3R1cmUgY29tcHJpc2VzIHRo ZSBmb2xsb3dpbmcgdHdvIGtleQ0KDQogICBmdW5jdGlvbmFsIGNvbXBvbmVudHMgc2hvd24gYmVs b3c6DQoNCiANCg0KICAgbyAgUlRQIE1vbml0b3INCg0KIA0KDQogICBvICBSVFAgTWV0cmljIEJs b2NrIFN0cnVjdHVyZQ0KDQogDQoNCiAgIFJUUCBNb25pdG9yIGlzIHRoZSBmdW5jdGlvbmFsIGNv bXBvbmVudCBkZWZpbmVkIGluIHRoZSBSZWFsLXRpbWUNCg0KICAgVHJhbnNwb3J0IFByb3RvY29s IFtSRkMzNTUwXS4gSXQgYWN0cyBhcyBhIHNvdXJjZSBvZiBpbmZvcm1hdGlvbg0KDQogICBnYXRo ZXJlZCBmb3IgbW9uaXRvcmluZyBwdXJwb3NlcyBhbmQgZXhjaGFuZ2VzIGluZm9ybWF0aW9uIHdp dGggDQoNCiAgIHRoZSBvdGhlciBSVFAgbW9uaXRvcnMgdXNpbmcgUlRDUCBNZXRyaWMgQmxvY2tz LiAgQWNjb3JkaW5nIHRvIA0KDQogICB0aGUgZGVmaW5pdGlvbiBvZiBtb25pdG9yIGluIHRoZQ0K DQogICBSVFAgUHJvdG9jb2wgW1JGQzM1NTBdLCB0aGUgZW5kIHN5c3RlbSB0aGF0IHJ1bnMgYW4g YXBwbGljYXRpb24NCg0KICAgcHJvZ3JhbSB0aGF0IHNlbmRzIG9yIHJlY2VpdmVzIFJUUCBkYXRh IHBhY2tldHMsIGFuIGludGVybWVkaWF0ZS0NCg0KICAgc3lzdGVtIHRoYXQgZm9yd2FyZHMgUlRQ IHBhY2tldHMgdG8gRW5kLWRldmljZXMgb3IgYSB0aGlyZCBwYXJ0eSB0aGF0DQoNCiAgIG9ic2Vy dmVzIHRoZSBSVFAgYW5kIFJUQ1AgdHJhZmZpYyBidXQgZG9lcyBub3QgbWFrZSBpdHNlbGYgdmlz aWJsZSB0bw0KDQogICB0aGUgUlRQIFNlc3Npb24gcGFydGljaXBhbnRzIChpLmUuLCB0aGUgdGhp cmQgcGFydHkgbW9uaXRvciBkZXBpY3RlZA0KDQogICBpbiBmaWd1cmUgMSkgY2FuIGFjdCBhcyB0 aGUgUlRQIG1vbml0b3IuIFRoZSB0aGlyZCBwYXJ0eSBtb25pdG9yIHNob3VsZCBiZQ0KDQogICBw bGFjZWQgb24gdGhlIFJUUC9SVENQIHBhdGhzIGJldHdlZW4gdGhlIHNlbmRlciwgaW50ZXJtZWRp YXRlIGFuZCB0aGUNCg0KICAgcmVjZWl2ZXIuDQoNCiANCg0KICAgVGhlIFJUUCBtb25pdG9yIGFs c28gZXhwb3NlcyByZWFsIHRpbWUgQXBwbGljYXRpb24gUW9TL1FvRSBtZXRyaWMNCg0KICAgaW5m b3JtYXRpb24gaW4gdGhlIGFwcHJvcHJpYXRlIHJlcG9ydCBibG9jayBmb3JtYXQgKGUuZy4sUlRD UCBYUiBvciANCg0KICAgb3RoZSBub24tUlRQIG1lYW5zKSB0byB0aGUgbWFuYWdlbWVudA0KDQog ICBzeXN0ZW0uICBTdWNoIGluZm9ybWF0aW9uIGNhbiBiZSBmb3JtdWxhdGVkIGFzIGRpZmZlcmVu dCBtZXRyaWMgdHlwZXMsIA0KDQogICBlLmcuLGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpYywgdHJh bnNwb3J0IGxldmVsIG1ldHJpYywgZW5kIHN5c3RlbSBtZXRyaWMsDQoNCiAgICBpbnRlcnZhbCBt ZXRyaWMsIGN1bXVsYXRpdmUgbWV0cmljLCBzYW1wbGVkIG1ldHJpYywgZGlyZWN0IG1ldHJpYywg Y29tcG9zZWQgbWV0cmljLGV0Yy4NCg0KICAgQm90aCB0aGUgUlRDUCBvciBSVENQIFhSIGNhbiBi ZSBleHRlbmRlZCB0byBjb252ZXkgdGhlc2UgbWV0cmljcy4NCg0KICAgVGhlIGRldGFpbHMgb24g dHJhbnNwb3J0IHByb3RvY29scyBmb3IgdGhlc2UgbWV0cmljIGFyZSBkZXNjcmliZWQgaW4NCg0K ICAgU2VjdGlvbiAzLjIuDQoNCiANCg0KICAgUlRQIG1heSBiZSB1c2VkIHRvIG11bHRpY2FzdCBn cm91cHMsIGJvdGggQW55IFNvdXJjZSBNdWx0aWNhc3QgKEFTTSkNCg0KICAgYW5kIFNvdXJjZSBT cGVjaWZpYyBNdWx0aWNhc3QgKFNTTSkuICBUaGVzZSBncm91cHMgY2FuIGJlIG1vbml0b3JlZA0K DQogICB1c2luZyBSVENQLiAgSW4gdGhlIEFTTSBjYXNlLCB0aGUgbW9uaXRvciBpcyBhIG1lbWJl ciBvZiB0aGUNCg0KICAgbXVsdGljYXN0IGdyb3VwIGFuZCBsaXN0ZW5zIHRvIFJUQ1AgWFIgcmVw b3J0cyBmcm9tIGFsbCBtZW1iZXJzIG9mDQoNCiAgIHRoZSBBU00gZ3JvdXAuICBJbiB0aGUgU1NN IGNhc2UsIHRoZXJlIGlzIGEgdW5pY2FzdCBmZWVkYmFjayB0YXJnZXQNCg0KICAgdGhhdCByZWNl aXZlcyBSVENQIGZlZWRiYWNrIGZyb20gcmVjZWl2ZXJzIGFuZCBkaXN0cmlidXRlcyBpdCB0bw0K DQogICBvdGhlciBtZW1iZXJzIG9mIHRoZSBTU00gZ3JvdXAgKHNlZSBmaWd1cmUgMSBvZiBSRkM1 NzYwKS4gIFRoZQ0KDQogICBtb25pdG9yIHdpbGwgbmVlZCB0byBiZSBjby1sb2NhdGVkIHdpdGgg dGhlIGZlZWRiYWNrIHRhcmdldCB0bw0KDQogICByZWNlaXZlIGFsbCBmZWVkYmFjayBmcm9tIHRo ZSByZWNlaXZlcnMgKHRoaXMgbWF5IGFsc28gYmUgYW4NCg0KICAgaW50ZXJtZWRpYXRlIHN5c3Rl bSkuICBJbiBib3RoIEFTTSBhbmQgU1NNIHNjZW5hcmlvcywgcmVjZWl2ZXJzIGNhbg0KDQogICBz ZW5kIFJUQ1AgWFIgcmVwb3J0cyB0byBlbmhhbmNlIHRoZSByZWNlcHRpb24gcXVhbGl0eSByZXBv cnRpbmcuDQoNCiANCg0KIg0KDQoNCj4gSW4gdGhlIGRlZmluaXRpb24gb2YgQ29tcG9zZWQgbWV0 cmljcywgdGhlIHNlbnRlbmNlICJBbiBleGFtcGxlIGlzIGEgDQo+IG1ldHJpYyBjYWxjdWxhdGVk IGJhc2VkIG9uIGRlcml2ZWQgbWV0cmljcyB0aGF0IGhhdmUgYmVlbiBtZWFzdXJlZC4iIA0KPiBt YWtlcyBsaXR0bGUgc2Vuc2UuIA0KDQpbUWluXSBUaGUgZGVyaXZlZCBtZXRyaWNzIGluIHRoZSBz ZW50ZW5jZSBzaG91bGQgYmVlbiBjb3JyZWN0ZWQgYXMgImRpcmVjdCBtZXRyaWMiLg0KDQoNCj5E aWQgeW91IG1lYW4gc29tZXRoaW5nIGxpa2UgIkFuIGV4YW1wbGUgaXMgYSBtZXRyaWMgDQo+IGRl cml2ZWQgYnkgYWxnb3JpdGhtaWNhbGx5IGNvbWJpbmluZyBtZWFzdXJlZCBtZXRyaWNzLiI/DQoN CltRaW5dOkkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGFuZCBsaWtlIHRvIGFkb3B0 IHlvdXIgc3VnZ2VzdGlvbi4NCg0KPiBUaGUgZGVmaW5pdGlvbnMgb2YgSW50ZXJ2YWwsIEN1bXVs YXRpdmUsIGFuZCBTYW1wbGVkIG1ldHJpY3MgYXJlIG5vdCBjbGVhci4NCg0KW1Fpbl06IEkgYWdy ZWUgdGhlIGRlZmluaXRpb24gZm9yIHRoZXNlIHRocmVlIG1ldHJpY3MgbmVlZCB0byBiZSBtb3Jl IGNsZWFlciwgSSBwcm9wb3NlcyB0byBkbyB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCk5FVyBU ZXh0Og0KDQoiDQoNCiAgIEludGVydmFsIG1ldHJpY3MNCg0KIA0KDQogICAgICBNZXRyaWNzIG9m IHdoaWNoIHRoZSByZXBvcnRlZCB2YWx1ZXMNCg0KICAgICAgYXJlIG1lYXN1cmVkIGluIHRoZSBt b3N0IHJlY2VudCBtZWFzdXJlbWVudCBpbnRlcnZhbCBkdXJhdGlvbiBiZXR3ZWVuDQoNCiAgICAg IHN1Y2Nlc3NpdmUgbWV0cmljcyByZXBvcnRzLiBTdWNoIG1lYXN1cmVtZW50IGludGVydmFsIGlz IGVxdWFsIHRvIG9uZSANCg0KICAgICBSVENQIHJlcG9ydCBpbnRlcnZhbCAoUkZDMzU1MCxTZWN0 aW9uIDYuMikuIA0KDQogDQoNCiANCg0KICAgQ3VtdWxhdGl2ZSBtZXRyaWNzDQoNCiANCg0KICAg ICAgTWV0cmljcyBvZiB3aGljaCB0aGUgcmVwb3J0ZWQgdmFsdWVzDQoNCiAgICAgIGFwcGx5IHRv IHRoZSBhY2N1bXVsYXRpb24gcGVyaW9kIGNoYXJhY3RlcmlzdGljIG9mIGN1bXVsYXRpdmUNCg0K ICAgICAgbWVhc3VyZW1lbnRzLiBUaGUgcmVwb3J0ZWQgdmFsdWVzIGFyZSBtZWFzdXJlZCBkdXJp bmcgdGhlIGFjY3VtdWxhdGlvbiBwZXJpb2QuIA0KDQogICBUaGUgYWNjdW11bGF0aW9uIHBlcmlv ZCBzcGFucyBvdmVyIG1vcmUgdGhhbiBvbmUgUlRDUCByZXBvcnQgaW50ZXJ2YWxzLg0KDQogDQoN CiANCg0KICAgU2FtcGxlZCBtZXRyaWNzDQoNCiANCg0KICAgICAgTWV0cmljcyBvZiB3aGljaCB0 aGUgcmVwb3J0ZWQgdmFsdWVzIG9ubHkNCg0KICAgICAgYXBwbHkgdG8gdGhlIHZhbHVlIG9mIGEg Y29udGludW91c2x5IG1lYXN1cmVkIG9yIGNhbGN1bGF0ZWQgbWV0cmljDQoNCiAgICAgIHRoYXQg aGFzIGJlZW4gc2FtcGxlZCBhdCBhbnkgZ2l2ZW4gaW5zdGFuY2Ugb2YgdGhlIFJUQ1AgcmVwb3J0 IGludGVydmFsLiANCg0KICAgICBPbmUgZXhhbXBsZSBvZiBzdWNoIG1ldHJpYyBpcyB0aGUgaW50 ZXItYXJyaXZhbCBqaXR0ZXIgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIDYuNC4xIG9mIFJGQzM1 NTAuDQoNCiINCg0KPiBJZiB0aGUgZGlzY3Vzc2lvbiBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gMy4x IGlzIGtlcHQsIHRoZSByZWZlcmVuY2UgdG8gDQo+IFJGQzU3NjAgc2hvdWxkIGJlIGEgcmVhbCBy ZWZlcmVuY2UsIGFuZCBSRkM1NzYwIHNob3VsZCBhcHBlYXIgaW4gdGhlIA0KPiByZWZlcmVuY2Ug c2VjdGlvbi4NCg0KW1Fpbl06IE9rYXkuIA0KDQo+IFRoZSBwb2ludCBvZiBzZWN0aW9uIDMuMiBp cyBub3Qgb2J2aW91cy4gSG93IGRvZXMgaXQgY29udHJpYnV0ZSB0byB0aGUgDQo+IGRlc2NyaXB0 aW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUuIEl0IG1peGVzIHRhbGtpbmcgYWJvdXQgd2hhdCByZXBv cnQgDQo+IGJsb2NrcyBhcmUgd2l0aCBvY2Nhc2lvbmFsbHkgbmVlZGluZyB0byBzZW5kIHRoZW0g bW9yZSBmcmVxdWVudGx5LiBUaG9zZSANCj4gcG9pbnRzIGNvdWxkIGJlIG1hZGUgc2VwYXJhdGVs eSBhbmQgbW9yZSBzaW1wbHkuDQoNCltRaW5dOiBPa2F5LiBJIGxpa2UgdG8gaW5jb3Jwb3JhdGUg dGhlIGtleSBwb2ludHMgaW4gdGhlIHNlY3Rpb24gMy4yIGludG8gc2VjdGlvbiAzLjENCg0KPiBT ZWN0aW9uIDMuMyBpcyBub3QgY2xlYXIgLSBpdCBzdGFydHMgb2ZmIHNheWluZyB0aGF0IHRoZSBs b2NhdGlvbiBvZiB0aGUgDQo+IHNlbmRlciBhbmQgcmVjZWl2ZXIgbWF5IGNoYW5nZSB3aGF0IG1l dHJpY3MgYXJlIG1lYW5pbmdmdWwuIEl0J3Mgbm90IA0KPiBjbGVhciB3aGF0IHlvdSBtZWFuIGJ5 IGxvY2F0aW9uLiBZb3UgY2VydGFpbmx5IGRvbid0IG1lYW4gZ2Vvc3BhdGlhbCANCj4gY29vcmRp bmF0ZXMuIERvIHlvdSBtZWFuIGFueXRoaW5nIG90aGVyIHRoYW4gd2hldGhlciB0aGUgZWxlbWVu dCBpcyANCj4gdHJ1c3RlZCBvciB1bnRydXN0ZWQgYnkgdGhlIG9wZXJhdGlvbnMgbmV0d29yaz8g SWYgc28sIHNheSB0aGF0LiBUaGUgDQo+IHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBvbmx5IHNwZWFr cyB0byB3aGF0IGVsZW1lbnQgY29sbGVjdHMgdGhlIG1ldHJpY3MuIA0KDQpbUWluXSBTZWN0aW9u IDMuMyBpcyBvbmx5IHVzZWQgdG8gZGVzY3JpYmUgd2hlcmUgb3IgZnJvbSB3aGljaCBSVFAgZW50 aXR5IA0KDQp0byBnYXRoZXIgdGhlIG1ldHJpY3MgKGkuZS4sIG1lYXN1cmVtZW50IHBvaW50KSBp biB0aGUgcGh5c2ljYWwgbmV0d29yayBhbmQNCg0KIGlzIG5vdCBmb2N1cyBvZiB0aGlzIGRvY3Vt ZW50LiBTZWNvbmRseSwgDQoNCkkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2YgYXBwbGljYXRpb24g bGV2ZWwgbWV0cmljcyBoYXMgYWxyZWFkeSBjbGFyaWZpZWQgdGhhdCANCg0KYXBwbGljYXRpb24g bGV2ZWwgbWV0cmljcyBpcyBub3JtYWxseSBnYXRoZXJlZCBmcm9tIHVzZXIgZW5kcG9pbnQuDQoN Cg0KPiBJdCdzIG5vdCBjbGVhciB0aGF0IHRoZSBzZXQgb2YgbWVhbmluZ2Z1bCBtZXRyaWNzIGlz IGNoYW5nZWQgYXQgYWxsIC0gDQo+IGp1c3Qgd2hlcmUgeW91IGNvbGxlY3QgdGhlbS4gSWYgdGhl IHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MgZG9lcyBpbiANCj4gZmFjdCBjaGFuZ2UsIHRoZXJl IG5lZWRzIHRvIGJlIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbiBoZXJlLg0KDQpbUWluXTogVGhlIG1l dHJpY3MgYWN0dWFsbHkgZG9lc24ndCBjaGFuZ2UuU2luY2UgdGhlIGRlZmluaXRpb24gb2YgYXBw bGljYXRpb24gbGV2ZWwgbWV0cmljcyANCg0KSGF2ZSBhbHJlYWR5IGNvbnZleWVkIHRoZSBtZWFu aW5nIG9mIHdoYXQgc2VjdGlvbiAzLjMgd2FudHMgdG8gZGVzY3JpYmUsIEkgcHJvcG9zZSB0byBy ZW1vdmUNCg0KdGhpcyBzZWN0aW9uLg0KDQo+IFNlY3Rpb24gNCdzIGZpcnN0IHBhcmFncmFwaDog SXMgICJwcm9iYWJseSIgdGhlIGJlc3QgdGhlIHdvcmtpbmcgZ3JvdXAgDQo+IGNhbiBzYXk/DQoN CltRaW5dOk5vLCB3aWxsIHJlbW92ZSB0aGlzIHdvcmQuDQoNCg0KPiBUaGUgbGFzdCB0d28gc2Vu dGVuY2VzIG9mIHRoZSBzZWNvbmQgYnVsbGV0IGluIHNlY3Rpb24gNCBkbyBub3QgcGFyc2UuIA0K PiBQbGVhc2Ugc2ltcGxpZnkgdGhlbS4NCg0KW1Fpbl06IE9rYXksIGhvdyBhYm91dCBjaGFuZ2Ug dGhlbSBhcyBmb2xsb3dzOg0KDQpORVcgVGV4dDoNCg0KIg0KDQogICAgIFdpdGggdGhlc2UgbWlu aW1hbCBudW1iZXIgb2YNCg0KICAgICAgUlRDUCBzdGF0aXN0aWNzIHBhcmFtZXRlcnMgbWFwcGVk IHRvIG5vbi1SVENQDQoNCiAgICAgIG1lYXN1cmVtZW50cywgaXQgaXMgaGFyZCB0byBwcm92aWRl IGFjY3VyYXRlDQoNCiAgICAgIG1lYXN1cmVzIG9mIHJlYWwgdGltZSBhcHBsaWNhdGlvbiBxdWFs aXR5LGNvbmR1Y3QgDQoNCiAgICAgZGV0YWlsZWQgZGF0YSBhbmFseXNpcyBhbmQgY3JlYXRlcyBh bGVydHMgdGltbHkgdG8gdGhlDQoNCiAgICAgIHVzZXJzLiBUaGVyZWZvcmUgY29ycmVsYXRpb24g YmV0d2VlbiBSVENQIFhSIGFuZA0KDQogICAgICBub24tUlRQIGRhdGEgc2hvdWxkIGJlIHByb3Zp ZGVkLg0KDQoNCiINCg0KPiBUaGUgZmlyc3QgZnVsbCBzZW50ZW5jZSBvZiB0aGUgdGhpcmQgYnVs bGV0IGluIHNlY3Rpb24gNCBkb2VzIG5vdCBtYWtlIA0KPiBzZW5zZS4gVGhlIHdob2xlIGJ1bGxl dCBjb3VsZCBiZSBjbGFyaWZpZWQuDQoNCltRaW5dOiBBZ3JlZSBhbmQgd2lsbCByZW1vdmUgdGhl IGZpcnN0IHNlbnRlbmNlLg0KDQo+IFRoZSBmb3VydGggYnVsbGV0IGluIHNlY3Rpb24gNCBhbmQg c2VjdGlvbiA1LjUgc2hvdWxkIGNhbGwgb3V0IHRoYXQgDQo+IFJGQzM2MTEgYWxyZWFkeSBzZXQg QmxvY2sgVHlwZSAyNTUgYXNpZGUgZm9yIGZ1dHVyZSBleHRlbnNpb25zLCANCj4gYW50aWNpcGF0 aW5nIHRoZSBwb3RlbnRpYWwgbmVlZCB0byBleHRlbmQgdGhlIGJsb2NrIHR5cGUgc3BhY2UuDQoN CltRaW5dOiBPa2F5LCBIb3cgYWJvdXQgcmV2aXNpbmcgdGhlIHNlY3Rpb24gNCxidWxsZXQgNCBh cyBmb2xsb3dzOg0KDQoiDQoNCkNvbnN1bXB0aW9uIG9mIFhSIGJsb2NrIGNvZGUgcG9pbnRzLiAg VGhlIFJUQ1AgWFIgYmxvY2sgbmFtZXNwYWNlDQoNCiAgICAgIGlzIGxpbWl0ZWQgYnkgdGhlIDgt Yml0IGJsb2NrIHR5cGUgZmllbGQgaW4gdGhlIFJUQ1AgWFIgaGVhZGVyLg0KDQogICAgICBTcGFj ZSBleGhhdXN0aW9uIG1heSBiZSBhIGNvbmNlcm4gaW4gdGhlIGZ1dHVyZS4gQW50aWNpcGF0aW5n IHRoZQ0KDQogcG90ZW50aWFsIG5lZWQgdG8gZXh0ZW5kIHRoZSBibG9jayB0eXBlIHNwYWNlLCBp dCBpcyBub3RlZCBpbiBbUkZDMzYxMV0NCg0KIHRoYXQgQmxvY2sgVHlwZSAyNTUgaXMgcmVzZXJ2 ZWQgZm9yIGZ1dHVyZSBleHRlbnNpb25zLCANCg0KIg0KDQo+IEluIHNlY3Rpb24gNSwgY29uc2lk ZXIgbmFtaW5nIHRoZSBzdWJzZWN0aW9ucyB3aXRoIHRoZSBhY3R1YWwgZ3VpZGVsaW5lIA0KPiBp bnN0ZWFkIG9mIHRoZSBwcm9ibGVtIHRoZSBndWlkZWxpbmUgaXMgdHJ5aW5nIHRvIGFkZHJlc3Mu DQo+IDUuMS4gTWV0cmljIGJsb2NrcyBzaG91bGQgY29udGFpbiBhIHNpbmdsZSBtZXRyaWMNCg0K W1Fpbl06IEkgc3VnZ2VzdCB0byBjaGFuZ2UgaXQgYXMgIkNvbnRhaW4gdGhlIHNpbmdsZSBtZXRy aWNzIGluIHRoZSBtZXRyaWMgYmxvY2siDQoNCj4gNS4yLiBJbmNsdWRlIHRoZSBwYXlsb2FkIHR5 cGUgYW5kIGZvcm1hdCBwYXJhbWV0ZXJzIGluIHRoZSBtZXRyaWMgYmxvY2sNCg0KW1Fpbl06IE9r YXkuDQoNCj4gNS4zLiBVc2UgUlRDUCBTREVTIHRvIGNvcnJlbGF0ZSBYUiByZXBvcnRzIHdpdGgg bm9uLVJUUCBkYXRhDQoNCltRaW5dOiBPa2F5Lg0KDQo+IDUuNC4gRG9uJ3QgcmVwZWF0IG1lYXN1 cmVtZW50IGluZm9ybWF0aW9uIGFjcm9zcyBtZXRyaWMgYmxvY2tzDQo+IA0KW1Fpbl06IEl0IGlz IG5vdCBwb3NzaWJsZSBjb21wbGV0ZWx5IHRvIGF2b2lkIG1lYXN1cmVtZW50IGluZm9ybWF0aW9u IHJlcGVhdGl0aW9uLg0KDQplLmcuLCBmb3IgcGFja2V0IGxvc3Mgcm9idXN0bmVzcyBpZiB0aGUg cmVwb3J0IGJsb2NrcyBmb3IgdGhlIHNhbWUgaW50ZXJ2YWwNCg0KICAgc3BhbiBvdmVyIG1vcmUg dGhhbiBvbmUgUlRDUCBwYWNrZXQgdGhlbiBlYWNoIG11c3QgaGF2ZSB0aGUNCg0KICAgc2FtZSBt ZWFzdXJlbWVudCBpZGVudGl0eSBpbmZvcm1hdGlvbiANCg0KU28gSSBzdWdnZXN0IHRvIGNoYW5n ZSBpdCBhczoNCg0KInJlZHVjZSBtZWFzdXJlbWVudCBpbmZvcm1hdGlvbiBhY3Jvc3MgbWV0cmlj IGJsb2NrcyINCg0KDQo+IFRoaXMgcG9pbnRzIG91dCBhIHN0cnVjdHVyYWwgcHJvYmxlbSB3aXRo IHRoZSBzZWN0aW9uLiBXaHkgaXMgNS41IGhlcmU/IA0KPiBJdCdzIG5vdCBhIGd1aWRlbGluZS4N Cg0KW1Fpbl06IEFncmVlIGFuZCBhbHNvIGFzIGRpc2N1c3NlZCxTcGFjZSBleGhhdXN0aW9uIGlz IG5vdCBiaWcgaXNzdWUuIEhvdyBhYm91dCByZW1vdmUgdGhpcyBzZWN0aW9uPw0KDQo+ICgqKSBB bmQgaXQgcmFpc2VzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUgZG9jdW1lbnQgaXMgdHJ5aW5n IHRvIA0KPiBhY2hpZXZlIHdpdGggc2VjdGlvbiA1LjQuIFRoYXQgc2VjdGlvbiBjbGFpbXMgdGhl IGRvY3VtZW50IGlzIHByb3Bvc2luZyANCj4gYSBuZXcgWFIgYmxvY2sgdHlwZSB0byBoZWxwIGF2 b2lkIGR1cGxpY2F0aW9uLCBidXQgaXQgZG9lc24ndCBhY3R1YWxseSANCj4gZGVmaW5lIHRoZSBu ZXcgYmxvY2sgdHlwZS4gSXMgdGhlIGd1aWRlbGluZSBzYXlpbmcgc2ltcGx5IGRvbid0IHJlcGVh dCANCj4gbWVhc3VyZW1lbnRzIG9yIGl0cyB0aGUgZ3VpZGVsaW5lIHNheWluZyAidXNlIHRoaXMg bmV3IFhSIGJsb2NrIHR5cGUgd2UgDQo+IGhhdmVuJ3QgZGVmaW5lZCB5ZXQiPyANCg0KW1Fpbl06 IEp1c3QgdG8gY2xhcmlmeSwgd2UgaGF2ZSBhbHJlYWR5IGRlZmluZWQgb25lIG5ldyBYUiBCbG9j ayANCg0KdHlwZSB0byBoZWxwIGF2b2lkIG9yIHJlZHVjZSBkdXBsaWNhdGlvbi4gSXQgaXMgbWVh c3VyZW1lbnQgaW5mb3JtYXRpb24gDQoNCmJsb2NrLiBUaGUgcmVsZXZhbnQgZHJhZnQgaXMgYXZh aWxhYmxlIGF0Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXhyYmxv Y2stcnRjcC14ci1tZWFzLWlkZW50aXR5LTA2DQoNCg0KPlRoZSBzZWN0aW9uIG5lZWRzIG1vcmUg Y2xhcml0eS4gSWYgaXQgcmVhbGx5IGlzIA0KPiB0cnlpbmcgdG8gZGVmaW5lIGEgbmV3IHR5cGUs IHRoZXJlJ3MgbW9yZSB3b3JrIHRvIGJlIGRvbmUuDQoNCltRaW5dOiBJbiBvcmRlciB0byBhdm9p ZCBzdWNoIGNvbmZ1c2lvbiwgSSBwcm9wb3NlZCB0byBkbyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0 byB0aGUgc2VjdGlvbiA1LjQ6DQoNCk9MRCBUZXh0Og0KDQoiDQoNClRoaXMgbWVtbyBwcm9wb3Nl cyB0bw0KDQogICBkZWZpbmUgYSBuZXcgWFIgQmxvY2sgdGhhdCB3aWxsIGJlIHVzZWQgdG8gY29u dmV5IHRoZSBjb21tb24gdGltZQ0KDQogICBwZXJpb2QgYW5kIHRoZSBudW1iZXIgb2YgcGFja2V0 cyBzZW50IGR1cmluZyB0aGlzIHBlcmlvZC4NCg0KIg0KDQpOZXcgdGV4dDoNCg0KIg0KDQpUaGlz IG1lbW8gcHJvcG9zZXMgdG8NCg0KICAgZGVmaW5lIGEgbmV3IFhSIEJsb2NrIChpLmUuLCB0aGUg TWVhc3VyZW1lbnQNCg0KICAgaW5mb3JtYXRpb24gYmxvY2tbSS5ELWlldGYteHJibG9jay1ydGNw LXhyLW1lYXMtaWRlbnRpdHldKSB0aGF0IHdpbGwgYmUgdXNlZCB0byBjb252ZXkgdGhlIGNvbW1v biB0aW1lDQoNCiAgIHBlcmlvZCBhbmQgdGhlIG51bWJlciBvZiBwYWNrZXRzIHNlbnQgZHVyaW5n IHRoaXMgcGVyaW9kLg0KDQoiDQoNCj4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rp b24sIHBhcnRpY3VsYXJseSB0aGUgdGhpcmQgcGFyYWdyYXBoLCANCj4gbmVlZHMgdG8gYmUgY2xl YXJlci4gV2hhdCBleGFjdGx5IGRvIHlvdSBtZWFuIGJ5ICJtb25pdG9yaW5nIHNob3VsZCBiZSAN Cj4gcHJvaGliaXRlZCIsIGFuZCBob3cgaXMgdGhlIGZhY3QgdGhhdCB0aGlyZCBwYXJ0eSBtb25p dG9ycyBkb24ndCBzZW5kIA0KPiBSVENQIHJlbGV2YW50PyBEaWQgeW91IGludGVuZCB0aG9zZSB0 byBiZSBzZXBhcmF0ZSBwb2ludHM/DQoNCltRaW5dOiBZZXMsIHRoZXkgYXJlIG9uIHRoZSBkaWZm ZXJlbnQgcG9ydC4gU3VjaCBtb25pdG9yIG1heSByZWNlaXZlIFJUUCBwYWNrZXQgYnV0IGRvZXMg bm90IHNlbmQgUlRDUCBwYWNrZXQuDQoNCj4gRWRpdG9yaWFsIE5pdHMgYW5kIFN1Z2dlc3Rpb25z Og0KPiANCj4gVGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgaW50cm9kdWN0aW9uIGlzIG92ZXJs eSBjb21wbGV4LCBhbmQgd29uJ3QgYWdlIA0KPiB3ZWxsLiBJIHN1Z2dlc3QgcmVwbGFjaW5nIGl0 IHdpdGg6ICJNdWx0aW1lZGlhIHNlcnZpY2VzIHVzaW5nIHRoZSANCj4gUmVhbC1UaW1lIFByb3Rv Y29sIChSVFApIGFyZSBzZWVpbmcgaW5jcmVhc2VkIHVzZS4gU3RhbmRhcmQgbWV0aG9kcyBmb3Ig DQo+IGdhdGhlcmluZyBSVFAgcGVyZm9ybWFuY2UgbWV0cmljcyBmcm9tIHRoZXNlIGFwcGxpY2F0 aW9ucyBhcmUgbmVlZGVkIHRvIA0KPiBtYW5hZ2UgdW5jZXJ0YWludGllcyBpbiB0aGUgYmVoYXZp b3IgYW5kIGF2YWlsYWJpbGl0eSBvZiB0aGVpciANCj4gc2VydmljZXMuIiBUaGVuIHJlcGxhY2Ug IlRoZXNlIHJhcGlkbHkgZW1lcmdpbmcgc3RhbmRhcmRzLCIgd2l0aCANCj4gIlN0YW5kYXJkcyIu DQoNCltRaW5dOiBPa2F5Lg0KDQo+IEludHJvZHVjdGlvbiBwYXJhZ3JhcGggMyBzZW50ZW5jZSAy IHNob3VsZCBzdGFydCAiVGhlIFJUQ1AgR3VpZGVsaW5lcyANCj4gW1JGQzU5NjhdIi4gSXQgd291 bGQgYmUgZXZlbiBiZXR0ZXIgdG8gdXNlIHRoZSBmdWxsIHRpdGxlIGZyb20gNTk2ODogDQo+ICdU aGUgIkd1aWRlbGluZXMgZm9yIEV4dGVuZGluZyB0aGUgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJU Q1ApIiBbUkZDNTk2OF0nDQoNCltRaW5dOiBPa2F5Lg0KDQo+IFRoaXMgbWF5IGJlY29tZSBtb290 IGFzIHNlY3Rpb24gMyBpcyBtb2RpZmllZCB0byBtYWtlIGl0cyBtYWluIHBvaW50IA0KPiBtb3Jl IG9idmlvdXMsIGJ1dCBSRkMzNTUwIGRvZXMgbm90IGNoYXJhY3Rlcml6ZSBNb25pdG9ycyBhcyAi YSBzb3VyY2Ugb2YgDQo+IGluZm9ybWF0aW9uIi4gVGhhdCBjb3VsZCBiZSBtaXN1bmRlcnN0b29k LiBQbGVhc2UgY2hvb3NlIGFub3RoZXIgd29yZC4gDQo+IFBlcmhhcHMgInJlcG9zaXRvcnkiPw0K DQpbUWluXTogT2theSwgcmVwb3NpdG9yeSBsb29rcyBnb29kIHRvIG1lLg0KDQo+IEluIGJ1bGxl dCBsaXN0cywgc3RhcnRpbmcgYW4gZW50cnkgd2l0aCAib3IiIG9yICJhbmQiIGlzIHVubmVjZXNz YXJ5LiBJdCANCj4gc2hvdWxkIGJlIGNsZWFyIGZyb20gdGhlIGludHJvZHVjdGlvbiB0byB0aGUg bGlzdCB3aGV0aGVyIHRoZSBpbmRpdmlkdWFsIA0KPiBlbnRyaWVzIHNob3VsZCBiZSBjb21iaW5l ZCBvciBzZWxlY3RlZCBmcm9tLg0KDQpbUWluXTogT2theS4NCg0KPiBJbiBzZWN0aW9uIDMuMSB3 aGVyZSB5b3Ugc2F5ICJSVFAgbWF5IGJlIHVzZWQgdG8gbXVsdGljYXN0IGdyb3VwcyIgZGlkIA0K PiB5b3UgbWVhbiAiUlRQIG1heSBiZSBzZW50IHRvIG11bHRpY2FzdCBncm91cHMiIG9yICJSVFAg bWF5IGJlIHVzZWQgd2l0aCANCj4gbXVsdGljYXN0IGdyb3VwcyI/DQoNCltRaW5dOiBJIHRoaW5r IGl0IHNob3VsZCBiZSB0aGUgbGF0dGVyIGNhc2UsaS5lLiwiIFJUUCBtYXkgYmUgdXNlZCB3aXRo IA0KbXVsdGljYXN0IGdyb3VwcyIuDQoNCj4gDQo+IEluIHNlY3Rpb24gMy4yICJUaGUgZm9sbG93 aW5nIGFyZSBmb3VyIHVzZSBjYXNlcyBidXQgYXJlIG5vdCBsaW1pdGVkIA0KPiB0bzoiIGRvZXMg bm90IHBhcnNlLiBUaGUgYnVsbGV0cyBhcmVuJ3QgcmVhbGx5IHVzZSBjYXNlcyBhcyBtdWNoIGFz IHRoZXkgDQo+IGFyZSBtZWNoYW5pc21zLiBXb3VsZCBpdCBtYWtlIG1vcmUgc2Vuc2UgdG8gc2F5 ICJIZXJlIGFyZSBmb3VyIA0KPiBtZWNoYW5pc21zIHRoYXQgaGF2ZSBiZWVuIGNyZWF0ZWQgdG8g YWRkcmVzcyB0aGUgbmVlZCBmb3IgbW9yZSBmcmVxdWVudCANCj4gcmVwb3J0aW5nLiBUaGlzIGxp c3QgaXMgbm90IGludGVuZGVkIHRvIGJlIGV4aGF1c3RpdmUuIiBUaGUgdGhpcmQgYnVsbGV0IA0K PiBpbiB0aGF0IGxpc3Qgc2hvdWxkIHNheSAiUlRDUCBhbmQgUlRDUCBYUiBhcmUiIGluc3RlYWQg b2YgIlJUQ1Agb3IgUlRDUCANCj4gWFIgaXMiLg0KDQpbUWluXTogT2theSwgYnV0IEkgaGF2ZSBp bmNvcnBvcmF0ZWQgdGhlIGtleXBvaW50cyBvZiBzZWN0aW9uIDMuMiBpbnRvIHNlY3Rpb24gMy4x Lg0KDQo+IFRoZSBidWxsZXRzIGluIHNlY3Rpb24gNCB3b3VsZCBiZSBiZXR0ZXIgYXMgc3Vic2Vj dGlvbnMgd2l0aCB0aXRsZXMgDQo+ICh0YWtlbiBmcm9tIHRoZSBmaXJzdCBwaHJhc2Ugb2YgdGhl IGJ1bGxldCkuDQoNCltRaW5dOiBPa2F5Lg0KDQo+IEkgc3VnZ2VzdCB0aGlzIGFsdGVybmF0aXZl IGZvciB0aGUgZmlyc3QgZnVsbCBzZW50ZW5jZSBpbiB0aGUgZmlyc3QgDQo+IGJ1bGxldCBvZiBz ZWN0aW9uIDQgOiAiQSBjb21wb3VuZCBtZXRyaWNzIGJsb2NrIGlzIGRlc2lnbmVkIHRvIGNvbnRh aW4gYSANCj4gbGFyZ2UgbnVtYmVyIG9mIHBhcmFtZXRlcnMgZnJvbSBkaWZmZXJlbnQgY2xhc3Nl cyBmb3IgYSBzcGVjaWZpYyANCj4gYXBwbGljYXRpb24gaW4gYSBzaW5nbGUgYmxvY2suIg0KDQpb UWluXTogT2theS4NCg0KPiBTZWN0aW9uIDUncyB0aXRsZSBzaG91bGQgYmUgIkd1aWRlbGluZXMg Zm9yIHJlcG9ydGluZyIgaW5zdGVhZCBvZiANCj4gIkd1aWRlbGluZSBmb3IgcmVwb3J0aW5nIg0K DQpbUWluXTogT2theS4NCg0KPiBJbiBzZWN0aW9uIDUuMSBJIHN1Z2dlc3QgImp1c3RpZnkgdGhl IG92ZXJoZWFkLCIgaW5zdGVhZCBvZiAianVzdGlmeSB0aGUgDQo+IG92ZXJoZWFkcywiDQoNCltR aW5dOiBPa2F5Lg0KDQo+IFNlY3Rpb24gNyAtIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBmaXJz dCBwYXJhZ3JhcGggZG9lcyBub3QgcGFyc2UuIFRoZSANCj4gc2Vjb25kIHBhcmFncmFwaCAod2hp Y2ggaXMgYSBzaW5nbGUgc2VudGVuY2UpIHNob3VsZCBiZSBjbGFyaWZpZWQgLSBhbiANCj4gTUNV IGlzIG5vdCBhIHRvcG9sb2d5Lg0KDQoNCg0KW1Fpbl06IE9rYXkuIEhvdyBhYm91dCByZXZpc2lu ZyB0aGVtIGFzIGZvbGxvd3M6DQoNCk9MRCBUZXh0Og0KDQoiDQoNClRoZSB0b3BvbG9naWVzIGlu IHRoaXMgY2F0ZWdvcnkNCg0KICAgYXJlIFRvcG8tVmlkZW8tU3dpdGNoLU1DVSBhbmQgVG9wby1S VENQLXRlcm1pbmF0aW5nLU1DVS4gIFN1Y2gNCg0KICAgdG9wb2xvZ2llcyBiYXNlZCBvbiBzeXN0 ZW1zIGRvIG5vdCBiZWhhdmUgYWNjb3JkaW5nIHRvIHRoZSBSVFANCg0KICAgcHJvdG9jb2wgW1JG QzM1NTBdLg0KDQogDQoNCiAgIENvbnNpZGVyaW5nIHRoZSBNQ1UgYW5kIHRyYW5zbGF0b3IgYXJl IHR3byB0eXBpY2FsIHRvcG9sb2dpZXMgaW4gdGhlDQoNCiAgIHR3byBjYXRlZ29yaWVzIG1lbnRp b25lZCBhYm92ZSwgdGhpcyBkb2N1bWVudCB3aWxsIHRha2UgdGhlbSBhcyB0d28NCg0KICAgdHlw aWNhbCBleGFtcGxlcyB0byBleHBsYWluIGhvdyBSVENQIFhSIHJlcG9ydCB3b3JrcyBpbiBkaWZm ZXJlbnQNCg0KICAgUkZDNTExNyB0b3BvbG9naWVzLg0KDQogDQoNCiINCg0KTkVXIFRleHQ6DQoN CiINCg0KVGhlIHRvcG9sb2dpZXMgaW4gdGhpcyBjYXRlZ29yeQ0KDQogICBhcmUgVG9wby1WaWRl by1Td2l0Y2gtTUNVIGFuZCBUb3BvLVJUQ1AtdGVybWluYXRpbmctTUNVLiAgU3VjaA0KDQogICB0 b3BvbG9naWVzIGJhc2VkIG9uIHN5c3RlbXMgKGUuZy4sTUNVKSBkbyBub3QgYmVoYXZlIGFjY29y ZGluZyB0byB0aGUgUlRQDQoNCiAgIHByb3RvY29sIFtSRkMzNTUwXS4NCg0KIA0KDQogICBDb25z aWRlcmluZyB0aGUgTUNVIGFuZCB0cmFuc2xhdG9yIGFyZSB0d28gdHlwaWNhbCBpbnRlcm1lZGlh cnkgc3lzdGVtcyBpbiB0aGUNCg0KICAgdHdvIGNhdGVnb3JpZXMgbWVudGlvbmVkIGFib3ZlLCB0 aGlzIGRvY3VtZW50IHdpbGwgdGFrZSB0aGVtIGFzIHR3bw0KDQogICB0eXBpY2FsIGV4YW1wbGVz IHRvIGV4cGxhaW4gaG93IFJUQ1AgWFIgcmVwb3J0IHdvcmtzIGluIGRpZmZlcmVudA0KDQogICBS RkM1MTE3IHRvcG9sb2dpZXMuDQoNCiANCg0KIg0KDQo+IFRoZSBsYXN0IHR3byBzZW50ZW5jZXMg b2YgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgc2VjdXJpdHkgDQo+IGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gYWRkIG5vdGhpbmcgdG8gdGhlIGRvY3VtZW50LiBJIHN1Z2dlc3QgZGVsZXRpbmcg dGhlbS4NCg0KW1Fpbl06IE9rYXkuDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFu Y2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXZ0DQo+ From bill.wu@huawei.com Mon May 21 23:56:05 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E39E8015 for ; Mon, 21 May 2012 23:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.246 X-Spam-Level: X-Spam-Status: No, score=-4.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 v4Yl5WXV11Lc for ; Mon, 21 May 2012 23:56:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E53C9E8011 for ; Mon, 21 May 2012 23:56:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGD34836; Tue, 22 May 2012 02:56:02 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 21 May 2012 23:53:32 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 21 May 2012 23:53:35 -0700 Received: from w53375 (10.138.41.149) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 14:53:30 +0800 Message-ID: <8550925CD2F24829AC4483B12606F03A@china.huawei.com> From: Qin Wu To: Albrecht Schwarz References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> Date: Tue, 22 May 2012 14:53:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:56:05 -0000 SGksOg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGJyZWNodCBTY2h3 YXJ6IiA8YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPg0KVG86IDxiaWxsLnd1QGh1YXdlaS5jb20+ DQpDYzogPGF2dEBpZXRmLm9yZz47IDxyanNwYXJrc0Bub3N0cnVtLmNvbT4NClNlbnQ6IFR1ZXNk YXksIE1heSAyMiwgMjAxMiAxMToxOCBBTQ0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBTdWJqZWN0 OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMNCg0KDQpEZWFyIEFs bCwNCg0KY29uY2VybmluZyB0aGUgcmVzb2x1dGlvbiBwcm9wb3NhbCBmb3IgY2xhdXNlIDMuMzoN CkkgZG9uJ3QgYWdyZWUgaW4ganVzdCBkZWxldGluZyBhZ2FpbiB0aGF0IHNlY3Rpb24hDQpUaGVy ZSB3YXMgcXVpdGUgYSBsb25nIGRlYmF0ZSBmb3IgaW5jb3Jwb3JhdGluZyBzdWNoIGEgY2xhdXNl Lg0KVGhlIG9yaWdpbmFsIHRleHQgcHJvcG9zYWwgd2FzIG11Y2ggbW9yZSBkZXRhaWxlZC4gUGVy aGFwcyB0aGUgc2hvcnRlbmluZyB0byBqdXN0IGEgc2luZ2xlIHBhcmFncmFwaCBpcyB0aGUgbWFp biBjYXVzZSBmb3IgdW5jbGFyaXR5Lg0KVGh1cywgaW5zdGVhZCBvZiByZW1vdmluZyBwcmV2aW91 cyBhZ3JlZWQgdGV4dCwgd2UganVzdCByYXRoZXIgZXh0ZW5kIGl0IGFnYWluLg0KDQoNCltRaW5d OiANClRoZSByZWFzb24gSSBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgc2VjdGlvbiAzLjMgaXMgDQph LiBJIHRoaW5rIFJvYmVydCBpcyBjb3JyZWN0LiBUaGUgc2V0IG9mIG1lYW5pbmdmdWwgbWV0cmlj cyBpc24ndCBjaGFuZ2VkIGF0IGFsbCAgd2hlcmV2ZXIgeW91IGNvbGxlY3QgdGhlbS4gSXQgc2Vl bXMgbGl0dGxlIHNlbnNlIA0KICAgIHRvIHNheSAidGhlIGxvY2F0aW9uIG9mIHRoZSBSVFAgU2Vu ZGVyL1JlY2VpdmVyIGVudGl0aWVzIG1heSBpbXBhY3QgYSBzZXQgb2YgbWVhbmluZ2Z1bCBtZXRy aWNzLiAiIA0KYi4gV2hlcmUgdG8gZ2F0aGVyIG9yIG1lYXN1cmUgbWV0cmljcyBjYW4gYmUgaW5k aWNhdGVkIGJ5IHRoZSBkZWZpbml0aW9uIG9mIFRyYW5zcG9ydCBtZXRyaWNzLCBFbmQgc3lzdGVt IG1ldHJpY3MgYW5kIGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MuDQpjLiBTZWN0aW9uIDMuMyBz ZWVtcyB0byBkaXNjdXNzIHdoZXJlIHRvIGdhdGhlciB3aGF0IG1ldHJpY3MuIFJlY29tbWVuZGF0 aW9uIElUVS1UIEcuMTA4MSBoYXZlIGFscmVhZHkgZGVmaW5lZCBmaXZlIG1vbml0b3JpbmcgcG9p bnRzIA0KICAgIHdoZXJlIHRoZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMgY2FuIGJlIG1hZGUu DQoNCj4gSSB0aGluayB0aGUgZGVmaW5pdGlvbiBvZiBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNz IGhhcyBhbHJlYWR5IGNsYXJpZmllZCB0aGF0ICBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGlz IG5vcm1hbGx5IGdhdGhlcmVkIGZyb20gdXNlciBlbmRwb2ludC4gDQoNCk5vLiBXZSBkaWQgZGlz Y3VzcyB0aGlzIGFscmVhZHkgZXh0ZW5zaXZlbHkuDQpBbiBSVFAgbWVkaWEgdHJhbnNsYXRvciBj b3VsZCBwcm92aWRlIGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgYmVjYXVzZSBlLmcuIHRlcm1p bmF0aW5nIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCBsYXllci4NClN1Y2ggYW4gUlRQIHRvcG9s b2d5IGlzIE5PVCBsb2NhdGVkIGluIGFuIHVzZXIgZW5kcG9pbnQhDQoNCltRaW5dOiBTb3JyeSwg SSBzaG91bGQgY29ycmVjdCBtZSB0byBzYXkgUW9FIG1ldHJpYyBpcyB1c3VzYWxseSBtZWFzdXJl ZCBhdCB0aGUgdXNlciBlbmRwb2ludC4NCg0KUmVnYXJkcywNCkFsYnJlY2h0DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KW0RhdGUgUHJldl1bRGF0ZSBOZXh0XVtUaHJlYWQgUHJl dl1bVGhyZWFkIE5leHRdW0RhdGUgSW5kZXhdW1RocmVhZCBJbmRleF0gDQpSZTogW0FWVENPUkVd IFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KKiBUbzogUm9iZXJ0IFNwYXJrcyA8cmpz cGFya3MgYXQgbm9zdHJ1bS5jb20+LCBJRVRGIEFWVENvcmUgV0cgPGF2dCBhdCBpZXRmLm9yZz4s IDxkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhdCB0b29scy5pZXRmLm9yZz4NCiogU3ViamVj dDogUmU6IFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3Jl LW1vbmFyY2gtMTMNCiogRnJvbTogUWluIFd1IDxiaWxsLnd1IGF0IGh1YXdlaS5jb20+DQoqIERh dGU6IEZyaSwgMTggTWF5IDIwMTIgMTg6Mzc6NTYgKzA4MDANCiogRGVsaXZlcmVkLXRvOiBhdnQg YXQgaWV0ZmEuYW1zbC5jb20NCiogTGlzdC1hcmNoaXZlOiA8aHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2F2dD4NCiogTGlzdC1oZWxwOiA8bWFpbHRvOmF2dC1yZXF1ZXN0QGll dGYub3JnP3N1YmplY3Q9aGVscD4NCiogTGlzdC1pZDogQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENv cmUgTWFpbnRlbmFuY2UgPGF2dC5pZXRmLm9yZz4NCiogTGlzdC1wb3N0OiA8bWFpbHRvOmF2dEBp ZXRmLm9yZz4NCiogTGlzdC1zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2F2dD4sIDxtYWlsdG86YXZ0LXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJz Y3JpYmU+DQoqIExpc3QtdW5zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L29wdGlvbnMvYXZ0PiwgPG1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXVuc3Vi c2NyaWJlPg0KKiBSZWZlcmVuY2VzOiA8NEZCMkUzMjMuMzA5MDQwNiBhdCBub3N0cnVtLmNvbT4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkhpLFJvYmVydDoNClRoYW5rIGZv ciB5b3VyIHZhbHVhYmxlIHJldmlldy4gcGxlYXNlIHNlZSBteSByZXBsaWVzIGlubGluZSBiZWxv d3MuIFJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IlJvYmVydCBTcGFya3MiIDxyanNwYXJrcyBhdCBub3N0cnVtLmNvbT4NClRvOiAiSUVURiBBVlRD b3JlIFdHIiA8YXZ0IGF0IGlldGYub3JnPjsgPGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoIGF0 IHRvb2xzLmlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTYsIDIwMTIgNzoxMyBBTQ0K U3ViamVjdDogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNv cmUtbW9uYXJjaC0xMyA+IFN1bW1hcnk6IFRoZXJlIGFyZSBpc3N1ZXMgdG8gcmVzb2x2ZSB3aXRo IGEgcmV2aXNlZCBJRCBiZWZvcmUgDQo+IHByb2dyZXNzaW5nIHRvIElFVEYgTEMuDQo+IA0KPiBJ dCdzIGEgc3RydWdnbGUgdG8gc2VlIHRoZSBfYXJjaGl0ZWN0dXJlXyB0aGlzIGRvY3VtZW50IGlz IHN1cHBvc2VkIHRvIA0KPiBkZXNjcmliZS4gSSBzdXNwZWN0IG1vc3Qgb2YgdGhlIHdvcmtpbmcg Z3JvdXAgZW5lcmd5IHdlbnQgaW50byBTZWN0aW9uIDUgDQo+ICh0aGUgZ3VpZGVsaW5lcyBmb3Ig d3JpdGluZyBYUiBibG9jayBkZWZpbml0aW9ucykgLSB0aGUgcmVzdCBvZiB0aGUgDQo+IGRvY3Vt ZW50IG5lZWRzIGEgc2ltaWxhciBsZXZlbCBvZiBhdHRlbnRpb24gdG8gZGV0YWlsLg0KPiANCj4g VGhlcmUgYXJlIHR3byBtYWpvciBpc3N1ZXMgdGhhdCBJJ3ZlIHRhZ2dlZCB3aXRoIGEgKCopLiBJ IGZvbGxvd2VkIGEgDQo+IG1vc3RseSBkb2N1bWVudC1vcmRlciBmbG93IGluc3RlYWQgb2YgZ3Jv dXBpbmcgdGhlIG1ham9yIGlzc3VlcyBhdCB0aGUgdG9wLg0KPiANCj4gKCopIEdpdmVuIHRoZSBk b2N1bWVudCdzIHRpdGxlLCBpdCBzaG91bGQgYmUgdmVyeSBlYXN5IHRvIGFuc3dlciAiV2hhdCAN Cj4gaXMgdGhlIG1vbml0b3JpbmcgYXJjaGl0ZWN0dXJlPyIgZm9yIHBlb3BsZSB3aG8gYXJlIHJl YWRpbmcgdGhpcyBkcmFmdCANCj4gZm9yIHRoZSBmaXJzdCB0aW1lLg0KPiBUaGUga2V5IG1lc3Nh Z2UgaXMgdGhhdCB0aGUgbW9uaXRvcmluZyBhcmNoaXRlY3R1cmUgY29uc2lzdHMgb2YgTW9uaXRv cnMgDQo+IHRoYXQgZXhjaGFuZ2UgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBNZXRyaWMgQmxvY2tz LiBbUWluXTogQWdyZWUuID5UaGUgdGV4dCBzaG91bGQgc2F5IA0KPiB0aGF0LiBbUWluXTogT2th eS4gPiBUaGVyZSBpcyBhIGxvdCBvZiBwcm9zZSBpbiBzZWN0aW9uIDMgYW5kIHZpc3VhbCBkZXRh aWwgaW4gdGhlIA0KPiBkaWFncmFtIGluIEZpZ3VyZSAxIHRoYXQgbWFrZXMgdGhhdCBleHRyZW1l bHkgZGlmZmljdWx0IHRvIHNlZS4gDQo+IFNpbXBsaWZ5aW5nIHRoZSBmaWd1cmUgYnkgcmVtb3Zp bmcgdGhlIGRldGFpbHMgYWJvdXQgYXBwbGljYXRpb25zIGFuZCANCj4gdHJhbnNwb3J0cywgb3Ig YXQgbGVhc3QgbW92aW5nIHRoZW0gdG8gYSBzZWNvbmQgZmlndXJlLCBtYWtpbmcgdGhlIA0KPiBN b25pdG9yIGJveGVzIHN0YW5kIG91dCwgYW5kIG1ha2luZyB0aGUgdHlwZXMgb2YgaW5mb3JtYXRp b24gZmxvd3MgKHRoZSANCj4gYXJyb3dzKSB2aXN1YWxseSBkaXN0aW5jdGl2ZSB3b3VsZCBoZWxw LiBTaW1wbGlmeSB0aGUgcHJvc2UgKG11Y2ggb2YgaXQgDQo+IGNvdWxkIGJlIHJlbW92ZWQpIHRv IGZvY3VzIG9uIHRoYXQga2V5IG1lc3NhZ2UuIFtRaW5dOiBBZ3JlZSwgSSBwcm9wb3NlIHRvIHJl bW92ZSB0aGUgZmlndXJlIDEgYW5kIHNxdWVlemUgdGhlIHNlY3Rpb24gMy4xIGFzIGZvbGxvd3M6 ICIgMy4xLiBPdmVydmlldyBUaGUgUlRQIG1vbml0b3JpbmcgYXJjaGl0ZWN0dXJlIGNvbXByaXNl cyB0aGUgZm9sbG93aW5nIHR3byBrZXkgZnVuY3Rpb25hbCBjb21wb25lbnRzIHNob3duIGJlbG93 OiBvIFJUUCBNb25pdG9yIG8gUlRQIE1ldHJpYyBCbG9jayBTdHJ1Y3R1cmUgUlRQIE1vbml0b3Ig aXMgdGhlIGZ1bmN0aW9uYWwgY29tcG9uZW50IGRlZmluZWQgaW4gdGhlIFJlYWwtdGltZSBUcmFu c3BvcnQgUHJvdG9jb2wgW1JGQzM1NTBdLiBJdCBhY3RzIGFzIGEgc291cmNlIG9mIGluZm9ybWF0 aW9uIGdhdGhlcmVkIGZvciBtb25pdG9yaW5nIHB1cnBvc2VzIGFuZCBleGNoYW5nZXMgaW5mb3Jt YXRpb24gd2l0aCB0aGUgb3RoZXIgUlRQIG1vbml0b3JzIHVzaW5nIFJUQ1AgTWV0cmljIEJsb2Nr cy4gQWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0aW9uIG9mIG1vbml0b3IgaW4gdGhlIFJUUCBQcm90 b2NvbCBbUkZDMzU1MF0sIHRoZSBlbmQgc3lzdGVtIHRoYXQgcnVucyBhbiBhcHBsaWNhdGlvbiBw cm9ncmFtIHRoYXQgc2VuZHMgb3IgcmVjZWl2ZXMgUlRQIGRhdGEgcGFja2V0cywgYW4gaW50ZXJt ZWRpYXRlLSBzeXN0ZW0gdGhhdCBmb3J3YXJkcyBSVFAgcGFja2V0cyB0byBFbmQtZGV2aWNlcyBv ciBhIHRoaXJkIHBhcnR5IHRoYXQgb2JzZXJ2ZXMgdGhlIFJUUCBhbmQgUlRDUCB0cmFmZmljIGJ1 dCBkb2VzIG5vdCBtYWtlIGl0c2VsZiB2aXNpYmxlIHRvIHRoZSBSVFAgU2Vzc2lvbiBwYXJ0aWNp cGFudHMgKGkuZS4sIHRoZSB0aGlyZCBwYXJ0eSBtb25pdG9yIGRlcGljdGVkIGluIGZpZ3VyZSAx KSBjYW4gYWN0IGFzIHRoZQ0KIFJUUCBtb25pdG9yLiBUaGUgdGhpcmQgcGFydHkgbW9uaXRvciBz aG91bGQgYmUgcGxhY2VkIG9uIHRoZSBSVFAvUlRDUCBwYXRocyBiZXR3ZWVuIHRoZSBzZW5kZXIs IGludGVybWVkaWF0ZSBhbmQgdGhlIHJlY2VpdmVyLiBUaGUgUlRQIG1vbml0b3IgYWxzbyBleHBv c2VzIHJlYWwgdGltZSBBcHBsaWNhdGlvbiBRb1MvUW9FIG1ldHJpYyBpbmZvcm1hdGlvbiBpbiB0 aGUgYXBwcm9wcmlhdGUgcmVwb3J0IGJsb2NrIGZvcm1hdCAoZS5nLixSVENQIFhSIG9yIG90aGUg bm9uLVJUUCBtZWFucykgdG8gdGhlIG1hbmFnZW1lbnQgc3lzdGVtLiBTdWNoIGluZm9ybWF0aW9u IGNhbiBiZSBmb3JtdWxhdGVkIGFzIGRpZmZlcmVudCBtZXRyaWMgdHlwZXMsIGUuZy4sYXBwbGlj YXRpb24gbGV2ZWwgbWV0cmljLCB0cmFuc3BvcnQgbGV2ZWwgbWV0cmljLCBlbmQgc3lzdGVtIG1l dHJpYywgaW50ZXJ2YWwgbWV0cmljLCBjdW11bGF0aXZlIG1ldHJpYywgc2FtcGxlZCBtZXRyaWMs IGRpcmVjdCBtZXRyaWMsIGNvbXBvc2VkIG1ldHJpYyxldGMuIEJvdGggdGhlIFJUQ1Agb3IgUlRD UCBYUiBjYW4gYmUgZXh0ZW5kZWQgdG8gY29udmV5IHRoZXNlIG1ldHJpY3MuIFRoZSBkZXRhaWxz IG9uIHRyYW5zcG9ydCBwcm90b2NvbHMgZm9yIHRoZXNlIG1ldHJpYyBhcmUgZGVzY3JpYmVkIGlu IFNlY3Rpb24gMy4yLiBSVFAgbWF5IGJlIHVzZWQgdG8gbXVsdGljYXN0IGdyb3VwcywgYm90aCBB bnkgU291cmNlIE11bHRpY2FzdCAoQVNNKSBhbmQgU291cmNlIFNwZWNpZmljIE11bHRpY2FzdCAo U1NNKS4gVGhlc2UgZ3JvdXBzIGNhbiBiZSBtb25pdG9yZWQgdXNpbmcgUlRDUC4gSW4gdGhlIEFT TSBjYXNlLCB0aGUgbW9uaXRvciBpcyBhIG1lbWJlciBvZiB0aGUgbXVsdGljYXN0IGdyb3VwIGFu ZCBsaXN0ZW5zIHRvIFJUQ1AgWFIgcmVwb3J0cyBmcm9tIGFsbCBtZW1iZXJzIG9mIHRoZSBBU00N CiBncm91cC4gSW4gdGhlIFNTTSBjYXNlLCB0aGVyZSBpcyBhIHVuaWNhc3QgZmVlZGJhY2sgdGFy Z2V0IHRoYXQgcmVjZWl2ZXMgUlRDUCBmZWVkYmFjayBmcm9tIHJlY2VpdmVycyBhbmQgZGlzdHJp YnV0ZXMgaXQgdG8gb3RoZXIgbWVtYmVycyBvZiB0aGUgU1NNIGdyb3VwIChzZWUgZmlndXJlIDEg b2YgUkZDNTc2MCkuIFRoZSBtb25pdG9yIHdpbGwgbmVlZCB0byBiZSBjby1sb2NhdGVkIHdpdGgg dGhlIGZlZWRiYWNrIHRhcmdldCB0byByZWNlaXZlIGFsbCBmZWVkYmFjayBmcm9tIHRoZSByZWNl aXZlcnMgKHRoaXMgbWF5IGFsc28gYmUgYW4gaW50ZXJtZWRpYXRlIHN5c3RlbSkuIEluIGJvdGgg QVNNIGFuZCBTU00gc2NlbmFyaW9zLCByZWNlaXZlcnMgY2FuIHNlbmQgUlRDUCBYUiByZXBvcnRz IHRvIGVuaGFuY2UgdGhlIHJlY2VwdGlvbiBxdWFsaXR5IHJlcG9ydGluZy4gIiA+IEluIHRoZSBk ZWZpbml0aW9uIG9mIENvbXBvc2VkIG1ldHJpY3MsIHRoZSBzZW50ZW5jZSAiQW4gZXhhbXBsZSBp cyBhIA0KPiBtZXRyaWMgY2FsY3VsYXRlZCBiYXNlZCBvbiBkZXJpdmVkIG1ldHJpY3MgdGhhdCBo YXZlIGJlZW4gbWVhc3VyZWQuIiANCj4gbWFrZXMgbGl0dGxlIHNlbnNlLiBbUWluXSBUaGUgZGVy aXZlZCBtZXRyaWNzIGluIHRoZSBzZW50ZW5jZSBzaG91bGQgYmVlbiBjb3JyZWN0ZWQgYXMgImRp cmVjdCBtZXRyaWMiLiA+RGlkIHlvdSBtZWFuIHNvbWV0aGluZyBsaWtlICJBbiBleGFtcGxlIGlz IGEgbWV0cmljIA0KPiBkZXJpdmVkIGJ5IGFsZ29yaXRobWljYWxseSBjb21iaW5pbmcgbWVhc3Vy ZWQgbWV0cmljcy4iPyBbUWluXTpJIGFncmVlIHdpdGggeW91ciBzdWdnZXN0ZWQgdGV4dCBhbmQg bGlrZSB0byBhZG9wdCB5b3VyIHN1Z2dlc3Rpb24uID4gVGhlIGRlZmluaXRpb25zIG9mIEludGVy dmFsLCBDdW11bGF0aXZlLCBhbmQgU2FtcGxlZCBtZXRyaWNzIGFyZSBub3QgY2xlYXIuIFtRaW5d OiBJIGFncmVlIHRoZSBkZWZpbml0aW9uIGZvciB0aGVzZSB0aHJlZSBtZXRyaWNzIG5lZWQgdG8g YmUgbW9yZSBjbGVhZXIsIEkgcHJvcG9zZXMgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2VzOiBO RVcgVGV4dDogIiBJbnRlcnZhbCBtZXRyaWNzIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVk IHZhbHVlcyBhcmUgbWVhc3VyZWQgaW4gdGhlIG1vc3QgcmVjZW50IG1lYXN1cmVtZW50IGludGVy dmFsIGR1cmF0aW9uIGJldHdlZW4gc3VjY2Vzc2l2ZSBtZXRyaWNzIHJlcG9ydHMuIFN1Y2ggbWVh c3VyZW1lbnQgaW50ZXJ2YWwgaXMgZXF1YWwgdG8gb25lIFJUQ1AgcmVwb3J0IGludGVydmFsIChS RkMzNTUwLFNlY3Rpb24gNi4yKS4gQ3VtdWxhdGl2ZSBtZXRyaWNzIE1ldHJpY3Mgb2Ygd2hpY2gg dGhlIHJlcG9ydGVkIHZhbHVlcyBhcHBseSB0byB0aGUgYWNjdW11bGF0aW9uIHBlcmlvZCBjaGFy YWN0ZXJpc3RpYyBvZiBjdW11bGF0aXZlIG1lYXN1cmVtZW50cy4gVGhlIHJlcG9ydGVkIHZhbHVl cyBhcmUgbWVhc3VyZWQgZHVyaW5nIHRoZSBhY2N1bXVsYXRpb24gcGVyaW9kLiBUaGUgYWNjdW11 bGF0aW9uIHBlcmlvZCBzcGFucyBvdmVyIG1vcmUgdGhhbiBvbmUgUlRDUCByZXBvcnQgaW50ZXJ2 YWxzLiBTYW1wbGVkIG1ldHJpY3MgTWV0cmljcyBvZiB3aGljaCB0aGUgcmVwb3J0ZWQgdmFsdWVz IG9ubHkgYXBwbHkgdG8gdGhlIHZhbHVlIG9mIGEgY29udGludW91c2x5IG1lYXN1cmVkIG9yDQog Y2FsY3VsYXRlZCBtZXRyaWMgdGhhdCBoYXMgYmVlbiBzYW1wbGVkIGF0IGFueSBnaXZlbiBpbnN0 YW5jZSBvZiB0aGUgUlRDUCByZXBvcnQgaW50ZXJ2YWwuIE9uZSBleGFtcGxlIG9mIHN1Y2ggbWV0 cmljIGlzIHRoZSBpbnRlci1hcnJpdmFsIGppdHRlciBkZXNjcmliZWQgaW4gdGhlIHNlY3Rpb24g Ni40LjEgb2YgUkZDMzU1MC4gIiA+IElmIHRoZSBkaXNjdXNzaW9uIGF0IHRoZSBlbmQgb2Ygc2Vj dGlvbiAzLjEgaXMga2VwdCwgdGhlIHJlZmVyZW5jZSB0byANCj4gUkZDNTc2MCBzaG91bGQgYmUg YSByZWFsIHJlZmVyZW5jZSwgYW5kIFJGQzU3NjAgc2hvdWxkIGFwcGVhciBpbiB0aGUgDQo+IHJl ZmVyZW5jZSBzZWN0aW9uLiBbUWluXTogT2theS4gPiBUaGUgcG9pbnQgb2Ygc2VjdGlvbiAzLjIg aXMgbm90IG9idmlvdXMuIEhvdyBkb2VzIGl0IGNvbnRyaWJ1dGUgdG8gdGhlIA0KPiBkZXNjcmlw dGlvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlLiBJdCBtaXhlcyB0YWxraW5nIGFib3V0IHdoYXQgcmVw b3J0IA0KPiBibG9ja3MgYXJlIHdpdGggb2NjYXNpb25hbGx5IG5lZWRpbmcgdG8gc2VuZCB0aGVt IG1vcmUgZnJlcXVlbnRseS4gVGhvc2UgDQo+IHBvaW50cyBjb3VsZCBiZSBtYWRlIHNlcGFyYXRl bHkgYW5kIG1vcmUgc2ltcGx5LiBbUWluXTogT2theS4gSSBsaWtlIHRvIGluY29ycG9yYXRlIHRo ZSBrZXkgcG9pbnRzIGluIHRoZSBzZWN0aW9uIDMuMiBpbnRvIHNlY3Rpb24gMy4xID4gU2VjdGlv biAzLjMgaXMgbm90IGNsZWFyIC0gaXQgc3RhcnRzIG9mZiBzYXlpbmcgdGhhdCB0aGUgbG9jYXRp b24gb2YgdGhlIA0KPiBzZW5kZXIgYW5kIHJlY2VpdmVyIG1heSBjaGFuZ2Ugd2hhdCBtZXRyaWNz IGFyZSBtZWFuaW5nZnVsLiBJdCdzIG5vdCANCj4gY2xlYXIgd2hhdCB5b3UgbWVhbiBieSBsb2Nh dGlvbi4gWW91IGNlcnRhaW5seSBkb24ndCBtZWFuIGdlb3NwYXRpYWwgDQo+IGNvb3JkaW5hdGVz LiBEbyB5b3UgbWVhbiBhbnl0aGluZyBvdGhlciB0aGFuIHdoZXRoZXIgdGhlIGVsZW1lbnQgaXMg DQo+IHRydXN0ZWQgb3IgdW50cnVzdGVkIGJ5IHRoZSBvcGVyYXRpb25zIG5ldHdvcms/IElmIHNv LCBzYXkgdGhhdC4gVGhlIA0KPiByZXN0IG9mIHRoZSBwYXJhZ3JhcGggb25seSBzcGVha3MgdG8g d2hhdCBlbGVtZW50IGNvbGxlY3RzIHRoZSBtZXRyaWNzLiBbUWluXSBTZWN0aW9uIDMuMyBpcyBv bmx5IHVzZWQgdG8gZGVzY3JpYmUgd2hlcmUgb3IgZnJvbSB3aGljaCBSVFAgZW50aXR5IHRvIGdh dGhlciB0aGUgbWV0cmljcyAoaS5lLiwgbWVhc3VyZW1lbnQgcG9pbnQpIGluIHRoZSBwaHlzaWNh bCBuZXR3b3JrIGFuZCBpcyBub3QgZm9jdXMgb2YgdGhpcyBkb2N1bWVudC4gU2Vjb25kbHksIEkg dGhpbmsgdGhlIGRlZmluaXRpb24gb2YgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcyBoYXMgYWxy ZWFkeSBjbGFyaWZpZWQgdGhhdCBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGlzIG5vcm1hbGx5 IGdhdGhlcmVkIGZyb20gdXNlciBlbmRwb2ludC4gPiBJdCdzIG5vdCBjbGVhciB0aGF0IHRoZSBz ZXQgb2YgbWVhbmluZ2Z1bCBtZXRyaWNzIGlzIGNoYW5nZWQgYXQgYWxsIC0gDQo+IGp1c3Qgd2hl cmUgeW91IGNvbGxlY3QgdGhlbS4gSWYgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MgZG9l cyBpbiANCj4gZmFjdCBjaGFuZ2UsIHRoZXJlIG5lZWRzIHRvIGJlIGFkZGl0aW9uYWwgZGlzY3Vz c2lvbiBoZXJlLiBbUWluXTogVGhlIG1ldHJpY3MgYWN0dWFsbHkgZG9lc24ndCBjaGFuZ2UuU2lu Y2UgdGhlIGRlZmluaXRpb24gb2YgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcyBIYXZlIGFscmVh ZHkgY29udmV5ZWQgdGhlIG1lYW5pbmcgb2Ygd2hhdCBzZWN0aW9uIDMuMyB3YW50cyB0byBkZXNj cmliZSwgSSBwcm9wb3NlIHRvIHJlbW92ZSB0aGlzIHNlY3Rpb24uID4gU2VjdGlvbiA0J3MgZmly c3QgcGFyYWdyYXBoOiBJcyAicHJvYmFibHkiIHRoZSBiZXN0IHRoZSB3b3JraW5nIGdyb3VwIA0K PiBjYW4gc2F5PyBbUWluXTpObywgd2lsbCByZW1vdmUgdGhpcyB3b3JkLiA+IFRoZSBsYXN0IHR3 byBzZW50ZW5jZXMgb2YgdGhlIHNlY29uZCBidWxsZXQgaW4gc2VjdGlvbiA0IGRvIG5vdCBwYXJz ZS4gDQo+IFBsZWFzZSBzaW1wbGlmeSB0aGVtLiBbUWluXTogT2theSwgaG93IGFib3V0IGNoYW5n ZSB0aGVtIGFzIGZvbGxvd3M6IE5FVyBUZXh0OiAiIFdpdGggdGhlc2UgbWluaW1hbCBudW1iZXIg b2YgUlRDUCBzdGF0aXN0aWNzIHBhcmFtZXRlcnMgbWFwcGVkIHRvIG5vbi1SVENQIG1lYXN1cmVt ZW50cywgaXQgaXMgaGFyZCB0byBwcm92aWRlIGFjY3VyYXRlIG1lYXN1cmVzIG9mIHJlYWwgdGlt ZSBhcHBsaWNhdGlvbiBxdWFsaXR5LGNvbmR1Y3QgZGV0YWlsZWQgZGF0YSBhbmFseXNpcyBhbmQg Y3JlYXRlcyBhbGVydHMgdGltbHkgdG8gdGhlIHVzZXJzLiBUaGVyZWZvcmUgY29ycmVsYXRpb24g YmV0d2VlbiBSVENQIFhSIGFuZCBub24tUlRQIGRhdGEgc2hvdWxkIGJlIHByb3ZpZGVkLiAiID4g VGhlIGZpcnN0IGZ1bGwgc2VudGVuY2Ugb2YgdGhlIHRoaXJkIGJ1bGxldCBpbiBzZWN0aW9uIDQg ZG9lcyBub3QgbWFrZSANCj4gc2Vuc2UuIFRoZSB3aG9sZSBidWxsZXQgY291bGQgYmUgY2xhcmlm aWVkLiBbUWluXTogQWdyZWUgYW5kIHdpbGwgcmVtb3ZlIHRoZSBmaXJzdCBzZW50ZW5jZS4gPiBU aGUgZm91cnRoIGJ1bGxldCBpbiBzZWN0aW9uIDQgYW5kIHNlY3Rpb24gNS41IHNob3VsZCBjYWxs IG91dCB0aGF0IA0KPiBSRkMzNjExIGFscmVhZHkgc2V0IEJsb2NrIFR5cGUgMjU1IGFzaWRlIGZv ciBmdXR1cmUgZXh0ZW5zaW9ucywgDQo+IGFudGljaXBhdGluZyB0aGUgcG90ZW50aWFsIG5lZWQg dG8gZXh0ZW5kIHRoZSBibG9jayB0eXBlIHNwYWNlLiBbUWluXTogT2theSwgSG93IGFib3V0IHJl dmlzaW5nIHRoZSBzZWN0aW9uIDQsYnVsbGV0IDQgYXMgZm9sbG93czogIiBDb25zdW1wdGlvbiBv ZiBYUiBibG9jayBjb2RlIHBvaW50cy4gVGhlIFJUQ1AgWFIgYmxvY2sgbmFtZXNwYWNlIGlzIGxp bWl0ZWQgYnkgdGhlIDgtYml0IGJsb2NrIHR5cGUgZmllbGQgaW4gdGhlIFJUQ1AgWFIgaGVhZGVy LiBTcGFjZSBleGhhdXN0aW9uIG1heSBiZSBhIGNvbmNlcm4gaW4gdGhlIGZ1dHVyZS4gQW50aWNp cGF0aW5nIHRoZSBwb3RlbnRpYWwgbmVlZCB0byBleHRlbmQgdGhlIGJsb2NrIHR5cGUgc3BhY2Us IGl0IGlzIG5vdGVkIGluIFtSRkMzNjExXSB0aGF0IEJsb2NrIFR5cGUgMjU1IGlzIHJlc2VydmVk IGZvciBmdXR1cmUgZXh0ZW5zaW9ucywgIiA+IEluIHNlY3Rpb24gNSwgY29uc2lkZXIgbmFtaW5n IHRoZSBzdWJzZWN0aW9ucyB3aXRoIHRoZSBhY3R1YWwgZ3VpZGVsaW5lIA0KPiBpbnN0ZWFkIG9m IHRoZSBwcm9ibGVtIHRoZSBndWlkZWxpbmUgaXMgdHJ5aW5nIHRvIGFkZHJlc3MuDQo+IDUuMS4g TWV0cmljIGJsb2NrcyBzaG91bGQgY29udGFpbiBhIHNpbmdsZSBtZXRyaWMgW1Fpbl06IEkgc3Vn Z2VzdCB0byBjaGFuZ2UgaXQgYXMgIkNvbnRhaW4gdGhlIHNpbmdsZSBtZXRyaWNzIGluIHRoZSBt ZXRyaWMgYmxvY2siID4gNS4yLiBJbmNsdWRlIHRoZSBwYXlsb2FkIHR5cGUgYW5kIGZvcm1hdCBw YXJhbWV0ZXJzIGluIHRoZSBtZXRyaWMgYmxvY2sgW1Fpbl06IE9rYXkuID4gNS4zLiBVc2UgUlRD UCBTREVTIHRvIGNvcnJlbGF0ZSBYUiByZXBvcnRzIHdpdGggbm9uLVJUUCBkYXRhIFtRaW5dOiBP a2F5LiA+IDUuNC4gRG9uJ3QgcmVwZWF0IG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIGFjcm9zcyBt ZXRyaWMgYmxvY2tzDQo+IA0KW1Fpbl06IEl0IGlzIG5vdCBwb3NzaWJsZSBjb21wbGV0ZWx5IHRv IGF2b2lkIG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIHJlcGVhdGl0aW9uLiBlLmcuLCBmb3IgcGFj a2V0IGxvc3Mgcm9idXN0bmVzcyBpZiB0aGUgcmVwb3J0IGJsb2NrcyBmb3IgdGhlIHNhbWUgaW50 ZXJ2YWwgc3BhbiBvdmVyIG1vcmUgdGhhbiBvbmUgUlRDUCBwYWNrZXQgdGhlbiBlYWNoIG11c3Qg aGF2ZSB0aGUgc2FtZSBtZWFzdXJlbWVudCBpZGVudGl0eSBpbmZvcm1hdGlvbiBTbyBJIHN1Z2dl c3QgdG8gY2hhbmdlIGl0IGFzOiAicmVkdWNlIG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIGFjcm9z cyBtZXRyaWMgYmxvY2tzIiA+IFRoaXMgcG9pbnRzIG91dCBhIHN0cnVjdHVyYWwgcHJvYmxlbSB3 aXRoIHRoZSBzZWN0aW9uLiBXaHkgaXMgNS41IGhlcmU/IA0KPiBJdCdzIG5vdCBhIGd1aWRlbGlu ZS4gW1Fpbl06IEFncmVlIGFuZCBhbHNvIGFzIGRpc2N1c3NlZCxTcGFjZSBleGhhdXN0aW9uIGlz IG5vdCBiaWcgaXNzdWUuIEhvdyBhYm91dCByZW1vdmUgdGhpcyBzZWN0aW9uPyA+ICgqKSBBbmQg aXQgcmFpc2VzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUgZG9jdW1lbnQgaXMgdHJ5aW5nIHRv IA0KPiBhY2hpZXZlIHdpdGggc2VjdGlvbiA1LjQuIFRoYXQgc2VjdGlvbiBjbGFpbXMgdGhlIGRv Y3VtZW50IGlzIHByb3Bvc2luZyANCj4gYSBuZXcgWFIgYmxvY2sgdHlwZSB0byBoZWxwIGF2b2lk IGR1cGxpY2F0aW9uLCBidXQgaXQgZG9lc24ndCBhY3R1YWxseSANCj4gZGVmaW5lIHRoZSBuZXcg YmxvY2sgdHlwZS4gSXMgdGhlIGd1aWRlbGluZSBzYXlpbmcgc2ltcGx5IGRvbid0IHJlcGVhdCAN Cj4gbWVhc3VyZW1lbnRzIG9yIGl0cyB0aGUgZ3VpZGVsaW5lIHNheWluZyAidXNlIHRoaXMgbmV3 IFhSIGJsb2NrIHR5cGUgd2UgDQo+IGhhdmVuJ3QgZGVmaW5lZCB5ZXQiPyBbUWluXTogSnVzdCB0 byBjbGFyaWZ5LCB3ZSBoYXZlIGFscmVhZHkgZGVmaW5lZCBvbmUgbmV3IFhSIEJsb2NrIHR5cGUg dG8gaGVscCBhdm9pZCBvciByZWR1Y2UgZHVwbGljYXRpb24uIEl0IGlzIG1lYXN1cmVtZW50IGlu Zm9ybWF0aW9uIGJsb2NrLiBUaGUgcmVsZXZhbnQgZHJhZnQgaXMgYXZhaWxhYmxlIGF0OiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLWlk ZW50aXR5LTA2ID5UaGUgc2VjdGlvbiBuZWVkcyBtb3JlIGNsYXJpdHkuIElmIGl0IHJlYWxseSBp cyANCj4gdHJ5aW5nIHRvIGRlZmluZSBhIG5ldyB0eXBlLCB0aGVyZSdzIG1vcmUgd29yayB0byBi ZSBkb25lLiBbUWluXTogSW4gb3JkZXIgdG8gYXZvaWQgc3VjaCBjb25mdXNpb24sIEkgcHJvcG9z ZWQgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIHNlY3Rpb24gNS40OiBPTEQgVGV4 dDogIiBUaGlzIG1lbW8gcHJvcG9zZXMgdG8gZGVmaW5lIGEgbmV3IFhSIEJsb2NrIHRoYXQgd2ls bCBiZSB1c2VkIHRvIGNvbnZleSB0aGUgY29tbW9uIHRpbWUgcGVyaW9kIGFuZCB0aGUgbnVtYmVy IG9mIHBhY2tldHMgc2VudCBkdXJpbmcgdGhpcyBwZXJpb2QuICIgTmV3IHRleHQ6ICIgVGhpcyBt ZW1vIHByb3Bvc2VzIHRvIGRlZmluZSBhIG5ldyBYUiBCbG9jayAoaS5lLiwgdGhlIE1lYXN1cmVt ZW50IGluZm9ybWF0aW9uIGJsb2NrW0kuRC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLWlkZW50 aXR5XSkgdGhhdCB3aWxsIGJlIHVzZWQgdG8gY29udmV5IHRoZSBjb21tb24gdGltZSBwZXJpb2Qg YW5kIHRoZSBudW1iZXIgb2YgcGFja2V0cyBzZW50IGR1cmluZyB0aGlzIHBlcmlvZC4gIiA+IFRo ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBwYXJ0aWN1bGFybHkgdGhlIHRoaXJk IHBhcmFncmFwaCwgDQo+IG5lZWRzIHRvIGJlIGNsZWFyZXIuIFdoYXQgZXhhY3RseSBkbyB5b3Ug bWVhbiBieSAibW9uaXRvcmluZyBzaG91bGQgYmUgDQo+IHByb2hpYml0ZWQiLCBhbmQgaG93IGlz IHRoZSBmYWN0IHRoYXQgdGhpcmQgcGFydHkgbW9uaXRvcnMgZG9uJ3Qgc2VuZCANCj4gUlRDUCBy ZWxldmFudD8gRGlkIHlvdSBpbnRlbmQgdGhvc2UgdG8gYmUgc2VwYXJhdGUgcG9pbnRzPyBbUWlu XTogWWVzLCB0aGV5IGFyZSBvbiB0aGUgZGlmZmVyZW50IHBvcnQuIFN1Y2ggbW9uaXRvciBtYXkg cmVjZWl2ZSBSVFAgcGFja2V0IGJ1dCBkb2VzIG5vdCBzZW5kIFJUQ1AgcGFja2V0LiA+IEVkaXRv cmlhbCBOaXRzIGFuZCBTdWdnZXN0aW9uczoNCj4gDQo+IFRoZSBmaXJzdCBwYXJhZ3JhcGggb2Yg dGhlIGludHJvZHVjdGlvbiBpcyBvdmVybHkgY29tcGxleCwgYW5kIHdvbid0IGFnZSANCj4gd2Vs bC4gSSBzdWdnZXN0IHJlcGxhY2luZyBpdCB3aXRoOiAiTXVsdGltZWRpYSBzZXJ2aWNlcyB1c2lu ZyB0aGUgDQo+IFJlYWwtVGltZSBQcm90b2NvbCAoUlRQKSBhcmUgc2VlaW5nIGluY3JlYXNlZCB1 c2UuIFN0YW5kYXJkIG1ldGhvZHMgZm9yIA0KPiBnYXRoZXJpbmcgUlRQIHBlcmZvcm1hbmNlIG1l dHJpY3MgZnJvbSB0aGVzZSBhcHBsaWNhdGlvbnMgYXJlIG5lZWRlZCB0byANCj4gbWFuYWdlIHVu Y2VydGFpbnRpZXMgaW4gdGhlIGJlaGF2aW9yIGFuZCBhdmFpbGFiaWxpdHkgb2YgdGhlaXIgDQo+ IHNlcnZpY2VzLiIgVGhlbiByZXBsYWNlICJUaGVzZSByYXBpZGx5IGVtZXJnaW5nIHN0YW5kYXJk cywiIHdpdGggDQo+ICJTdGFuZGFyZHMiLiBbUWluXTogT2theS4gPiBJbnRyb2R1Y3Rpb24gcGFy YWdyYXBoIDMgc2VudGVuY2UgMiBzaG91bGQgc3RhcnQgIlRoZSBSVENQIEd1aWRlbGluZXMgDQo+ IFtSRkM1OTY4XSIuIEl0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyIHRvIHVzZSB0aGUgZnVsbCB0aXRs ZSBmcm9tIDU5Njg6IA0KPiAnVGhlICJHdWlkZWxpbmVzIGZvciBFeHRlbmRpbmcgdGhlIFJUUCBD b250cm9sIFByb3RvY29sIChSVENQKSIgW1JGQzU5NjhdJyBbUWluXTogT2theS4gPiBUaGlzIG1h eSBiZWNvbWUgbW9vdCBhcyBzZWN0aW9uIDMgaXMgbW9kaWZpZWQgdG8gbWFrZSBpdHMgbWFpbiBw b2ludCANCj4gbW9yZSBvYnZpb3VzLCBidXQgUkZDMzU1MCBkb2VzIG5vdCBjaGFyYWN0ZXJpemUg TW9uaXRvcnMgYXMgImEgc291cmNlIG9mIA0KPiBpbmZvcm1hdGlvbiIuIFRoYXQgY291bGQgYmUg bWlzdW5kZXJzdG9vZC4gUGxlYXNlIGNob29zZSBhbm90aGVyIHdvcmQuIA0KPiBQZXJoYXBzICJy ZXBvc2l0b3J5Ij8gW1Fpbl06IE9rYXksIHJlcG9zaXRvcnkgbG9va3MgZ29vZCB0byBtZS4gPiBJ biBidWxsZXQgbGlzdHMsIHN0YXJ0aW5nIGFuIGVudHJ5IHdpdGggIm9yIiBvciAiYW5kIiBpcyB1 bm5lY2Vzc2FyeS4gSXQgDQo+IHNob3VsZCBiZSBjbGVhciBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24g dG8gdGhlIGxpc3Qgd2hldGhlciB0aGUgaW5kaXZpZHVhbCANCj4gZW50cmllcyBzaG91bGQgYmUg Y29tYmluZWQgb3Igc2VsZWN0ZWQgZnJvbS4gW1Fpbl06IE9rYXkuID4gSW4gc2VjdGlvbiAzLjEg d2hlcmUgeW91IHNheSAiUlRQIG1heSBiZSB1c2VkIHRvIG11bHRpY2FzdCBncm91cHMiIGRpZCAN Cj4geW91IG1lYW4gIlJUUCBtYXkgYmUgc2VudCB0byBtdWx0aWNhc3QgZ3JvdXBzIiBvciAiUlRQ IG1heSBiZSB1c2VkIHdpdGggDQo+IG11bHRpY2FzdCBncm91cHMiPyBbUWluXTogSSB0aGluayBp dCBzaG91bGQgYmUgdGhlIGxhdHRlciBjYXNlLGkuZS4sIiBSVFAgbWF5IGJlIHVzZWQgd2l0aCAN Cm11bHRpY2FzdCBncm91cHMiLiA+IA0KPiBJbiBzZWN0aW9uIDMuMiAiVGhlIGZvbGxvd2luZyBh cmUgZm91ciB1c2UgY2FzZXMgYnV0IGFyZSBub3QgbGltaXRlZCANCj4gdG86IiBkb2VzIG5vdCBw YXJzZS4gVGhlIGJ1bGxldHMgYXJlbid0IHJlYWxseSB1c2UgY2FzZXMgYXMgbXVjaCBhcyB0aGV5 IA0KPiBhcmUgbWVjaGFuaXNtcy4gV291bGQgaXQgbWFrZSBtb3JlIHNlbnNlIHRvIHNheSAiSGVy ZSBhcmUgZm91ciANCj4gbWVjaGFuaXNtcyB0aGF0IGhhdmUgYmVlbiBjcmVhdGVkIHRvIGFkZHJl c3MgdGhlIG5lZWQgZm9yIG1vcmUgZnJlcXVlbnQgDQo+IHJlcG9ydGluZy4gVGhpcyBsaXN0IGlz IG5vdCBpbnRlbmRlZCB0byBiZSBleGhhdXN0aXZlLiIgVGhlIHRoaXJkIGJ1bGxldCANCj4gaW4g dGhhdCBsaXN0IHNob3VsZCBzYXkgIlJUQ1AgYW5kIFJUQ1AgWFIgYXJlIiBpbnN0ZWFkIG9mICJS VENQIG9yIFJUQ1AgDQo+IFhSIGlzIi4gW1Fpbl06IE9rYXksIGJ1dCBJIGhhdmUgaW5jb3Jwb3Jh dGVkIHRoZSBrZXlwb2ludHMgb2Ygc2VjdGlvbiAzLjIgaW50byBzZWN0aW9uIDMuMS4gPiBUaGUg YnVsbGV0cyBpbiBzZWN0aW9uIDQgd291bGQgYmUgYmV0dGVyIGFzIHN1YnNlY3Rpb25zIHdpdGgg dGl0bGVzIA0KPiAodGFrZW4gZnJvbSB0aGUgZmlyc3QgcGhyYXNlIG9mIHRoZSBidWxsZXQpLiBb UWluXTogT2theS4gPiBJIHN1Z2dlc3QgdGhpcyBhbHRlcm5hdGl2ZSBmb3IgdGhlIGZpcnN0IGZ1 bGwgc2VudGVuY2UgaW4gdGhlIGZpcnN0IA0KPiBidWxsZXQgb2Ygc2VjdGlvbiA0IDogIkEgY29t cG91bmQgbWV0cmljcyBibG9jayBpcyBkZXNpZ25lZCB0byBjb250YWluIGEgDQo+IGxhcmdlIG51 bWJlciBvZiBwYXJhbWV0ZXJzIGZyb20gZGlmZmVyZW50IGNsYXNzZXMgZm9yIGEgc3BlY2lmaWMg DQo+IGFwcGxpY2F0aW9uIGluIGEgc2luZ2xlIGJsb2NrLiIgW1Fpbl06IE9rYXkuID4gU2VjdGlv biA1J3MgdGl0bGUgc2hvdWxkIGJlICJHdWlkZWxpbmVzIGZvciByZXBvcnRpbmciIGluc3RlYWQg b2YgDQo+ICJHdWlkZWxpbmUgZm9yIHJlcG9ydGluZyIgW1Fpbl06IE9rYXkuID4gSW4gc2VjdGlv biA1LjEgSSBzdWdnZXN0ICJqdXN0aWZ5IHRoZSBvdmVyaGVhZCwiIGluc3RlYWQgb2YgImp1c3Rp ZnkgdGhlIA0KPiBvdmVyaGVhZHMsIiBbUWluXTogT2theS4gPiBTZWN0aW9uIDcgLSB0aGUgbGFz dCBzZW50ZW5jZSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIGRvZXMgbm90IHBhcnNlLiBUaGUgDQo+ IHNlY29uZCBwYXJhZ3JhcGggKHdoaWNoIGlzIGEgc2luZ2xlIHNlbnRlbmNlKSBzaG91bGQgYmUg Y2xhcmlmaWVkIC0gYW4gDQo+IE1DVSBpcyBub3QgYSB0b3BvbG9neS4gW1Fpbl06IE9rYXkuIEhv dyBhYm91dCByZXZpc2luZyB0aGVtIGFzIGZvbGxvd3M6IE9MRCBUZXh0OiAiIFRoZSB0b3BvbG9n aWVzIGluIHRoaXMgY2F0ZWdvcnkgYXJlIFRvcG8tVmlkZW8tU3dpdGNoLU1DVSBhbmQgVG9wby1S VENQLXRlcm1pbmF0aW5nLU1DVS4gU3VjaCB0b3BvbG9naWVzIGJhc2VkIG9uIHN5c3RlbXMgZG8g bm90IGJlaGF2ZSBhY2NvcmRpbmcgdG8gdGhlIFJUUCBwcm90b2NvbCBbUkZDMzU1MF0uIENvbnNp ZGVyaW5nIHRoZSBNQ1UgYW5kIHRyYW5zbGF0b3IgYXJlIHR3byB0eXBpY2FsIHRvcG9sb2dpZXMg aW4gdGhlIHR3byBjYXRlZ29yaWVzIG1lbnRpb25lZCBhYm92ZSwgdGhpcyBkb2N1bWVudCB3aWxs IHRha2UgdGhlbSBhcyB0d28gdHlwaWNhbCBleGFtcGxlcyB0byBleHBsYWluIGhvdyBSVENQIFhS IHJlcG9ydCB3b3JrcyBpbiBkaWZmZXJlbnQgUkZDNTExNyB0b3BvbG9naWVzLiAiIE5FVyBUZXh0 OiAiIFRoZSB0b3BvbG9naWVzIGluIHRoaXMgY2F0ZWdvcnkgYXJlIFRvcG8tVmlkZW8tU3dpdGNo LU1DVSBhbmQgVG9wby1SVENQLXRlcm1pbmF0aW5nLU1DVS4gU3VjaCB0b3BvbG9naWVzIGJhc2Vk IG9uIHN5c3RlbXMgKGUuZy4sTUNVKSBkbyBub3QgYmVoYXZlIGFjY29yZGluZyB0byB0aGUgUlRQ IHByb3RvY29sIFtSRkMzNTUwXS4gQ29uc2lkZXJpbmcgdGhlIE1DVSBhbmQgdHJhbnNsYXRvciBh cmUgdHdvIHR5cGljYWwgaW50ZXJtZWRpYXJ5IHN5c3RlbXMgaW4gdGhlIHR3byBjYXRlZ29yaWVz IG1lbnRpb25lZCBhYm92ZSwgdGhpcyBkb2N1bWVudCB3aWxsIHRha2UgdGhlbSBhcyB0d28gdHlw aWNhbCBleGFtcGxlcyB0byBleHBsYWluIGhvdyBSVENQIFhSIHJlcG9ydCB3b3JrcyBpbiBkaWZm ZXJlbnQgUkZDNTExNyB0b3BvbG9naWVzLiAiID4gVGhlIGxhc3QgdHdvIHNlbnRlbmNlcyBvZiB0 aGUgZmlyc3QNCiBwYXJhZ3JhcGggb2YgdGhlIHNlY3VyaXR5IA0KPiBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uIGFkZCBub3RoaW5nIHRvIHRoZSBkb2N1bWVudC4gSSBzdWdnZXN0IGRlbGV0aW5nIHRo ZW0uIFtRaW5dOiBPa2F5LiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+IGF2 dCBhdCBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2 dCA+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoqIFJlZmVyZW5jZXM6IA0K KiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25h cmNoLTEzIA0KKiBGcm9tOiBSb2JlcnQgU3BhcmtzDQoqIFByZXYgYnkgRGF0ZTogW0FWVENPUkVd IFByb3RvY29sIEFjdGlvbjogJ0V4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04p IGZvciBSVFAgb3ZlciANClVEUCcgdG8gUHJvcG9zZWQgU3RhbmRhcmQgKGRyYWZ0LWlldGYtYXZ0 Y29yZS1lY24tZm9yLXJ0cC0wOC50eHQpIA0KKiBQcmV2aW91cyBieSB0aHJlYWQ6IFtBVlRDT1JF XSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMgDQoq IE5leHQgYnkgdGhyZWFkOiBbQVZUQ09SRV0gUHJvdG9jb2wgQWN0aW9uOiAnRXhwbGljaXQgQ29u Z2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgZm9yIFJUUCBvdmVyIA0KVURQJyB0byBQcm9wb3Nl ZCBTdGFuZGFyZCAoZHJhZnQtaWV0Zi1hdnRjb3JlLWVjbi1mb3ItcnRwLTA4LnR4dCkgDQoqIElu ZGV4KGVzKTogDQoqIERhdGUNCiogVGhyZWFk From magnus.westerlund@ericsson.com Tue May 22 01:18:33 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9230C21F8564 for ; Tue, 22 May 2012 01:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.098 X-Spam-Level: X-Spam-Status: No, score=-106.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 9mDIwpmOnW7X for ; Tue, 22 May 2012 01:18:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2723B21F8552 for ; Tue, 22 May 2012 01:18:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-9b-4fbb4bd56ffd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.F7.11913.5DB4BBF4; Tue, 22 May 2012 10:18:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 22 May 2012 10:18:28 +0200 Message-ID: <4FBB4BD3.9000909@ericsson.com> Date: Tue, 22 May 2012 10:18:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3Vveq925/gwvTLCxe9qxkt1h7JNGB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyph1/ANzwYe8ionHrjM2ME4N6GLk5JAQMJF4 dPgUO4QtJnHh3nq2LkYuDiGBU4wSZ+auZARJCAksZ5T4ey8SxOYV0JZ49G42E4jNIqAqcWn2 UVYQm03AQuLmj0Y2EFtUIFjixZ4rrBD1ghInZz5hAbFFBIwkdp5/CRZnFlCSmLv0NXMXIweH sIC5xKuzfBA3SEoc/HeNHaJET2LK1RZGCFteonnrbGaIc7QlGpo6WCcwCsxCsmEWkpZZSFoW MDKvYhTOTczMSS831EstykwuLs7P0ytO3cQIDMeDW37r7mA8dU7kEKM0B4uSOO9mg13+QgLp iSWp2ampBalF8UWlOanFhxiZODilGhhLLVzOnhcO1vG5eGKK+qq3HN7cE9Nfzz2mllVR6hHN slCL4azwtsrSqRwxX3j/XDvx8vrcusqfabdMny45nWx4nvuHMGPENw7GrlOCdX88Nm9Pnrpm 5b1rz//HOttJ/OfzDjjAKnCg9KZNqtg1Hg5m1crco1IzhKb1p/Ozs+cxfepL4rBYsUWJpTgj 0VCLuag4EQCfEFC7FQIAAA== Cc: IETF AVTCore WG Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:18:33 -0000 Hi, I got a request to progress this document towards WG last call. So while we chairs are cleaning up some administrative stuff, like getting a milestone in place. I thought the authors should get something to do and thus reviewed the draft. 1) Section 1.1 "Crypto Context For the purposes of this document a crypto context is the outcome of any process which results in authentication of each participant in the SRTP session and possession by each partcipant of a shared secret master key and a shared master salt." What is the definition of participant here, SSRC, endpoint, user, or system? Please correct the "partcipant" spelling error also. 2) Section 1.1, crypto context: " Ciper Contest" I guess should be Crypto Context. 3) Section 1.1. is the text for crypto context really accurate as the document does define protection profiles for both DTLS-SRTP and Security description. 4) I am missing protection profiles for MIKEY. I think they should be defined as MIKEY is the third key-management protocol and are used in a lot of cases which neither DTLS-SRTP and Security Description are suitable for. 5) Section 1.1 Instantiation: "each participant in the SRTP/SRTCP session will need four instantiations of the AEAD algorithm; one for inbound SRTP traffic, one for outbound SRTP traffic source, one for inbound SRTCP traffic, and one for outbound SRTCP traffic source. " Is this really correct. This seems to be limiting the use of AEAD to point to point scenarios? The other crypto transforms for SRTP are capable of handling group scenarios. DTLS-SRTP with EKT for example would allow each end-point to distribute its own master key that it will use for the SSRCs it sends. There are also scenarios where one use a common master key for all participants. 6) Section 1.2: Associated Data This is data that is to be authenticated but not encrypted. In SRTP, the associated data consists of the entire RTP header, including the list of CSRC identifiers (if present) and the RTP header extension (if present), as shown in Figure 3. Shouldn't this point to and discuss the relation to draft-ietf-avtcore-srtp-encrypted-header-ext-01 7. Section 1.2: Associated Data This is data that is to be authenticated but not encrypted. In SRTP, the associated data consists of the entire RTP header, including the list of CSRC identifiers (if present) and the RTP header extension (if present), as shown in Figure 3. Plaintext Data that is to be both encrypted and authenticated. In SRTP this consists of the RTP payload, the RTP padding and the RTP pad count fields (if the latter two fields are present) as shown in Figure 3. The padding service provided by RTP is not needed by the AEAD encryption algorithm, so the RTP padding and RTP pad count fields SHOULD be omitted. Why are these paragraphs not discussing RTCP? 8. Section 1.2.1: (Note that this means that the cipher text will be longer than the plain text by precisely the length of the AEAD authentication tag.) This needs more extensive discussion as it needs to be taken into account in RTP/RTCP when determine packet sizes both for generating right sized RTP that don't violate MTU and that they are included in the RTCP avg_rtcp_size parameter part of the scheduling algorithm. 9. Section 1.2.2: For confirmation: Packet Counter Each AEAD instantiation MUST maintain a 6 octet zero-based packet counter which is incremented each time an SRTP packet is sent. As we shall see below, the packet counter is used to insure each SRTP packet gets a unique initialization vector. Can this use the "ROC" distribution mechanism (RFC4771) or what the key-management provide to correctly deduce the field, or will it have problems with late joiners in a group communication? 10. Section 1.2.2 Packet Counter: "zero-based packet counter" Does this mean that the 6 octet long field is initialized to 0 and thus violate the recommendation of RTP sequence number requirement of random start position. 11. Section 1.5: I don't like using the figure to indicate what is of different types. Two reasons. The first is that it doesn't explicitly enumerate protocol fields, instead 32-bytes octet with fields. Secondly because it make it hard for someone that can't see to correctly interpret this. Think if Sam Hartman would like to read this spec. You made it much more difficult for him. You had a description earlier that with a bit more precision would be correct, after having dealt with comment 6 and what needs to be included due to that. 12. Section 1.6. AEAD Processing of SRTCP Packets All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP packet encryption is optional. A sender can select which packets to encrypt, and indicates this choice with a 1-bit encryption flag (located in the leftmost bit of the 32-bit word that contains the SRTCP index) I think it is important to write "SRTCP packet" as SRTCP compount packet. As each individual RTCP packet can't be individually encrypted or not in the same compound packet. 13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here you may have to talk about octets as it is defined as the first of 32-bit words of the first RTCP packet part of the compound that are unencrypted. 14. Section 1.8. Prevention of IV Reuse For a given key it is critical that the IV not repeat. This reduces to the problem of insuring neither the Packet Counter nor the SRTCP index do not repeat before the AEAD instantiation is rekeyed. Processing MUST cease if either the 48-bit Packet Counter or the 31-bit SRTCP index cycles back to their initial value. Processing MUST NOT resume until a new SRTP/SRTCP session has been established using a new shared secret master key and shares master salt. Ideally, a rekey should be done well before either of these counters cycle. This section fails to discuss another issue where IV reuse could arise. Namely SSRC collision. If more than a single end-point uses the same SSRC there can be collision. This either put stringent requirements on how one key this crypto transform in different topologies or the usage of SSRC assignment rules. As the later is not really present it might be worth defining rules and be clear on the impact of an SSRC collision. 15. Section 2.1: C_MAX maximum ciphertext MUST be at most 2^16-40 octets length per invocation SHOULD be at least 2232 I think the lower bound reasonsing is flawed. First of all there is RTCP that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675) which support packet sizes of 2^32 bytes. I think the max should be set to what the upper limit where something breaks. Is 2^32 a working limit from crypto perspective, in that case I think you should use that. 16. Minimal value for C_MAX Similarly the lower bound on C_MAX is based on the maximum transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many RTP applications use very short payloads (for example, the G.729 codec used in VoIP can be as short as 20 octets), implementations that only support a maximum ciphertext length smaller than 2232 octets are permitted under this RFC. However, in the interest of maximizing interoperability between various AEAD implementations, the use of C_MAX values less than 2232 is discouraged. I actually think the minimum value should be that a C_MAX value of 2234 MUST be supported. My reasoning is that it must be 2 bytes larger to support full MTU RTCP. Then it really should be a MUST to ensure that one knows that a counter part can support that size of plaintext. I would like to point out that the current key-management systems aren't the greatest for negotiating a lot of sub-parameters. For example my understanding is that DTLS-SRTP only support negoptiating whole profiles, not sub-parameters at all. So if you are not specifying a hard limit what packet size a receiver must support how do you know that you can interoperate? At the same time I realize that this is not optimal for a very constrained device that sends encrypted real-time payloads of some type that are much smaller and actually don't have the buffering space for so large packets. Maybe the way forward is to separate the C_max value boundary and the minimal value supported for the defiended profiles and make it clear that the protection profiles defined in 2.2 and 2.3 actually requires a C_max that is 2234. 17. Section 2.1: For sake of clarity we specify two additional parameters: Authentication Tag Length MUST be either 8, 12, or 16 octets Maximum number of invocations MUST be at most 2^48 for SRTP for a given instantiation MUST be at most 2^31 for SRTCP As these parameters are for AEAD algorithms in general, how can you be certain that no one likes an authentication tag length longer than 16 bytes or for that matter one that is 14 bytes? I guess the maximum number of invocations also comes from an assumption around the IV construction. Which I am not certain holds as you clearly defined the IV specifically for the algorithms and other AEAD algorithms can make a different choice for IV including an explicit one, can't they? Thus does these max values really hold? 18. Section 2.2 In addition to the Packet Counter used in the formation of IVs, each instantiation of AES-GCM has a block counter which is incremented each time AES is called to produce a 16-octet output block. I would prefer that you where more explicit about the lenght of the block counters length, i.e ... AES-GCM has a block counter (32-bit) which ... This also applies to the corresponding text in 2.3. 19. Section 2.3: For AES-CCM in SRTP/SRTCP, the flag octet has the hex value 5A if an 8-octet authentication tag is used, 6A if a 12-octet authentication tag is used, and 7A if a 16-octet authentication tag is used. The flag octet is one of the inputs to AES during the counter mode encryption of the plaintext. Considering that the table only defines the modes that has 16-octet auth tags, whats the point of mentioning the other lengths? 20. Section 4: RFC 4568 defines SRTP "crypto suites" I would prefer that one instead of just using the "RFC 4568" as handle to the specification instead included the title or an abbreviated one at least. Like this: Security Descriptions [RFC4586] defines SRTP "crypto suites" This I think is much more clear as I don't have to go to the reference section if I don't directly remember what the RFC number is. 21. Section 4: RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to a particular AEAD algorithm in SRTP. In order to allow SDP to signal the use of the algorithms defined in this document, IANA will register the following crypto suites into the subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions: srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / "AEAD_AES_256_GCM" / "AEAD_AES_128_GCM_8" / "AEAD_AES_256_GCM_8" / "AEAD_AES_128_GCM_12" / "AEAD_AES_256_GCM_12" / "AEAD_AES_128_CCM" / "AEAD_AES_256_CCM" / Igoe and McGrew Informational [Page 15] Internet Draft AES-GCM and AES-CCM for SRTP Feb 17, 2012 srtp-crypto-suite-ext I don't think this fulfills the registration requirement in that it hasn't made it clear how the key-salt structure for inline method are constructed. How many bits of keys, and how many bits of salt is to be included in the structure. 22. Section 4: When it comes to DTLS-SRTP the protection profiles defined in RFC 5764 has the following information defined in its section 4.1.2 SRTP_AES128_CM_HMAC_SHA1_80 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80 I believe this information is present, but maybe it should be collected together. It also doesn't define how the AEAD parameters defined in this specification actually are parameterized when needed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Tue May 22 04:04:37 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D658121F85D4 for ; Tue, 22 May 2012 04:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 ej0V+MJLhn0n for ; Tue, 22 May 2012 04:04:36 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id B08F321F85D0 for ; Tue, 22 May 2012 04:04:35 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SWmtG-0005O8-hz; Tue, 22 May 2012 11:04:34 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: <8550925CD2F24829AC4483B12606F03A@china.huawei.com> Date: Tue, 22 May 2012 12:04:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1278) Cc: Albrecht Schwarz , avt@ietf.org Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:04:37 -0000 I also don't agree with deleting Section 3.3 from the monarch draft.=20 The architecture needs to be clear that there are valid scenarios for = RTP monitoring within a network, either in some middlebox that comprises = part of an RTP session, or in a third-party monitoring device used for = network management purposes. Section 3.3 is a reasonable place to = discuss these, and to explain why the metrics that can be reported from = middleboxes are different to those that can be captured at end systems. Colin On 22 May 2012, at 07:53, Qin Wu wrote: > Hi,: > ----- Original Message -----=20 > From: "Albrecht Schwarz" > To: > Cc: ; > Sent: Tuesday, May 22, 2012 11:18 AM > Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 >=20 >=20 > Dear All, >=20 > concerning the resolution proposal for clause 3.3: > I don't agree in just deleting again that section! > There was quite a long debate for incorporating such a clause. > The original text proposal was much more detailed. Perhaps the = shortening to just a single paragraph is the main cause for unclarity. > Thus, instead of removing previous agreed text, we just rather extend = it again. >=20 >=20 > [Qin]:=20 > The reason I propose to remove the section 3.3 is=20 > a. I think Robert is correct. The set of meaningful metrics isn't = changed at all wherever you collect them. It seems little sense=20 > to say "the location of the RTP Sender/Receiver entities may impact = a set of meaningful metrics. "=20 > b. Where to gather or measure metrics can be indicated by the = definition of Transport metrics, End system metrics and application = level metrics. > c. Section 3.3 seems to discuss where to gather what metrics. = Recommendation ITU-T G.1081 have already defined five monitoring points=20= > where the performance measurements can be made. >=20 >> I think the definition of application level metrics has already = clarified that application level metrics is normally gathered from user = endpoint.=20 >=20 > No. We did discuss this already extensively. > An RTP media translator could provide application level metrics = because e.g. terminating the application protocol layer. > Such an RTP topology is NOT located in an user endpoint! >=20 > [Qin]: Sorry, I should correct me to say QoE metric is ususally = measured at the user endpoint. >=20 > Regards, > Albrecht > ________________________________ > [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread = Index]=20 > Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 > ________________________________ >=20 > * To: Robert Sparks , IETF AVTCore WG , > * Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 > * From: Qin Wu > * Date: Fri, 18 May 2012 18:37:56 +0800 > * Delivered-to: avt at ietfa.amsl.com > * List-archive: > * List-help: > * List-id: Audio/Video Transport Core Maintenance > * List-post: > * List-subscribe: , = > * List-unsubscribe: , = > * References: <4FB2E323.3090406 at nostrum.com> > ________________________________ >=20 > Hi,Robert: > Thank for your valuable review. please see my replies inline belows. = Regards! > -Qin > ----- Original Message -----=20 > From: "Robert Sparks" > To: "IETF AVTCore WG" ; > Sent: Wednesday, May 16, 2012 7:13 AM > Subject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 = > Summary: There are issues to resolve with a revised ID before=20 >> progressing to IETF LC. >>=20 >> It's a struggle to see the _architecture_ this document is supposed = to=20 >> describe. I suspect most of the working group energy went into = Section 5=20 >> (the guidelines for writing XR block definitions) - the rest of the=20= >> document needs a similar level of attention to detail. >>=20 >> There are two major issues that I've tagged with a (*). I followed a=20= >> mostly document-order flow instead of grouping the major issues at = the top. >>=20 >> (*) Given the document's title, it should be very easy to answer = "What=20 >> is the monitoring architecture?" for people who are reading this = draft=20 >> for the first time. >> The key message is that the monitoring architecture consists of = Monitors=20 >> that exchange information using RTCP Metric Blocks. [Qin]: Agree. = >The text should say=20 >> that. [Qin]: Okay. > There is a lot of prose in section 3 and visual = detail in the=20 >> diagram in Figure 1 that makes that extremely difficult to see.=20 >> Simplifying the figure by removing the details about applications and=20= >> transports, or at least moving them to a second figure, making the=20 >> Monitor boxes stand out, and making the types of information flows = (the=20 >> arrows) visually distinctive would help. Simplify the prose (much of = it=20 >> could be removed) to focus on that key message. [Qin]: Agree, I = propose to remove the figure 1 and squeeze the section 3.1 as follows: " = 3.1. Overview The RTP monitoring architecture comprises the following = two key functional components shown below: o RTP Monitor o RTP Metric = Block Structure RTP Monitor is the functional component defined in the = Real-time Transport Protocol [RFC3550]. It acts as a source of = information gathered for monitoring purposes and exchanges information = with the other RTP monitors using RTCP Metric Blocks. According to the = definition of monitor in the RTP Protocol [RFC3550], the end system that = runs an application program that sends or receives RTP data packets, an = intermediate- system that forwards RTP packets to End-devices or a third = party that observes the RTP and RTCP traffic but does not make itself = visible to the RTP Session participants (i.e., the third party monitor = depicted in figure 1) can act as the > RTP monitor. The third party monitor should be placed on the RTP/RTCP = paths between the sender, intermediate and the receiver. The RTP monitor = also exposes real time Application QoS/QoE metric information in the = appropriate report block format (e.g.,RTCP XR or othe non-RTP means) to = the management system. Such information can be formulated as different = metric types, e.g.,application level metric, transport level metric, end = system metric, interval metric, cumulative metric, sampled metric, = direct metric, composed metric,etc. Both the RTCP or RTCP XR can be = extended to convey these metrics. The details on transport protocols for = these metric are described in Section 3.2. RTP may be used to multicast = groups, both Any Source Multicast (ASM) and Source Specific Multicast = (SSM). These groups can be monitored using RTCP. In the ASM case, the = monitor is a member of the multicast group and listens to RTCP XR = reports from all members of the ASM > group. In the SSM case, there is a unicast feedback target that = receives RTCP feedback from receivers and distributes it to other = members of the SSM group (see figure 1 of RFC5760). The monitor will = need to be co-located with the feedback target to receive all feedback = from the receivers (this may also be an intermediate system). In both = ASM and SSM scenarios, receivers can send RTCP XR reports to enhance the = reception quality reporting. " > In the definition of Composed metrics, = the sentence "An example is a=20 >> metric calculated based on derived metrics that have been measured."=20= >> makes little sense. [Qin] The derived metrics in the sentence should = been corrected as "direct metric". >Did you mean something like "An = example is a metric=20 >> derived by algorithmically combining measured metrics."? [Qin]:I = agree with your suggested text and like to adopt your suggestion. > The = definitions of Interval, Cumulative, and Sampled metrics are not clear. = [Qin]: I agree the definition for these three metrics need to be more = cleaer, I proposes to do the following changes: NEW Text: " Interval = metrics Metrics of which the reported values are measured in the most = recent measurement interval duration between successive metrics reports. = Such measurement interval is equal to one RTCP report interval = (RFC3550,Section 6.2). Cumulative metrics Metrics of which the reported = values apply to the accumulation period characteristic of cumulative = measurements. The reported values are measured during the accumulation = period. The accumulation period spans over more than one RTCP report = intervals. Sampled metrics Metrics of which the reported values only = apply to the value of a continuously measured or > calculated metric that has been sampled at any given instance of the = RTCP report interval. One example of such metric is the inter-arrival = jitter described in the section 6.4.1 of RFC3550. " > If the discussion = at the end of section 3.1 is kept, the reference to=20 >> RFC5760 should be a real reference, and RFC5760 should appear in the=20= >> reference section. [Qin]: Okay. > The point of section 3.2 is not = obvious. How does it contribute to the=20 >> description of the architecture. It mixes talking about what report=20= >> blocks are with occasionally needing to send them more frequently. = Those=20 >> points could be made separately and more simply. [Qin]: Okay. I like = to incorporate the key points in the section 3.2 into section 3.1 > = Section 3.3 is not clear - it starts off saying that the location of the=20= >> sender and receiver may change what metrics are meaningful. It's not=20= >> clear what you mean by location. You certainly don't mean geospatial=20= >> coordinates. Do you mean anything other than whether the element is=20= >> trusted or untrusted by the operations network? If so, say that. The=20= >> rest of the paragraph only speaks to what element collects the = metrics. [Qin] Section 3.3 is only used to describe where or from which = RTP entity to gather the metrics (i.e., measurement point) in the = physical network and is not focus of this document. Secondly, I think = the definition of application level metrics has already clarified that = application level metrics is normally gathered from user endpoint. > = It's not clear that the set of meaningful metrics is changed at all -=20 >> just where you collect them. If the set of meaningful metrics does in=20= >> fact change, there needs to be additional discussion here. [Qin]: The = metrics actually doesn't change.Since the definition of application = level metrics Have already conveyed the meaning of what section 3.3 = wants to describe, I propose to remove this section. > Section 4's first = paragraph: Is "probably" the best the working group=20 >> can say? [Qin]:No, will remove this word. > The last two sentences of = the second bullet in section 4 do not parse.=20 >> Please simplify them. [Qin]: Okay, how about change them as follows: = NEW Text: " With these minimal number of RTCP statistics parameters = mapped to non-RTCP measurements, it is hard to provide accurate measures = of real time application quality,conduct detailed data analysis and = creates alerts timly to the users. Therefore correlation between RTCP XR = and non-RTP data should be provided. " > The first full sentence of the = third bullet in section 4 does not make=20 >> sense. The whole bullet could be clarified. [Qin]: Agree and will = remove the first sentence. > The fourth bullet in section 4 and section = 5.5 should call out that=20 >> RFC3611 already set Block Type 255 aside for future extensions,=20 >> anticipating the potential need to extend the block type space. = [Qin]: Okay, How about revising the section 4,bullet 4 as follows: " = Consumption of XR block code points. The RTCP XR block namespace is = limited by the 8-bit block type field in the RTCP XR header. Space = exhaustion may be a concern in the future. Anticipating the potential = need to extend the block type space, it is noted in [RFC3611] that Block = Type 255 is reserved for future extensions, " > In section 5, consider = naming the subsections with the actual guideline=20 >> instead of the problem the guideline is trying to address. >> 5.1. Metric blocks should contain a single metric [Qin]: I suggest to = change it as "Contain the single metrics in the metric block" > 5.2. = Include the payload type and format parameters in the metric block = [Qin]: Okay. > 5.3. Use RTCP SDES to correlate XR reports with non-RTP = data [Qin]: Okay. > 5.4. Don't repeat measurement information across = metric blocks >>=20 > [Qin]: It is not possible completely to avoid measurement information = repeatition. e.g., for packet loss robustness if the report blocks for = the same interval span over more than one RTCP packet then each must = have the same measurement identity information So I suggest to change it = as: "reduce measurement information across metric blocks" > This points = out a structural problem with the section. Why is 5.5 here?=20 >> It's not a guideline. [Qin]: Agree and also as discussed,Space = exhaustion is not big issue. How about remove this section? > (*) And it = raises a question about what the document is trying to=20 >> achieve with section 5.4. That section claims the document is = proposing=20 >> a new XR block type to help avoid duplication, but it doesn't = actually=20 >> define the new block type. Is the guideline saying simply don't = repeat=20 >> measurements or its the guideline saying "use this new XR block type = we=20 >> haven't defined yet"? [Qin]: Just to clarify, we have already defined = one new XR Block type to help avoid or reduce duplication. It is = measurement information block. The relevant draft is available at: = http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-meas-identity-06 = >The section needs more clarity. If it really is=20 >> trying to define a new type, there's more work to be done. [Qin]: In = order to avoid such confusion, I proposed to do the following change to = the section 5.4: OLD Text: " This memo proposes to define a new XR Block = that will be used to convey the common time period and the number of = packets sent during this period. " New text: " This memo proposes to = define a new XR Block (i.e., the Measurement information = block[I.D-ietf-xrblock-rtcp-xr-meas-identity]) that will be used to = convey the common time period and the number of packets sent during this = period. " > The Security Considerations section, particularly the third = paragraph,=20 >> needs to be clearer. What exactly do you mean by "monitoring should = be=20 >> prohibited", and how is the fact that third party monitors don't send=20= >> RTCP relevant? Did you intend those to be separate points? [Qin]: = Yes, they are on the different port. Such monitor may receive RTP packet = but does not send RTCP packet. > Editorial Nits and Suggestions: >>=20 >> The first paragraph of the introduction is overly complex, and won't = age=20 >> well. I suggest replacing it with: "Multimedia services using the=20 >> Real-Time Protocol (RTP) are seeing increased use. Standard methods = for=20 >> gathering RTP performance metrics from these applications are needed = to=20 >> manage uncertainties in the behavior and availability of their=20 >> services." Then replace "These rapidly emerging standards," with=20 >> "Standards". [Qin]: Okay. > Introduction paragraph 3 sentence 2 = should start "The RTCP Guidelines=20 >> [RFC5968]". It would be even better to use the full title from 5968:=20= >> 'The "Guidelines for Extending the RTP Control Protocol (RTCP)" = [RFC5968]' [Qin]: Okay. > This may become moot as section 3 is modified = to make its main point=20 >> more obvious, but RFC3550 does not characterize Monitors as "a source = of=20 >> information". That could be misunderstood. Please choose another = word.=20 >> Perhaps "repository"? [Qin]: Okay, repository looks good to me. > In = bullet lists, starting an entry with "or" or "and" is unnecessary. It=20 >> should be clear from the introduction to the list whether the = individual=20 >> entries should be combined or selected from. [Qin]: Okay. > In = section 3.1 where you say "RTP may be used to multicast groups" did=20 >> you mean "RTP may be sent to multicast groups" or "RTP may be used = with=20 >> multicast groups"? [Qin]: I think it should be the latter case,i.e.," = RTP may be used with=20 > multicast groups". >=20 >> In section 3.2 "The following are four use cases but are not limited=20= >> to:" does not parse. The bullets aren't really use cases as much as = they=20 >> are mechanisms. Would it make more sense to say "Here are four=20 >> mechanisms that have been created to address the need for more = frequent=20 >> reporting. This list is not intended to be exhaustive." The third = bullet=20 >> in that list should say "RTCP and RTCP XR are" instead of "RTCP or = RTCP=20 >> XR is". [Qin]: Okay, but I have incorporated the keypoints of section = 3.2 into section 3.1. > The bullets in section 4 would be better as = subsections with titles=20 >> (taken from the first phrase of the bullet). [Qin]: Okay. > I suggest = this alternative for the first full sentence in the first=20 >> bullet of section 4 : "A compound metrics block is designed to = contain a=20 >> large number of parameters from different classes for a specific=20 >> application in a single block." [Qin]: Okay. > Section 5's title = should be "Guidelines for reporting" instead of=20 >> "Guideline for reporting" [Qin]: Okay. > In section 5.1 I suggest = "justify the overhead," instead of "justify the=20 >> overheads," [Qin]: Okay. > Section 7 - the last sentence of the first = paragraph does not parse. The=20 >> second paragraph (which is a single sentence) should be clarified - = an=20 >> MCU is not a topology. [Qin]: Okay. How about revising them as = follows: OLD Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems do not behave according to the RTP protocol [RFC3550]. = Considering the MCU and translator are two typical topologies in the two = categories mentioned above, this document will take them as two typical = examples to explain how RTCP XR report works in different RFC5117 = topologies. " NEW Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems (e.g.,MCU) do not behave according to the RTP protocol = [RFC3550]. Considering the MCU and translator are two typical = intermediary systems in the two categories mentioned above, this = document will take them as two typical examples to explain how RTCP XR = report works in different RFC5117 topologies. " > The last two sentences = of the first > paragraph of the security=20 >> considerations section add nothing to the document. I suggest = deleting them. [Qin]: Okay. > = _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt at ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > ________________________________ >=20 > * References:=20 > * [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13=20 > * From: Robert Sparks > * Prev by Date: [AVTCORE] Protocol Action: 'Explicit Congestion = Notification (ECN) for RTP over=20 > UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)=20 > * Previous by thread: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13=20 > * Next by thread: [AVTCORE] Protocol Action: 'Explicit Congestion = Notification (ECN) for RTP over=20 > UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)=20 > * Index(es):=20 > * Date > * Thread > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Tue May 22 04:57:42 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1C521F85E5; Tue, 22 May 2012 04:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.611 X-Spam-Level: X-Spam-Status: No, score=-98.611 tagged_above=-999 required=5 tests=[AWL=-3.988, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 xJTcasxnNNfa; Tue, 22 May 2012 04:57:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA72221F85D6; Tue, 22 May 2012 04:57:41 -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.02 Message-ID: <20120522115741.11237.11586.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 04:57:41 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:57:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : Ray van Brandenburg Hans Stokking Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-04.txt Pages : 21 Date : 2012-05-22 This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media playout information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-idms-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/ From Felix.Wyss@inin.com Tue May 22 07:05:34 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC921F85F1 for ; Tue, 22 May 2012 07:05:34 -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 I4f7He1TTbe5 for ; Tue, 22 May 2012 07:05:33 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by ietfa.amsl.com (Postfix) with ESMTP id AD32C21F85DD for ; Tue, 22 May 2012 07:05:32 -0700 (PDT) Received: from hub1.i3domain.inin.com [172.17.60.36] by smtpedge.inin.com - Websense Email Security (7.3.0); Tue, 22 May 2012 10:05:30 -0400 Received: from MAILDB2.i3domain.inin.com ([fe80::1c14:d969:a21a:e887]) by Hub1.i3domain.inin.com ([fe80::fc5a:f565:b6c5:4f42%11]) with mapi id 14.01.0289.001; Tue, 22 May 2012 10:05:31 -0400 From: "Wyss, Felix" To: 'Magnus Westerlund' , "'draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org'" Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 Thread-Index: AQHNN/OQaXHhEAzfokaQDbHlzpg6eJbV0dzw Date: Tue, 22 May 2012 14:05:30 +0000 Message-ID: References: <4FBB4BD3.9000909@ericsson.com> In-Reply-To: <4FBB4BD3.9000909@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.101.222] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 7_3_0_01181__2012_05_22_10_05_30 Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:05:34 -0000 Furthermore, the issues raised in the following document should be addresse= d in section #3: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fergu= son2.pdf It basically means the modes with authentication tags smaller than 16 octet= s MUST NOT be used with AES-GCM. =20 In light of that, I question the value of supporting a GCM based mode for S= RTP.=20 Thanks, --Felix > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Tuesday, May 22, 2012 04:18 > To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org > Cc: IETF AVTCore WG > Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 >=20 > Hi, >=20 > I got a request to progress this document towards WG last call. So while > we chairs are cleaning up some administrative stuff, like getting a > milestone in place. I thought the authors should get something to do and > thus reviewed the draft. >=20 > 1) Section 1.1 > "Crypto Context For the purposes of this document a crypto context > is the outcome of any process which results in > authentication of each participant in the SRTP > session and possession by each partcipant of a > shared secret master key and a shared master > salt." >=20 > What is the definition of participant here, SSRC, endpoint, user, or > system? Please correct the "partcipant" spelling error also. >=20 > 2) Section 1.1, crypto context: " Ciper Contest" I guess should be Crypto > Context. >=20 > 3) Section 1.1. is the text for crypto context really accurate as the > document does define protection profiles for both DTLS-SRTP and Security > description. >=20 > 4) I am missing protection profiles for MIKEY. I think they should be > defined as MIKEY is the third key-management protocol and are used in a > lot of cases which neither DTLS-SRTP and Security Description are suitabl= e > for. >=20 > 5) Section 1.1 Instantiation: > "each participant in the SRTP/SRTCP > session will need four instantiations of the AEAD > algorithm; one for inbound SRTP traffic, one for > outbound SRTP traffic source, one for inbound > SRTCP traffic, and one for outbound SRTCP traffic > source. " >=20 > Is this really correct. This seems to be limiting the use of AEAD to poin= t > to point scenarios? The other crypto transforms for SRTP are capable of > handling group scenarios. DTLS-SRTP with EKT for example would allow each > end-point to distribute its own master key that it will use for the SSRCs > it sends. There are also scenarios where one use a common master key for > all participants. >=20 > 6) Section 1.2: Associated Data This is data that is to be > authenticated > but not encrypted. In SRTP, the associated > data consists of the entire RTP header, > including the list of CSRC identifiers (if > present) and the RTP header extension (if > present), as shown in Figure 3. >=20 > Shouldn't this point to and discuss the relation to > draft-ietf-avtcore-srtp-encrypted-header-ext-01 >=20 > 7. Section 1.2: > Associated Data This is data that is to be authenticated > but not encrypted. In SRTP, the associated > data consists of the entire RTP header, > including the list of CSRC identifiers (if > present) and the RTP header extension (if > present), as shown in Figure 3. >=20 > Plaintext Data that is to be both encrypted and > authenticated. In SRTP this consists of > the RTP payload, the RTP padding and the > RTP pad count fields (if the latter two > fields are present) as shown in Figure 3. > The padding service provided by RTP is not > needed by the AEAD encryption algorithm, so > the RTP padding and RTP pad count fields > SHOULD be omitted. >=20 > Why are these paragraphs not discussing RTCP? >=20 > 8. Section 1.2.1: > (Note that this means > that the cipher text will be longer than the plain text by precisely > the length of the AEAD authentication tag.) >=20 > This needs more extensive discussion as it needs to be taken into account > in RTP/RTCP when determine packet sizes both for generating right sized > RTP that don't violate MTU and that they are included in the RTCP > avg_rtcp_size parameter part of the scheduling algorithm. >=20 > 9. Section 1.2.2: For confirmation: >=20 > Packet Counter Each AEAD instantiation MUST maintain a 6 octet > zero-based packet counter which is incremented > each time an SRTP packet is sent. As we shall > see below, the packet counter is used to insure > each SRTP packet gets a unique initialization > vector. >=20 > Can this use the "ROC" distribution mechanism (RFC4771) or what the key- > management provide to correctly deduce the field, or will it have problem= s > with late joiners in a group communication? >=20 > 10. Section 1.2.2 Packet Counter: >=20 > "zero-based packet counter" Does this mean that the 6 octet long field is > initialized to 0 and thus violate the recommendation of RTP sequence > number requirement of random start position. >=20 > 11. Section 1.5: I don't like using the figure to indicate what is of > different types. Two reasons. The first is that it doesn't explicitly > enumerate protocol fields, instead 32-bytes octet with fields. Secondly > because it make it hard for someone that can't see to correctly interpret > this. Think if Sam Hartman would like to read this spec. You made it much > more difficult for him. You had a description earlier that with a bit mor= e > precision would be correct, after having dealt with comment 6 and what > needs to be included due to that. >=20 > 12. Section 1.6. AEAD Processing of SRTCP Packets >=20 > All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP > packet encryption is optional. A sender can select which packets to > encrypt, and indicates this choice with a 1-bit encryption flag > (located in the leftmost bit of the 32-bit word that contains the > SRTCP index) >=20 > I think it is important to write "SRTCP packet" as SRTCP compount packet. > As each individual RTCP packet can't be individually encrypted or not in > the same compound packet. >=20 > 13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here you > may have to talk about octets as it is defined as the first of 32-bit > words of the first RTCP packet part of the compound that are unencrypted. >=20 > 14. Section 1.8. Prevention of IV Reuse >=20 > For a given key it is critical that the IV not repeat. This reduces > to the problem of insuring neither the Packet Counter nor the SRTCP > index do not repeat before the AEAD instantiation is rekeyed. >=20 > Processing MUST cease if either the 48-bit Packet Counter or the > 31-bit SRTCP index cycles back to their initial value. Processing > MUST NOT resume until a new SRTP/SRTCP session has been established > using a new shared secret master key and shares master salt. > Ideally, a rekey should be done well before either of these counters > cycle. >=20 > This section fails to discuss another issue where IV reuse could arise. > Namely SSRC collision. If more than a single end-point uses the same SSRC > there can be collision. This either put stringent requirements on how one > key this crypto transform in different topologies or the usage of SSRC > assignment rules. As the later is not really present it might be worth > defining rules and be clear on the impact of an SSRC collision. >=20 > 15. Section 2.1: > C_MAX maximum ciphertext MUST be at most 2^16-40 octets > length per invocation SHOULD be at least 2232 >=20 > I think the lower bound reasonsing is flawed. First of all there is RTCP > that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers > thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675) > which support packet sizes of 2^32 bytes. >=20 > I think the max should be set to what the upper limit where something > breaks. Is 2^32 a working limit from crypto perspective, in that case I > think you should use that. >=20 > 16. Minimal value for C_MAX > Similarly the lower bound on C_MAX is based on the maximum > transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many > RTP applications use very short payloads (for example, the G.729 > codec used in VoIP can be as short as 20 octets), implementations > that only support a maximum ciphertext length smaller than 2232 > octets are permitted under this RFC. However, in the interest of > maximizing interoperability between various AEAD implementations, the > use of C_MAX values less than 2232 is discouraged. >=20 > I actually think the minimum value should be that a C_MAX value of 2234 > MUST be supported. My reasoning is that it must be 2 bytes larger to > support full MTU RTCP. Then it really should be a MUST to ensure that one > knows that a counter part can support that size of plaintext. I would lik= e > to point out that the current key-management systems aren't the greatest > for negotiating a lot of sub-parameters. For example my understanding is > that DTLS-SRTP only support negoptiating whole profiles, not sub- > parameters at all. >=20 > So if you are not specifying a hard limit what packet size a receiver mus= t > support how do you know that you can interoperate? >=20 > At the same time I realize that this is not optimal for a very constraine= d > device that sends encrypted real-time payloads of some type that are much > smaller and actually don't have the buffering space for so large packets. >=20 > Maybe the way forward is to separate the C_max value boundary and the > minimal value supported for the defiended profiles and make it clear that > the protection profiles defined in 2.2 and 2.3 actually requires a C_max > that is 2234. >=20 >=20 > 17. Section 2.1: >=20 > For sake of clarity we specify two additional parameters: >=20 > Authentication Tag Length MUST be either 8, 12, or 16 > octets > Maximum number of invocations MUST be at most 2^48 for SRTP > for a given instantiation MUST be at most 2^31 for SRTCP >=20 > As these parameters are for AEAD algorithms in general, how can you be > certain that no one likes an authentication tag length longer than 16 > bytes or for that matter one that is 14 bytes? >=20 > I guess the maximum number of invocations also comes from an assumption > around the IV construction. Which I am not certain holds as you clearly > defined the IV specifically for the algorithms and other AEAD algorithms > can make a different choice for IV including an explicit one, can't they? > Thus does these max values really hold? >=20 > 18. Section 2.2 > In addition to the Packet Counter used in the formation of IVs, each > instantiation of AES-GCM has a block counter which is incremented > each time AES is called to produce a 16-octet output block. >=20 > I would prefer that you where more explicit about the lenght of the block > counters length, i.e ... AES-GCM has a block counter (32-bit) which ... >=20 > This also applies to the corresponding text in 2.3. >=20 > 19. Section 2.3: > For AES-CCM in SRTP/SRTCP, the > flag octet has the hex value 5A if an 8-octet authentication tag is > used, 6A if a 12-octet authentication tag is used, and 7A if a > 16-octet authentication tag is used. The flag octet is one of the > inputs to AES during the counter mode encryption of the plaintext. >=20 > Considering that the table only defines the modes that has 16-octet auth > tags, whats the point of mentioning the other lengths? >=20 > 20. Section 4: >=20 > RFC 4568 defines SRTP "crypto suites" >=20 > I would prefer that one instead of just using the "RFC 4568" as handle to > the specification instead included the title or an abbreviated one at > least. Like this: >=20 > Security Descriptions [RFC4586] defines SRTP "crypto suites" >=20 > This I think is much more clear as I don't have to go to the reference > section if I don't directly remember what the RFC number is. >=20 > 21. Section 4: >=20 > RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to > a particular AEAD algorithm in SRTP. In order to allow SDP to signal > the use of the algorithms defined in this document, IANA will > register the following crypto suites into the subregistry for SRTP > crypto suites under the SRTP transport of the SDP Security > Descriptions: >=20 > srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" / > "AEAD_AES_256_GCM" / > "AEAD_AES_128_GCM_8" / > "AEAD_AES_256_GCM_8" / > "AEAD_AES_128_GCM_12" / > "AEAD_AES_256_GCM_12" / > "AEAD_AES_128_CCM" / > "AEAD_AES_256_CCM" / >=20 > Igoe and McGrew Informational [Page 15] > Internet Draft AES-GCM and AES-CCM for SRTP Feb 17, 2012 >=20 > srtp-crypto-suite-ext >=20 > I don't think this fulfills the registration requirement in that it hasn'= t > made it clear how the key-salt structure for inline method are > constructed. How many bits of keys, and how many bits of salt is to be > included in the structure. >=20 > 22. Section 4: >=20 > When it comes to DTLS-SRTP the protection profiles defined in RFC 5764 ha= s > the following information defined in its section 4.1.2 > SRTP_AES128_CM_HMAC_SHA1_80 > cipher: AES_128_CM > cipher_key_length: 128 > cipher_salt_length: 112 > maximum_lifetime: 2^31 > auth_function: HMAC-SHA1 > auth_key_length: 160 > auth_tag_length: 80 >=20 > I believe this information is present, but maybe it should be collected > together. It also doesn't define how the AEAD parameters defined in this > specification actually are parameterized when needed. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From bill.wu@huawei.com Tue May 22 18:33:36 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2AC21F86B0 for ; Tue, 22 May 2012 18:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.246 X-Spam-Level: X-Spam-Status: No, score=-4.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, 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 WeJXhg0mbkrW for ; Tue, 22 May 2012 18:33:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ADED021F86AF for ; Tue, 22 May 2012 18:33:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGL09991; Tue, 22 May 2012 21:33:35 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 18:31:05 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 18:31:03 -0700 Received: from w53375 (10.138.41.149) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 09:30:59 +0800 Message-ID: <4E75E88AD2C84AC6A3824697C4126DB2@china.huawei.com> From: Qin Wu To: Robert Sparks , IETF AVTCore WG , References: <4FB2E323.3090406@nostrum.com> Date: Wed, 23 May 2012 09:30:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 01:33:36 -0000 Pj4gVGhlIGRlZmluaXRpb25zIG9mIEludGVydmFsLCBDdW11bGF0aXZlLCBhbmQgU2FtcGxlZCBt ZXRyaWNzIGFyZSBub3QgY2xlYXIuDQo+IA0KPiBbUWluXTogSSBhZ3JlZSB0aGUgZGVmaW5pdGlv biBmb3IgdGhlc2UgdGhyZWUgbWV0cmljcyBuZWVkIHRvIGJlIG1vcmUgY2xlYWVyLCBJIHByb3Bv c2VzIHRvIGRvIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCj4gDQo+IE5FVyBUZXh0Og0KPiANCj4g Ig0KPiANCj4gICBJbnRlcnZhbCBtZXRyaWNzDQo+IA0KPiANCj4gDQo+ICAgICAgTWV0cmljcyBv ZiB3aGljaCB0aGUgcmVwb3J0ZWQgdmFsdWVzDQo+IA0KPiAgICAgIGFyZSBtZWFzdXJlZCBpbiB0 aGUgbW9zdCByZWNlbnQgbWVhc3VyZW1lbnQgaW50ZXJ2YWwgZHVyYXRpb24gYmV0d2Vlbg0KPiAN Cj4gICAgICBzdWNjZXNzaXZlIG1ldHJpY3MgcmVwb3J0cy4gU3VjaCBtZWFzdXJlbWVudCBpbnRl cnZhbCBpcyBlcXVhbCB0byBvbmUgDQo+IA0KPiAgICAgUlRDUCByZXBvcnQgaW50ZXJ2YWwgKFJG QzM1NTAsU2VjdGlvbiA2LjIpLiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgIEN1bXVsYXRpdmUg bWV0cmljcw0KPiANCj4gDQo+IA0KPiAgICAgIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVk IHZhbHVlcw0KPiANCj4gICAgICBhcHBseSB0byB0aGUgYWNjdW11bGF0aW9uIHBlcmlvZCBjaGFy YWN0ZXJpc3RpYyBvZiBjdW11bGF0aXZlDQo+IA0KPiAgICAgIG1lYXN1cmVtZW50cy4gVGhlIHJl cG9ydGVkIHZhbHVlcyBhcmUgbWVhc3VyZWQgZHVyaW5nIHRoZSBhY2N1bXVsYXRpb24gcGVyaW9k LiANCj4gDQo+ICAgVGhlIGFjY3VtdWxhdGlvbiBwZXJpb2Qgc3BhbnMgb3ZlciBtb3JlIHRoYW4g b25lIFJUQ1AgcmVwb3J0IGludGVydmFscy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgIFNhbXBs ZWQgbWV0cmljcw0KPiANCj4gDQo+IA0KPiAgICAgIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9y dGVkIHZhbHVlcyBvbmx5DQo+IA0KPiAgICAgIGFwcGx5IHRvIHRoZSB2YWx1ZSBvZiBhIGNvbnRp bnVvdXNseSBtZWFzdXJlZCBvciBjYWxjdWxhdGVkIG1ldHJpYw0KPiANCj4gICAgICB0aGF0IGhh cyBiZWVuIHNhbXBsZWQgYXQgYW55IGdpdmVuIGluc3RhbmNlIG9mIHRoZSBSVENQIHJlcG9ydCBp bnRlcnZhbC4gDQo+IA0KPiAgICAgT25lIGV4YW1wbGUgb2Ygc3VjaCBtZXRyaWMgaXMgdGhlIGlu dGVyLWFycml2YWwgaml0dGVyIGRlc2NyaWJlZCBpbiB0aGUgc2VjdGlvbiA2LjQuMSBvZiBSRkMz NTUwLg0KPiANCj4gIg0KW1Fpbl06IE9uZSBpbXByb3ZlbWVudCB0byBkZWZpbml0aW9ucyBvZiBJ bnRlcnZhbCBNZXRyaWNzLCBDdW11bGF0aXZlIE1ldHJpY3MgYW5kIFNhbXBsZWQgTWV0cmljcyB0 byBnZXQgYWxpZ25tZW50IHdpdGggZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbWVhcy1pZGVu dGl0eQ0Kc2luY2UgYmFzZWQgb24gZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbWVhcy1pZGVu dGl0eSwgaW4gc29tZSBjYXNlLHRoZSBtZWFzdXJlbWVudCBpbnRlcnZhbCBmb3IgYSBtZXRyaWMg aXMgZGlmZmVyZW50IGZyb20gdGhlIFJUQ1ANCnJlcG9ydGluZyBpbnRlcnZhbCwgaW4gc3VjaCBj YXNlLCBNZWFzdXJlbWVudCBpbmZvcm1hdGlvbiBibG9jayBpbiB0aGUgZHJhZnQtaWV0Zi14cmJs b2NrLXJ0Y3AteHItbWVhcy1pZGVudGl0eSBjYW4gYmUgdXNlZCB0byBzcGVjaWZ5IHN1Y2ggbWVh c3VyZW1lbnQgaW50ZXJ2YWwuDQoNClRoZSBwcm9wb3NlZCBpbXByb3ZlbWVudCBpcyBkZXNjcmli ZWQgYXMgZm9sbG93czoNCiINCkludGVydmFsIG1ldHJpY3M6DQoNCk1ldHJpY3MgY2FsY3VsYXRl ZCBiYXNlZCBvbiB2YWx1ZXMgbWVhc3VyZWQgb3ZlciB0aGUgY291cnNlIG9mIGEgc2luZ2xlIHJl cG9ydGluZyBpbnRlcnZhbC4gVGhpcyBtYXkgYmUgdGhlIG1vc3QgcmVjZW50IFJUQ1AgcmVwb3J0 aW5nIGludGVydmFsIChbUkZDMzU1MF0sIHNlY3Rpb24gNi4yKSBvciBzb21lIG90aGVyIGludGVy dmFsIHNpZ25hbGxlZCB1c2luZyBhbiBSVENQIE1lYXN1cmVtZW50IEluZm9ybWF0aW9uIFhSIEJs b2NrIFtkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLWlkZW50aXR5XS4gQW4gZXhhbXBs ZSBpbnRlcnZhbCBtZXRyaWMgaXMgdGhlIGNvdW50IG9mIHRoZSBudW1iZXIgb2YgUlRQIHBhY2tl dHMgbG9zdCBvdmVyIHRoZSBjb3Vyc2Ugb2YgdGhlIGxhc3QgUlRDUCByZXBvcnRpbmcgaW50ZXJ2 YWwuDQoNCkN1bXVsYXRpdmUgbWV0cmljczoNCg0KTWV0cmljcyBkZXJpdmVkIGZyb20gY3VtdWxh dGl2ZSBtZWFzdXJlbWVudHMgdGFrZW4gb3ZlciBzZXZlcmFsIHJlcG9ydGluZyBpbnRlcnZhbHMu IFRoZSB0aW1lIHBlcmlvZCBvdmVyIHdoaWNoIG1lYXN1cmVtZW50cyBhcmUgYWNjdW11bGF0ZWQg Y2FuIGJlIHRoZSBjb21wbGV0ZSBSVFAgc2Vzc2lvbiwgb3Igc29tZSBvdGhlciBpbnRlcnZhbCBz aWduYWxsZWQgdXNpbmcgYW4gUlRDUCBNZWFzdXJlbWVudCBJbmZvcm1hdGlvbiBYUiBCbG9jayBb ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbWVhcy1pZGVudGl0eV0uICBBbiBleGFtcGxlIGN1 bXVsYXRpdmUgbWV0cmljIGlzIHRoZSB0b3RhbCBudW1iZXIgb2YgUlRQIHBhY2tldHMgbG9zdCBz aW5jZSB0aGUgc3RhcnQgb2YgdGhlIFJUUCBzZXNzaW9uLg0KDQpTYW1wbGVkIG1ldHJpY3M6DQoN Ck1ldHJpY3MgdGhhdCBhcmUgc2FtcGxlZCBhdCBhIHBhcnRpY3VsYXIgdGltZSBpbnN0YW50IHdp dGhpbiBhIHJlcG9ydGluZyBpbnRlcnZhbCAoZ2VuZXJhbGx5IHRoZSB2YWx1ZSBvZiBzb21lIG1l YXN1cmVtZW50IGFzIHRha2VuIGF0IHRoZSBlbmQgb2YgdGhlIHJlcG9ydGluZyBpbnRlcnZhbCku IEFuIGV4YW1wbGUgaXMgdGhlIGludGVyLWFycml2YWwgaml0dGVyIHJlcG9ydGVkIGluIFJUQ1Ag U1IgYW5kIFJSIHBhY2tldHMsIHdoaWNoIGlzIGNvbnRpbnVhbGx5IHVwZGF0ZWQgYXMgZWFjaCBS VFAgZGF0YSBwYWNrZXQgYXJyaXZlcywgYnV0IG9ubHkgcmVwb3J0ZWQgYmFzZWQgb24gYSBzbmFw c2hvdCBvZiB0aGUgdmFsdWUgd2hpY2ggaXMgc2FtcGxlZCBhdCB0aGUgaW5zdGFudCB0aGUgcmVw b3J0aW5nIGludGVydmFsIGVuZHMuDQoNCiINCg== From bill.wu@huawei.com Tue May 22 20:24:57 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D321F854B; Tue, 22 May 2012 20:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, MIME_BASE64_TEXT=1.753, 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 nmMPGthcl6Bc; Tue, 22 May 2012 20:24:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2646421F851C; Tue, 22 May 2012 20:24:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGL17276; Tue, 22 May 2012 23:24:48 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 20:22:04 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 20:22:08 -0700 Received: from w53375 (10.138.41.149) by szxeml423-hub.china.huawei.com (10.82.67.162) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 11:22:04 +0800 Message-ID: <565CA625413A4126AF25B21F2EC5F71F@china.huawei.com> From: Qin Wu To: Colin Perkins References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> Date: Wed, 23 May 2012 11:22:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: Albrecht Schwarz , avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 03:24:57 -0000 SGksDQpUYWtlIFJvYmVydCxDb2xpbiBhbmQgQWxicmVjaGV0J3MgY29tbWVudHMgaW50byBhY2Nv dW50LCBJIHByb3Bvc2UgdG8gcmV3cml0ZSBzZWN0aW9uIDMuMyB3aXRoIHRoZSBmb2xsb3dpbmcg Y2hhbmdlczoNCk9MRCBURVhUOg0KIg0KMy4zLiAgUlRQIFNlbmRlci9SZWNlaXZlciBlbnRpdGll cyBsb2NhdGVkIGluIG5ldHdvcmsgbm9kZXMNCg0KICAgVGhlIGxvY2F0aW9uIG9mIHRoZSBSVFAg U2VuZGVyL1JlY2VpdmVyIGVudGl0aWVzIG1heSBpbXBhY3QgYSBzZXQgb2YNCiAgIG1lYW5pbmdm dWwgbWV0cmljcy4gIEZvciBpbnN0YW5jZSwgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcyBmb3Ig UW9FDQogICByZWxhdGVkIHBlcmZvcm1hbmNlIHBhcmFtZXRlcnMgYXJlIHVuZGVyIG1vc3QgY29u ZGl0aW9ucyBtZWFzdXJlZCBhdA0KICAgdGhlIHVzZXIgZGV2aWNlIHRoYXQgcmVjZWl2ZXMgUlRQ IGRhdGEgcGFja2V0cy4gIEhvd2V2ZXIgaW4gc29tZQ0KICAgY2FzZXMsIGdpdmVuIHRoZSBmYWN0 b3JzICggIm1lYXN1cmVtZW50IHBvaW50IGxvY2F0aW9uIiwgIm1lYXN1cmVtZW50DQogICBtb2Rl bCBsb2NhdGlvbiIsICJhd2FyZW5lc3Mgb2YgY29udGVudCBpbmZvcm1hdGlvbiIsIGV0YyBbUC5O QU1TXSkNCiAgIHRha2VuIGludG8gYWNjb3VudCwgc3VjaCBtZXRyaWNzIG1heSBiZSBtZWFzdXJl ZCBpbiBhIG5ldHdvcmsgbm9kZQ0KICAgaW5zdGVhZCBvZiBhIHVzZXIgZGV2aWNlLg0KDQoiDQpO RVcgVEVYVDoNCiINCjMuMy4gTWVhc3VyZW1lbnQgcG9pbnQgb2YgdGhlIFJUUCBtb25pdG9yIHdp dGhpbiB0aGUgbmV0d29yay4NCg0KVGhlIFJUUCBtb25pdG9ycyBhcmUgc3ByZWFkIGFjcm9zcyBh IHNpbmdsZSBkb21haW4oZS5nLiwgbmV0d29yayAgZG9tYWluKSBvciANCm11bHRpcGxlIGRvbWFp bnMgKGUuZy4sIGJldHdlZW4gbmV0d29yayBkb21haW4gYW5kIHNlcnZpY2UgZG9tYWluKWluIHRo ZSBuZXR3b3JrLg0KVGhlIHBlcmZvcm1hbmNlIE1ldHJpY3MgcmVwb3J0ZWQgZnJvbSB0aGUgUlRQ IG1vbml0b3IgY2FuIGJlIGRpdmlkZWQgaW50byBlbmQgc3lzdGVtIA0KbWV0cmljcywgYXBwbGlj YXRpb24gbGV2ZWwgbWV0cmljcywgdHJhbnNwb3J0IGxldmVsIG1ldHJpY3MuIFNvbWUgb2YgdGhl c2UgbWV0cmljcyANCm1heSBiZSBzcGVjaWZpYyB0byB0aGUgbWVhc3VyZW1lbnQgcG9pbnQgb2Yg dGhlIFJUUCBtb25pdG9yIG9yIGRlcGVuZCBvbiB3aGVyZSANCnRoZSBSVFAgbW9uaXRvcnMgYXJl IGxvY2F0ZWQgaW4gdGhlIG5ldHdvcmsuIEZvciBpbnN0YW5jZSwgZW5kIHN5c3RlbSBtZXRyaWNz IGFyZSBvbmx5DQogYXZhaWxhYmxlIG9yIG1lYXN1cmVkIGF0IHRoZSBSVFAgZW5kIHN5c3RlbSBv ciB0ZXJtaW5hbCBkZXZpY2UuIEFwcGxpY2F0aW9uIGxldmVsDQogbWV0cmljcyB0aGF0IHJlZmxl Y3QgZW5kIHRvIGVuZCB1c2VyIGV4cGVyaWVuY2UgYXQgdGhlIGFwcGxpY2F0aW9uLWxldmVsIGFy ZSBtZWFzdXJlZCANCm1vcmUgcHJlY2lzZSBvciBsZXNzIGNvbXBsaWNhdGVkIGF0IHRoZSBSVFAg ZW5kIHN5c3RlbSB0aGFuIG1lYXN1cmVkIGZyb20gaW50ZXJtZWRpYXJ5IA0Kc3lzdGVtIChlLmcu LCB0aGUgUlRQIG1lZGlhIHRyYW5zbGF0b3IpIGluIHRoZSBuZXdvcmsuIEZvciB0cmFuc3BvcnQg bGV2ZWwgbWV0cmljcywgdGFrZXMNCiBvbmUgd2F5IGRlbGF5IGFzIGFuIGV4YW1wbGUsIGluIHRo ZSBhc3ltbWV0cmljIG5ldHdvcmssIHRoZSBvbmUgd2F5IGRlbGF5IG1lYXN1cmVkIA0KYXQgdGhl IFJUUCBzZW5kZXIgZW50aXR5IGlzIGRpZmZlcmVudCBmcm9tIG9uZSB3YXkgZGVsYXkgbWVhc3Vy ZWQgYXQgdGhlIFJUUCANCnJlY2VpdmVyIGVudGl0eS4gDQoiDQoNClJlZ2FyZHMhDQotUWluDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNvbGluIFBlcmtpbnMiIDxjc3BA Y3NwZXJraW5zLm9yZz4NClRvOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPg0KQ2M6ICJB bGJyZWNodCBTY2h3YXJ6IiA8YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPjsgPGF2dEBpZXRmLm9y Zz4NClNlbnQ6IFR1ZXNkYXksIE1heSAyMiwgMjAxMiA3OjA0IFBNDQpTdWJqZWN0OiBSZTogW0FW VENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0x Mw0KDQoNCkkgYWxzbyBkb24ndCBhZ3JlZSB3aXRoIGRlbGV0aW5nIFNlY3Rpb24gMy4zIGZyb20g dGhlIG1vbmFyY2ggZHJhZnQuIA0KDQpUaGUgYXJjaGl0ZWN0dXJlIG5lZWRzIHRvIGJlIGNsZWFy IHRoYXQgdGhlcmUgYXJlIHZhbGlkIHNjZW5hcmlvcyBmb3IgUlRQIG1vbml0b3Jpbmcgd2l0aGlu IGEgbmV0d29yaywgZWl0aGVyIGluIHNvbWUgbWlkZGxlYm94IHRoYXQgY29tcHJpc2VzIHBhcnQg b2YgYW4gUlRQIHNlc3Npb24sIG9yIGluIGEgdGhpcmQtcGFydHkgbW9uaXRvcmluZyBkZXZpY2Ug dXNlZCBmb3IgbmV0d29yayBtYW5hZ2VtZW50IHB1cnBvc2VzLiBTZWN0aW9uIDMuMyBpcyBhIHJl YXNvbmFibGUgcGxhY2UgdG8gZGlzY3VzcyB0aGVzZSwgYW5kIHRvIGV4cGxhaW4gd2h5IHRoZSBt ZXRyaWNzIHRoYXQgY2FuIGJlIHJlcG9ydGVkIGZyb20gbWlkZGxlYm94ZXMgYXJlIGRpZmZlcmVu dCB0byB0aG9zZSB0aGF0IGNhbiBiZSBjYXB0dXJlZCBhdCBlbmQgc3lzdGVtcy4NCg0KQ29saW4N Cg0KDQoNCk9uIDIyIE1heSAyMDEyLCBhdCAwNzo1MywgUWluIFd1IHdyb3RlOg0KPiBIaSw6DQo+ IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206ICJBbGJyZWNodCBTY2h3YXJ6 IiA8YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPg0KPiBUbzogPGJpbGwud3VAaHVhd2VpLmNvbT4N Cj4gQ2M6IDxhdnRAaWV0Zi5vcmc+OyA8cmpzcGFya3NAbm9zdHJ1bS5jb20+DQo+IFNlbnQ6IFR1 ZXNkYXksIE1heSAyMiwgMjAxMiAxMToxOCBBTQ0KPiBTdWJqZWN0OiBSZTogW0FWVENPUkVdIFN1 YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMw0KPiANCj4g DQo+IERlYXIgQWxsLA0KPiANCj4gY29uY2VybmluZyB0aGUgcmVzb2x1dGlvbiBwcm9wb3NhbCBm b3IgY2xhdXNlIDMuMzoNCj4gSSBkb24ndCBhZ3JlZSBpbiBqdXN0IGRlbGV0aW5nIGFnYWluIHRo YXQgc2VjdGlvbiENCj4gVGhlcmUgd2FzIHF1aXRlIGEgbG9uZyBkZWJhdGUgZm9yIGluY29ycG9y YXRpbmcgc3VjaCBhIGNsYXVzZS4NCj4gVGhlIG9yaWdpbmFsIHRleHQgcHJvcG9zYWwgd2FzIG11 Y2ggbW9yZSBkZXRhaWxlZC4gUGVyaGFwcyB0aGUgc2hvcnRlbmluZyB0byBqdXN0IGEgc2luZ2xl IHBhcmFncmFwaCBpcyB0aGUgbWFpbiBjYXVzZSBmb3IgdW5jbGFyaXR5Lg0KPiBUaHVzLCBpbnN0 ZWFkIG9mIHJlbW92aW5nIHByZXZpb3VzIGFncmVlZCB0ZXh0LCB3ZSBqdXN0IHJhdGhlciBleHRl bmQgaXQgYWdhaW4uDQo+IA0KPiANCj4gW1Fpbl06IA0KPiBUaGUgcmVhc29uIEkgcHJvcG9zZSB0 byByZW1vdmUgdGhlIHNlY3Rpb24gMy4zIGlzIA0KPiBhLiBJIHRoaW5rIFJvYmVydCBpcyBjb3Jy ZWN0LiBUaGUgc2V0IG9mIG1lYW5pbmdmdWwgbWV0cmljcyBpc24ndCBjaGFuZ2VkIGF0IGFsbCAg d2hlcmV2ZXIgeW91IGNvbGxlY3QgdGhlbS4gSXQgc2VlbXMgbGl0dGxlIHNlbnNlIA0KPiAgICB0 byBzYXkgInRoZSBsb2NhdGlvbiBvZiB0aGUgUlRQIFNlbmRlci9SZWNlaXZlciBlbnRpdGllcyBt YXkgaW1wYWN0IGEgc2V0IG9mIG1lYW5pbmdmdWwgbWV0cmljcy4gIiANCj4gYi4gV2hlcmUgdG8g Z2F0aGVyIG9yIG1lYXN1cmUgbWV0cmljcyBjYW4gYmUgaW5kaWNhdGVkIGJ5IHRoZSBkZWZpbml0 aW9uIG9mIFRyYW5zcG9ydCBtZXRyaWNzLCBFbmQgc3lzdGVtIG1ldHJpY3MgYW5kIGFwcGxpY2F0 aW9uIGxldmVsIG1ldHJpY3MuDQo+IGMuIFNlY3Rpb24gMy4zIHNlZW1zIHRvIGRpc2N1c3Mgd2hl cmUgdG8gZ2F0aGVyIHdoYXQgbWV0cmljcy4gUmVjb21tZW5kYXRpb24gSVRVLVQgRy4xMDgxIGhh dmUgYWxyZWFkeSBkZWZpbmVkIGZpdmUgbW9uaXRvcmluZyBwb2ludHMgDQo+ICAgIHdoZXJlIHRo ZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMgY2FuIGJlIG1hZGUuDQo+IA0KPj4gSSB0aGluayB0 aGUgZGVmaW5pdGlvbiBvZiBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGhhcyBhbHJlYWR5IGNs YXJpZmllZCB0aGF0ICBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGlzIG5vcm1hbGx5IGdhdGhl cmVkIGZyb20gdXNlciBlbmRwb2ludC4gDQo+IA0KPiBOby4gV2UgZGlkIGRpc2N1c3MgdGhpcyBh bHJlYWR5IGV4dGVuc2l2ZWx5Lg0KPiBBbiBSVFAgbWVkaWEgdHJhbnNsYXRvciBjb3VsZCBwcm92 aWRlIGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgYmVjYXVzZSBlLmcuIHRlcm1pbmF0aW5nIHRo ZSBhcHBsaWNhdGlvbiBwcm90b2NvbCBsYXllci4NCj4gU3VjaCBhbiBSVFAgdG9wb2xvZ3kgaXMg Tk9UIGxvY2F0ZWQgaW4gYW4gdXNlciBlbmRwb2ludCENCj4gDQo+IFtRaW5dOiBTb3JyeSwgSSBz aG91bGQgY29ycmVjdCBtZSB0byBzYXkgUW9FIG1ldHJpYyBpcyB1c3VzYWxseSBtZWFzdXJlZCBh dCB0aGUgdXNlciBlbmRwb2ludC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEFsYnJlY2h0DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFtEYXRlIFByZXZdW0RhdGUgTmV4dF1bVGhy ZWFkIFByZXZdW1RocmVhZCBOZXh0XVtEYXRlIEluZGV4XVtUaHJlYWQgSW5kZXhdIA0KPiBSZTog W0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJj aC0xMw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gKiBUbzogUm9i ZXJ0IFNwYXJrcyA8cmpzcGFya3MgYXQgbm9zdHJ1bS5jb20+LCBJRVRGIEFWVENvcmUgV0cgPGF2 dCBhdCBpZXRmLm9yZz4sIDxkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhdCB0b29scy5pZXRm Lm9yZz4NCj4gKiBTdWJqZWN0OiBSZTogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBk cmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMw0KPiAqIEZyb206IFFpbiBXdSA8YmlsbC53dSBh dCBodWF3ZWkuY29tPg0KPiAqIERhdGU6IEZyaSwgMTggTWF5IDIwMTIgMTg6Mzc6NTYgKzA4MDAN Cj4gKiBEZWxpdmVyZWQtdG86IGF2dCBhdCBpZXRmYS5hbXNsLmNvbQ0KPiAqIExpc3QtYXJjaGl2 ZTogPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hdnQ+DQo+ICogTGlzdC1o ZWxwOiA8bWFpbHRvOmF2dC1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4NCj4gKiBMaXN0 LWlkOiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZSA8YXZ0LmlldGYub3Jn Pg0KPiAqIExpc3QtcG9zdDogPG1haWx0bzphdnRAaWV0Zi5vcmc+DQo+ICogTGlzdC1zdWJzY3Jp YmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dD4sIDxtYWlsdG86 YXZ0LXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+DQo+ICogTGlzdC11bnN1YnNj cmliZTogPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vb3B0aW9ucy9hdnQ+LCA8bWFpbHRv OmF2dC1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU+DQo+ICogUmVmZXJlbmNl czogPDRGQjJFMzIzLjMwOTA0MDYgYXQgbm9zdHJ1bS5jb20+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IA0KPiBIaSxSb2JlcnQ6DQo+IFRoYW5rIGZvciB5b3VyIHZhbHVh YmxlIHJldmlldy4gcGxlYXNlIHNlZSBteSByZXBsaWVzIGlubGluZSBiZWxvd3MuIFJlZ2FyZHMh DQo+IC1RaW4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gRnJvbTogIlJvYmVy dCBTcGFya3MiIDxyanNwYXJrcyBhdCBub3N0cnVtLmNvbT4NCj4gVG86ICJJRVRGIEFWVENvcmUg V0ciIDxhdnQgYXQgaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2ggYXQgdG9v bHMuaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDEyIDc6MTMgQU0NCj4g U3ViamVjdDogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNv cmUtbW9uYXJjaC0xMyA+IFN1bW1hcnk6IFRoZXJlIGFyZSBpc3N1ZXMgdG8gcmVzb2x2ZSB3aXRo IGEgcmV2aXNlZCBJRCBiZWZvcmUgDQo+PiBwcm9ncmVzc2luZyB0byBJRVRGIExDLg0KPj4gDQo+ PiBJdCdzIGEgc3RydWdnbGUgdG8gc2VlIHRoZSBfYXJjaGl0ZWN0dXJlXyB0aGlzIGRvY3VtZW50 IGlzIHN1cHBvc2VkIHRvIA0KPj4gZGVzY3JpYmUuIEkgc3VzcGVjdCBtb3N0IG9mIHRoZSB3b3Jr aW5nIGdyb3VwIGVuZXJneSB3ZW50IGludG8gU2VjdGlvbiA1IA0KPj4gKHRoZSBndWlkZWxpbmVz IGZvciB3cml0aW5nIFhSIGJsb2NrIGRlZmluaXRpb25zKSAtIHRoZSByZXN0IG9mIHRoZSANCj4+ IGRvY3VtZW50IG5lZWRzIGEgc2ltaWxhciBsZXZlbCBvZiBhdHRlbnRpb24gdG8gZGV0YWlsLg0K Pj4gDQo+PiBUaGVyZSBhcmUgdHdvIG1ham9yIGlzc3VlcyB0aGF0IEkndmUgdGFnZ2VkIHdpdGgg YSAoKikuIEkgZm9sbG93ZWQgYSANCj4+IG1vc3RseSBkb2N1bWVudC1vcmRlciBmbG93IGluc3Rl YWQgb2YgZ3JvdXBpbmcgdGhlIG1ham9yIGlzc3VlcyBhdCB0aGUgdG9wLg0KPj4gDQo+PiAoKikg R2l2ZW4gdGhlIGRvY3VtZW50J3MgdGl0bGUsIGl0IHNob3VsZCBiZSB2ZXJ5IGVhc3kgdG8gYW5z d2VyICJXaGF0IA0KPj4gaXMgdGhlIG1vbml0b3JpbmcgYXJjaGl0ZWN0dXJlPyIgZm9yIHBlb3Bs ZSB3aG8gYXJlIHJlYWRpbmcgdGhpcyBkcmFmdCANCj4+IGZvciB0aGUgZmlyc3QgdGltZS4NCj4+ IFRoZSBrZXkgbWVzc2FnZSBpcyB0aGF0IHRoZSBtb25pdG9yaW5nIGFyY2hpdGVjdHVyZSBjb25z aXN0cyBvZiBNb25pdG9ycyANCj4+IHRoYXQgZXhjaGFuZ2UgaW5mb3JtYXRpb24gdXNpbmcgUlRD UCBNZXRyaWMgQmxvY2tzLiBbUWluXTogQWdyZWUuID5UaGUgdGV4dCBzaG91bGQgc2F5IA0KPj4g dGhhdC4gW1Fpbl06IE9rYXkuID4gVGhlcmUgaXMgYSBsb3Qgb2YgcHJvc2UgaW4gc2VjdGlvbiAz IGFuZCB2aXN1YWwgZGV0YWlsIGluIHRoZSANCj4+IGRpYWdyYW0gaW4gRmlndXJlIDEgdGhhdCBt YWtlcyB0aGF0IGV4dHJlbWVseSBkaWZmaWN1bHQgdG8gc2VlLiANCj4+IFNpbXBsaWZ5aW5nIHRo ZSBmaWd1cmUgYnkgcmVtb3ZpbmcgdGhlIGRldGFpbHMgYWJvdXQgYXBwbGljYXRpb25zIGFuZCAN Cj4+IHRyYW5zcG9ydHMsIG9yIGF0IGxlYXN0IG1vdmluZyB0aGVtIHRvIGEgc2Vjb25kIGZpZ3Vy ZSwgbWFraW5nIHRoZSANCj4+IE1vbml0b3IgYm94ZXMgc3RhbmQgb3V0LCBhbmQgbWFraW5nIHRo ZSB0eXBlcyBvZiBpbmZvcm1hdGlvbiBmbG93cyAodGhlIA0KPj4gYXJyb3dzKSB2aXN1YWxseSBk aXN0aW5jdGl2ZSB3b3VsZCBoZWxwLiBTaW1wbGlmeSB0aGUgcHJvc2UgKG11Y2ggb2YgaXQgDQo+ PiBjb3VsZCBiZSByZW1vdmVkKSB0byBmb2N1cyBvbiB0aGF0IGtleSBtZXNzYWdlLiBbUWluXTog QWdyZWUsIEkgcHJvcG9zZSB0byByZW1vdmUgdGhlIGZpZ3VyZSAxIGFuZCBzcXVlZXplIHRoZSBz ZWN0aW9uIDMuMSBhcyBmb2xsb3dzOiAiIDMuMS4gT3ZlcnZpZXcgVGhlIFJUUCBtb25pdG9yaW5n IGFyY2hpdGVjdHVyZSBjb21wcmlzZXMgdGhlIGZvbGxvd2luZyB0d28ga2V5IGZ1bmN0aW9uYWwg Y29tcG9uZW50cyBzaG93biBiZWxvdzogbyBSVFAgTW9uaXRvciBvIFJUUCBNZXRyaWMgQmxvY2sg U3RydWN0dXJlIFJUUCBNb25pdG9yIGlzIHRoZSBmdW5jdGlvbmFsIGNvbXBvbmVudCBkZWZpbmVk IGluIHRoZSBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIFtSRkMzNTUwXS4gSXQgYWN0cyBh cyBhIHNvdXJjZSBvZiBpbmZvcm1hdGlvbiBnYXRoZXJlZCBmb3IgbW9uaXRvcmluZyBwdXJwb3Nl cyBhbmQgZXhjaGFuZ2VzIGluZm9ybWF0aW9uIHdpdGggdGhlIG90aGVyIFJUUCBtb25pdG9ycyB1 c2luZyBSVENQIE1ldHJpYyBCbG9ja3MuIEFjY29yZGluZyB0byB0aGUgZGVmaW5pdGlvbiBvZiBt b25pdG9yIGluIHRoZSBSVFAgUHJvdG9jb2wgW1JGQzM1NTBdLCB0aGUgZW5kIHN5c3RlbSB0aGF0 IHJ1bnMgYW4gYXBwbGljYXRpb24gcHJvZ3JhbSB0aGF0IHNlbmRzIG9yIHJlY2VpdmVzIFJUUCBk YXRhIHBhY2tldHMsIGFuIGludGVybWVkaWF0ZS0gc3lzdGVtIHRoYXQgZm9yd2FyZHMgUlRQIHBh Y2tldHMgdG8gRW5kLWRldmljZXMgb3IgYSB0aGlyZCBwYXJ0eSB0aGF0IG9ic2VydmVzIHRoZSBS VFAgYW5kIFJUQ1AgdHJhZmZpYyBidXQgZG9lcyBub3QgbWFrZSBpdHNlbGYgdmlzaWJsZSB0byB0 aGUgUlRQIFNlc3Npb24gcGFydGljaXBhbnRzIChpLmUuLCB0aGUgdGhpcmQgcGFydHkgbW9uaXRv ciBkZXBpY3RlZCBpbiBmaWd1cmUgMSkgY2FuIGFjdCBhcyB0aGUNCj4gUlRQIG1vbml0b3IuIFRo ZSB0aGlyZCBwYXJ0eSBtb25pdG9yIHNob3VsZCBiZSBwbGFjZWQgb24gdGhlIFJUUC9SVENQIHBh dGhzIGJldHdlZW4gdGhlIHNlbmRlciwgaW50ZXJtZWRpYXRlIGFuZCB0aGUgcmVjZWl2ZXIuIFRo ZSBSVFAgbW9uaXRvciBhbHNvIGV4cG9zZXMgcmVhbCB0aW1lIEFwcGxpY2F0aW9uIFFvUy9Rb0Ug bWV0cmljIGluZm9ybWF0aW9uIGluIHRoZSBhcHByb3ByaWF0ZSByZXBvcnQgYmxvY2sgZm9ybWF0 IChlLmcuLFJUQ1AgWFIgb3Igb3RoZSBub24tUlRQIG1lYW5zKSB0byB0aGUgbWFuYWdlbWVudCBz eXN0ZW0uIFN1Y2ggaW5mb3JtYXRpb24gY2FuIGJlIGZvcm11bGF0ZWQgYXMgZGlmZmVyZW50IG1l dHJpYyB0eXBlcywgZS5nLixhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWMsIHRyYW5zcG9ydCBsZXZl bCBtZXRyaWMsIGVuZCBzeXN0ZW0gbWV0cmljLCBpbnRlcnZhbCBtZXRyaWMsIGN1bXVsYXRpdmUg bWV0cmljLCBzYW1wbGVkIG1ldHJpYywgZGlyZWN0IG1ldHJpYywgY29tcG9zZWQgbWV0cmljLGV0 Yy4gQm90aCB0aGUgUlRDUCBvciBSVENQIFhSIGNhbiBiZSBleHRlbmRlZCB0byBjb252ZXkgdGhl c2UgbWV0cmljcy4gVGhlIGRldGFpbHMgb24gdHJhbnNwb3J0IHByb3RvY29scyBmb3IgdGhlc2Ug bWV0cmljIGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuIFJUUCBtYXkgYmUgdXNlZCB0byBt dWx0aWNhc3QgZ3JvdXBzLCBib3RoIEFueSBTb3VyY2UgTXVsdGljYXN0IChBU00pIGFuZCBTb3Vy Y2UgU3BlY2lmaWMgTXVsdGljYXN0IChTU00pLiBUaGVzZSBncm91cHMgY2FuIGJlIG1vbml0b3Jl ZCB1c2luZyBSVENQLiBJbiB0aGUgQVNNIGNhc2UsIHRoZSBtb25pdG9yIGlzIGEgbWVtYmVyIG9m IHRoZSBtdWx0aWNhc3QgZ3JvdXAgYW5kIGxpc3RlbnMgdG8gUlRDUCBYUiByZXBvcnRzIGZyb20g YWxsIG1lbWJlcnMgb2YgdGhlIEFTTQ0KPiBncm91cC4gSW4gdGhlIFNTTSBjYXNlLCB0aGVyZSBp cyBhIHVuaWNhc3QgZmVlZGJhY2sgdGFyZ2V0IHRoYXQgcmVjZWl2ZXMgUlRDUCBmZWVkYmFjayBm cm9tIHJlY2VpdmVycyBhbmQgZGlzdHJpYnV0ZXMgaXQgdG8gb3RoZXIgbWVtYmVycyBvZiB0aGUg U1NNIGdyb3VwIChzZWUgZmlndXJlIDEgb2YgUkZDNTc2MCkuIFRoZSBtb25pdG9yIHdpbGwgbmVl ZCB0byBiZSBjby1sb2NhdGVkIHdpdGggdGhlIGZlZWRiYWNrIHRhcmdldCB0byByZWNlaXZlIGFs bCBmZWVkYmFjayBmcm9tIHRoZSByZWNlaXZlcnMgKHRoaXMgbWF5IGFsc28gYmUgYW4gaW50ZXJt ZWRpYXRlIHN5c3RlbSkuIEluIGJvdGggQVNNIGFuZCBTU00gc2NlbmFyaW9zLCByZWNlaXZlcnMg Y2FuIHNlbmQgUlRDUCBYUiByZXBvcnRzIHRvIGVuaGFuY2UgdGhlIHJlY2VwdGlvbiBxdWFsaXR5 IHJlcG9ydGluZy4gIiA+IEluIHRoZSBkZWZpbml0aW9uIG9mIENvbXBvc2VkIG1ldHJpY3MsIHRo ZSBzZW50ZW5jZSAiQW4gZXhhbXBsZSBpcyBhIA0KPj4gbWV0cmljIGNhbGN1bGF0ZWQgYmFzZWQg b24gZGVyaXZlZCBtZXRyaWNzIHRoYXQgaGF2ZSBiZWVuIG1lYXN1cmVkLiIgDQo+PiBtYWtlcyBs aXR0bGUgc2Vuc2UuIFtRaW5dIFRoZSBkZXJpdmVkIG1ldHJpY3MgaW4gdGhlIHNlbnRlbmNlIHNo b3VsZCBiZWVuIGNvcnJlY3RlZCBhcyAiZGlyZWN0IG1ldHJpYyIuID5EaWQgeW91IG1lYW4gc29t ZXRoaW5nIGxpa2UgIkFuIGV4YW1wbGUgaXMgYSBtZXRyaWMgDQo+PiBkZXJpdmVkIGJ5IGFsZ29y aXRobWljYWxseSBjb21iaW5pbmcgbWVhc3VyZWQgbWV0cmljcy4iPyBbUWluXTpJIGFncmVlIHdp dGggeW91ciBzdWdnZXN0ZWQgdGV4dCBhbmQgbGlrZSB0byBhZG9wdCB5b3VyIHN1Z2dlc3Rpb24u ID4gVGhlIGRlZmluaXRpb25zIG9mIEludGVydmFsLCBDdW11bGF0aXZlLCBhbmQgU2FtcGxlZCBt ZXRyaWNzIGFyZSBub3QgY2xlYXIuIFtRaW5dOiBJIGFncmVlIHRoZSBkZWZpbml0aW9uIGZvciB0 aGVzZSB0aHJlZSBtZXRyaWNzIG5lZWQgdG8gYmUgbW9yZSBjbGVhZXIsIEkgcHJvcG9zZXMgdG8g ZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2VzOiBORVcgVGV4dDogIiBJbnRlcnZhbCBtZXRyaWNzIE1l dHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVkIHZhbHVlcyBhcmUgbWVhc3VyZWQgaW4gdGhlIG1v c3QgcmVjZW50IG1lYXN1cmVtZW50IGludGVydmFsIGR1cmF0aW9uIGJldHdlZW4gc3VjY2Vzc2l2 ZSBtZXRyaWNzIHJlcG9ydHMuIFN1Y2ggbWVhc3VyZW1lbnQgaW50ZXJ2YWwgaXMgZXF1YWwgdG8g b25lIFJUQ1AgcmVwb3J0IGludGVydmFsIChSRkMzNTUwLFNlY3Rpb24gNi4yKS4gQ3VtdWxhdGl2 ZSBtZXRyaWNzIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVkIHZhbHVlcyBhcHBseSB0byB0 aGUgYWNjdW11bGF0aW9uIHBlcmlvZCBjaGFyYWN0ZXJpc3RpYyBvZiBjdW11bGF0aXZlIG1lYXN1 cmVtZW50cy4gVGhlIHJlcG9ydGVkIHZhbHVlcyBhcmUgbWVhc3VyZWQgZHVyaW5nIHRoZSBhY2N1 bXVsYXRpb24gcGVyaW9kLiBUaGUgYWNjdW11bGF0aW9uIHBlcmlvZCBzcGFucyBvdmVyIG1vcmUg dGhhbiBvbmUgUlRDUCByZXBvcnQgaW50ZXJ2YWxzLiBTYW1wbGVkIG1ldHJpY3MgTWV0cmljcyBv ZiB3aGljaCB0aGUgcmVwb3J0ZWQgdmFsdWVzIG9ubHkgYXBwbHkgdG8gdGhlIHZhbHVlIG9mIGEg Y29udGludW91c2x5IG1lYXN1cmVkIG9yDQo+IGNhbGN1bGF0ZWQgbWV0cmljIHRoYXQgaGFzIGJl ZW4gc2FtcGxlZCBhdCBhbnkgZ2l2ZW4gaW5zdGFuY2Ugb2YgdGhlIFJUQ1AgcmVwb3J0IGludGVy dmFsLiBPbmUgZXhhbXBsZSBvZiBzdWNoIG1ldHJpYyBpcyB0aGUgaW50ZXItYXJyaXZhbCBqaXR0 ZXIgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIDYuNC4xIG9mIFJGQzM1NTAuICIgPiBJZiB0aGUg ZGlzY3Vzc2lvbiBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gMy4xIGlzIGtlcHQsIHRoZSByZWZlcmVu Y2UgdG8gDQo+PiBSRkM1NzYwIHNob3VsZCBiZSBhIHJlYWwgcmVmZXJlbmNlLCBhbmQgUkZDNTc2 MCBzaG91bGQgYXBwZWFyIGluIHRoZSANCj4+IHJlZmVyZW5jZSBzZWN0aW9uLiBbUWluXTogT2th eS4gPiBUaGUgcG9pbnQgb2Ygc2VjdGlvbiAzLjIgaXMgbm90IG9idmlvdXMuIEhvdyBkb2VzIGl0 IGNvbnRyaWJ1dGUgdG8gdGhlIA0KPj4gZGVzY3JpcHRpb24gb2YgdGhlIGFyY2hpdGVjdHVyZS4g SXQgbWl4ZXMgdGFsa2luZyBhYm91dCB3aGF0IHJlcG9ydCANCj4+IGJsb2NrcyBhcmUgd2l0aCBv Y2Nhc2lvbmFsbHkgbmVlZGluZyB0byBzZW5kIHRoZW0gbW9yZSBmcmVxdWVudGx5LiBUaG9zZSAN Cj4+IHBvaW50cyBjb3VsZCBiZSBtYWRlIHNlcGFyYXRlbHkgYW5kIG1vcmUgc2ltcGx5LiBbUWlu XTogT2theS4gSSBsaWtlIHRvIGluY29ycG9yYXRlIHRoZSBrZXkgcG9pbnRzIGluIHRoZSBzZWN0 aW9uIDMuMiBpbnRvIHNlY3Rpb24gMy4xID4gU2VjdGlvbiAzLjMgaXMgbm90IGNsZWFyIC0gaXQg c3RhcnRzIG9mZiBzYXlpbmcgdGhhdCB0aGUgbG9jYXRpb24gb2YgdGhlIA0KPj4gc2VuZGVyIGFu ZCByZWNlaXZlciBtYXkgY2hhbmdlIHdoYXQgbWV0cmljcyBhcmUgbWVhbmluZ2Z1bC4gSXQncyBu b3QgDQo+PiBjbGVhciB3aGF0IHlvdSBtZWFuIGJ5IGxvY2F0aW9uLiBZb3UgY2VydGFpbmx5IGRv bid0IG1lYW4gZ2Vvc3BhdGlhbCANCj4+IGNvb3JkaW5hdGVzLiBEbyB5b3UgbWVhbiBhbnl0aGlu ZyBvdGhlciB0aGFuIHdoZXRoZXIgdGhlIGVsZW1lbnQgaXMgDQo+PiB0cnVzdGVkIG9yIHVudHJ1 c3RlZCBieSB0aGUgb3BlcmF0aW9ucyBuZXR3b3JrPyBJZiBzbywgc2F5IHRoYXQuIFRoZSANCj4+ IHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBvbmx5IHNwZWFrcyB0byB3aGF0IGVsZW1lbnQgY29sbGVj dHMgdGhlIG1ldHJpY3MuIFtRaW5dIFNlY3Rpb24gMy4zIGlzIG9ubHkgdXNlZCB0byBkZXNjcmli ZSB3aGVyZSBvciBmcm9tIHdoaWNoIFJUUCBlbnRpdHkgdG8gZ2F0aGVyIHRoZSBtZXRyaWNzIChp LmUuLCBtZWFzdXJlbWVudCBwb2ludCkgaW4gdGhlIHBoeXNpY2FsIG5ldHdvcmsgYW5kIGlzIG5v dCBmb2N1cyBvZiB0aGlzIGRvY3VtZW50LiBTZWNvbmRseSwgSSB0aGluayB0aGUgZGVmaW5pdGlv biBvZiBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGhhcyBhbHJlYWR5IGNsYXJpZmllZCB0aGF0 IGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgaXMgbm9ybWFsbHkgZ2F0aGVyZWQgZnJvbSB1c2Vy IGVuZHBvaW50LiA+IEl0J3Mgbm90IGNsZWFyIHRoYXQgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1l dHJpY3MgaXMgY2hhbmdlZCBhdCBhbGwgLSANCj4+IGp1c3Qgd2hlcmUgeW91IGNvbGxlY3QgdGhl bS4gSWYgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MgZG9lcyBpbiANCj4+IGZhY3QgY2hh bmdlLCB0aGVyZSBuZWVkcyB0byBiZSBhZGRpdGlvbmFsIGRpc2N1c3Npb24gaGVyZS4gW1Fpbl06 IFRoZSBtZXRyaWNzIGFjdHVhbGx5IGRvZXNuJ3QgY2hhbmdlLlNpbmNlIHRoZSBkZWZpbml0aW9u IG9mIGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgSGF2ZSBhbHJlYWR5IGNvbnZleWVkIHRoZSBt ZWFuaW5nIG9mIHdoYXQgc2VjdGlvbiAzLjMgd2FudHMgdG8gZGVzY3JpYmUsIEkgcHJvcG9zZSB0 byByZW1vdmUgdGhpcyBzZWN0aW9uLiA+IFNlY3Rpb24gNCdzIGZpcnN0IHBhcmFncmFwaDogSXMg InByb2JhYmx5IiB0aGUgYmVzdCB0aGUgd29ya2luZyBncm91cCANCj4+IGNhbiBzYXk/IFtRaW5d Ok5vLCB3aWxsIHJlbW92ZSB0aGlzIHdvcmQuID4gVGhlIGxhc3QgdHdvIHNlbnRlbmNlcyBvZiB0 aGUgc2Vjb25kIGJ1bGxldCBpbiBzZWN0aW9uIDQgZG8gbm90IHBhcnNlLiANCj4+IFBsZWFzZSBz aW1wbGlmeSB0aGVtLiBbUWluXTogT2theSwgaG93IGFib3V0IGNoYW5nZSB0aGVtIGFzIGZvbGxv d3M6IE5FVyBUZXh0OiAiIFdpdGggdGhlc2UgbWluaW1hbCBudW1iZXIgb2YgUlRDUCBzdGF0aXN0 aWNzIHBhcmFtZXRlcnMgbWFwcGVkIHRvIG5vbi1SVENQIG1lYXN1cmVtZW50cywgaXQgaXMgaGFy ZCB0byBwcm92aWRlIGFjY3VyYXRlIG1lYXN1cmVzIG9mIHJlYWwgdGltZSBhcHBsaWNhdGlvbiBx dWFsaXR5LGNvbmR1Y3QgZGV0YWlsZWQgZGF0YSBhbmFseXNpcyBhbmQgY3JlYXRlcyBhbGVydHMg dGltbHkgdG8gdGhlIHVzZXJzLiBUaGVyZWZvcmUgY29ycmVsYXRpb24gYmV0d2VlbiBSVENQIFhS IGFuZCBub24tUlRQIGRhdGEgc2hvdWxkIGJlIHByb3ZpZGVkLiAiID4gVGhlIGZpcnN0IGZ1bGwg c2VudGVuY2Ugb2YgdGhlIHRoaXJkIGJ1bGxldCBpbiBzZWN0aW9uIDQgZG9lcyBub3QgbWFrZSAN Cj4+IHNlbnNlLiBUaGUgd2hvbGUgYnVsbGV0IGNvdWxkIGJlIGNsYXJpZmllZC4gW1Fpbl06IEFn cmVlIGFuZCB3aWxsIHJlbW92ZSB0aGUgZmlyc3Qgc2VudGVuY2UuID4gVGhlIGZvdXJ0aCBidWxs ZXQgaW4gc2VjdGlvbiA0IGFuZCBzZWN0aW9uIDUuNSBzaG91bGQgY2FsbCBvdXQgdGhhdCANCj4+ IFJGQzM2MTEgYWxyZWFkeSBzZXQgQmxvY2sgVHlwZSAyNTUgYXNpZGUgZm9yIGZ1dHVyZSBleHRl bnNpb25zLCANCj4+IGFudGljaXBhdGluZyB0aGUgcG90ZW50aWFsIG5lZWQgdG8gZXh0ZW5kIHRo ZSBibG9jayB0eXBlIHNwYWNlLiBbUWluXTogT2theSwgSG93IGFib3V0IHJldmlzaW5nIHRoZSBz ZWN0aW9uIDQsYnVsbGV0IDQgYXMgZm9sbG93czogIiBDb25zdW1wdGlvbiBvZiBYUiBibG9jayBj b2RlIHBvaW50cy4gVGhlIFJUQ1AgWFIgYmxvY2sgbmFtZXNwYWNlIGlzIGxpbWl0ZWQgYnkgdGhl IDgtYml0IGJsb2NrIHR5cGUgZmllbGQgaW4gdGhlIFJUQ1AgWFIgaGVhZGVyLiBTcGFjZSBleGhh dXN0aW9uIG1heSBiZSBhIGNvbmNlcm4gaW4gdGhlIGZ1dHVyZS4gQW50aWNpcGF0aW5nIHRoZSBw b3RlbnRpYWwgbmVlZCB0byBleHRlbmQgdGhlIGJsb2NrIHR5cGUgc3BhY2UsIGl0IGlzIG5vdGVk IGluIFtSRkMzNjExXSB0aGF0IEJsb2NrIFR5cGUgMjU1IGlzIHJlc2VydmVkIGZvciBmdXR1cmUg ZXh0ZW5zaW9ucywgIiA+IEluIHNlY3Rpb24gNSwgY29uc2lkZXIgbmFtaW5nIHRoZSBzdWJzZWN0 aW9ucyB3aXRoIHRoZSBhY3R1YWwgZ3VpZGVsaW5lIA0KPj4gaW5zdGVhZCBvZiB0aGUgcHJvYmxl bSB0aGUgZ3VpZGVsaW5lIGlzIHRyeWluZyB0byBhZGRyZXNzLg0KPj4gNS4xLiBNZXRyaWMgYmxv Y2tzIHNob3VsZCBjb250YWluIGEgc2luZ2xlIG1ldHJpYyBbUWluXTogSSBzdWdnZXN0IHRvIGNo YW5nZSBpdCBhcyAiQ29udGFpbiB0aGUgc2luZ2xlIG1ldHJpY3MgaW4gdGhlIG1ldHJpYyBibG9j ayIgPiA1LjIuIEluY2x1ZGUgdGhlIHBheWxvYWQgdHlwZSBhbmQgZm9ybWF0IHBhcmFtZXRlcnMg aW4gdGhlIG1ldHJpYyBibG9jayBbUWluXTogT2theS4gPiA1LjMuIFVzZSBSVENQIFNERVMgdG8g Y29ycmVsYXRlIFhSIHJlcG9ydHMgd2l0aCBub24tUlRQIGRhdGEgW1Fpbl06IE9rYXkuID4gNS40 LiBEb24ndCByZXBlYXQgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gYWNyb3NzIG1ldHJpYyBibG9j a3MNCj4+IA0KPiBbUWluXTogSXQgaXMgbm90IHBvc3NpYmxlIGNvbXBsZXRlbHkgdG8gYXZvaWQg bWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gcmVwZWF0aXRpb24uIGUuZy4sIGZvciBwYWNrZXQgbG9z cyByb2J1c3RuZXNzIGlmIHRoZSByZXBvcnQgYmxvY2tzIGZvciB0aGUgc2FtZSBpbnRlcnZhbCBz cGFuIG92ZXIgbW9yZSB0aGFuIG9uZSBSVENQIHBhY2tldCB0aGVuIGVhY2ggbXVzdCBoYXZlIHRo ZSBzYW1lIG1lYXN1cmVtZW50IGlkZW50aXR5IGluZm9ybWF0aW9uIFNvIEkgc3VnZ2VzdCB0byBj aGFuZ2UgaXQgYXM6ICJyZWR1Y2UgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gYWNyb3NzIG1ldHJp YyBibG9ja3MiID4gVGhpcyBwb2ludHMgb3V0IGEgc3RydWN0dXJhbCBwcm9ibGVtIHdpdGggdGhl IHNlY3Rpb24uIFdoeSBpcyA1LjUgaGVyZT8gDQo+PiBJdCdzIG5vdCBhIGd1aWRlbGluZS4gW1Fp bl06IEFncmVlIGFuZCBhbHNvIGFzIGRpc2N1c3NlZCxTcGFjZSBleGhhdXN0aW9uIGlzIG5vdCBi aWcgaXNzdWUuIEhvdyBhYm91dCByZW1vdmUgdGhpcyBzZWN0aW9uPyA+ICgqKSBBbmQgaXQgcmFp c2VzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUgZG9jdW1lbnQgaXMgdHJ5aW5nIHRvIA0KPj4g YWNoaWV2ZSB3aXRoIHNlY3Rpb24gNS40LiBUaGF0IHNlY3Rpb24gY2xhaW1zIHRoZSBkb2N1bWVu dCBpcyBwcm9wb3NpbmcgDQo+PiBhIG5ldyBYUiBibG9jayB0eXBlIHRvIGhlbHAgYXZvaWQgZHVw bGljYXRpb24sIGJ1dCBpdCBkb2Vzbid0IGFjdHVhbGx5IA0KPj4gZGVmaW5lIHRoZSBuZXcgYmxv Y2sgdHlwZS4gSXMgdGhlIGd1aWRlbGluZSBzYXlpbmcgc2ltcGx5IGRvbid0IHJlcGVhdCANCj4+ IG1lYXN1cmVtZW50cyBvciBpdHMgdGhlIGd1aWRlbGluZSBzYXlpbmcgInVzZSB0aGlzIG5ldyBY UiBibG9jayB0eXBlIHdlIA0KPj4gaGF2ZW4ndCBkZWZpbmVkIHlldCI/IFtRaW5dOiBKdXN0IHRv IGNsYXJpZnksIHdlIGhhdmUgYWxyZWFkeSBkZWZpbmVkIG9uZSBuZXcgWFIgQmxvY2sgdHlwZSB0 byBoZWxwIGF2b2lkIG9yIHJlZHVjZSBkdXBsaWNhdGlvbi4gSXQgaXMgbWVhc3VyZW1lbnQgaW5m b3JtYXRpb24gYmxvY2suIFRoZSByZWxldmFudCBkcmFmdCBpcyBhdmFpbGFibGUgYXQ6IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLW1lYXMtaWRl bnRpdHktMDYgPlRoZSBzZWN0aW9uIG5lZWRzIG1vcmUgY2xhcml0eS4gSWYgaXQgcmVhbGx5IGlz IA0KPj4gdHJ5aW5nIHRvIGRlZmluZSBhIG5ldyB0eXBlLCB0aGVyZSdzIG1vcmUgd29yayB0byBi ZSBkb25lLiBbUWluXTogSW4gb3JkZXIgdG8gYXZvaWQgc3VjaCBjb25mdXNpb24sIEkgcHJvcG9z ZWQgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIHNlY3Rpb24gNS40OiBPTEQgVGV4 dDogIiBUaGlzIG1lbW8gcHJvcG9zZXMgdG8gZGVmaW5lIGEgbmV3IFhSIEJsb2NrIHRoYXQgd2ls bCBiZSB1c2VkIHRvIGNvbnZleSB0aGUgY29tbW9uIHRpbWUgcGVyaW9kIGFuZCB0aGUgbnVtYmVy IG9mIHBhY2tldHMgc2VudCBkdXJpbmcgdGhpcyBwZXJpb2QuICIgTmV3IHRleHQ6ICIgVGhpcyBt ZW1vIHByb3Bvc2VzIHRvIGRlZmluZSBhIG5ldyBYUiBCbG9jayAoaS5lLiwgdGhlIE1lYXN1cmVt ZW50IGluZm9ybWF0aW9uIGJsb2NrW0kuRC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLWlkZW50 aXR5XSkgdGhhdCB3aWxsIGJlIHVzZWQgdG8gY29udmV5IHRoZSBjb21tb24gdGltZSBwZXJpb2Qg YW5kIHRoZSBudW1iZXIgb2YgcGFja2V0cyBzZW50IGR1cmluZyB0aGlzIHBlcmlvZC4gIiA+IFRo ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBwYXJ0aWN1bGFybHkgdGhlIHRoaXJk IHBhcmFncmFwaCwgDQo+PiBuZWVkcyB0byBiZSBjbGVhcmVyLiBXaGF0IGV4YWN0bHkgZG8geW91 IG1lYW4gYnkgIm1vbml0b3Jpbmcgc2hvdWxkIGJlIA0KPj4gcHJvaGliaXRlZCIsIGFuZCBob3cg aXMgdGhlIGZhY3QgdGhhdCB0aGlyZCBwYXJ0eSBtb25pdG9ycyBkb24ndCBzZW5kIA0KPj4gUlRD UCByZWxldmFudD8gRGlkIHlvdSBpbnRlbmQgdGhvc2UgdG8gYmUgc2VwYXJhdGUgcG9pbnRzPyBb UWluXTogWWVzLCB0aGV5IGFyZSBvbiB0aGUgZGlmZmVyZW50IHBvcnQuIFN1Y2ggbW9uaXRvciBt YXkgcmVjZWl2ZSBSVFAgcGFja2V0IGJ1dCBkb2VzIG5vdCBzZW5kIFJUQ1AgcGFja2V0LiA+IEVk aXRvcmlhbCBOaXRzIGFuZCBTdWdnZXN0aW9uczoNCj4+IA0KPj4gVGhlIGZpcnN0IHBhcmFncmFw aCBvZiB0aGUgaW50cm9kdWN0aW9uIGlzIG92ZXJseSBjb21wbGV4LCBhbmQgd29uJ3QgYWdlIA0K Pj4gd2VsbC4gSSBzdWdnZXN0IHJlcGxhY2luZyBpdCB3aXRoOiAiTXVsdGltZWRpYSBzZXJ2aWNl cyB1c2luZyB0aGUgDQo+PiBSZWFsLVRpbWUgUHJvdG9jb2wgKFJUUCkgYXJlIHNlZWluZyBpbmNy ZWFzZWQgdXNlLiBTdGFuZGFyZCBtZXRob2RzIGZvciANCj4+IGdhdGhlcmluZyBSVFAgcGVyZm9y bWFuY2UgbWV0cmljcyBmcm9tIHRoZXNlIGFwcGxpY2F0aW9ucyBhcmUgbmVlZGVkIHRvIA0KPj4g bWFuYWdlIHVuY2VydGFpbnRpZXMgaW4gdGhlIGJlaGF2aW9yIGFuZCBhdmFpbGFiaWxpdHkgb2Yg dGhlaXIgDQo+PiBzZXJ2aWNlcy4iIFRoZW4gcmVwbGFjZSAiVGhlc2UgcmFwaWRseSBlbWVyZ2lu ZyBzdGFuZGFyZHMsIiB3aXRoIA0KPj4gIlN0YW5kYXJkcyIuIFtRaW5dOiBPa2F5LiA+IEludHJv ZHVjdGlvbiBwYXJhZ3JhcGggMyBzZW50ZW5jZSAyIHNob3VsZCBzdGFydCAiVGhlIFJUQ1AgR3Vp ZGVsaW5lcyANCj4+IFtSRkM1OTY4XSIuIEl0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyIHRvIHVzZSB0 aGUgZnVsbCB0aXRsZSBmcm9tIDU5Njg6IA0KPj4gJ1RoZSAiR3VpZGVsaW5lcyBmb3IgRXh0ZW5k aW5nIHRoZSBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkiIFtSRkM1OTY4XScgW1Fpbl06IE9r YXkuID4gVGhpcyBtYXkgYmVjb21lIG1vb3QgYXMgc2VjdGlvbiAzIGlzIG1vZGlmaWVkIHRvIG1h a2UgaXRzIG1haW4gcG9pbnQgDQo+PiBtb3JlIG9idmlvdXMsIGJ1dCBSRkMzNTUwIGRvZXMgbm90 IGNoYXJhY3Rlcml6ZSBNb25pdG9ycyBhcyAiYSBzb3VyY2Ugb2YgDQo+PiBpbmZvcm1hdGlvbiIu IFRoYXQgY291bGQgYmUgbWlzdW5kZXJzdG9vZC4gUGxlYXNlIGNob29zZSBhbm90aGVyIHdvcmQu IA0KPj4gUGVyaGFwcyAicmVwb3NpdG9yeSI/IFtRaW5dOiBPa2F5LCByZXBvc2l0b3J5IGxvb2tz IGdvb2QgdG8gbWUuID4gSW4gYnVsbGV0IGxpc3RzLCBzdGFydGluZyBhbiBlbnRyeSB3aXRoICJv ciIgb3IgImFuZCIgaXMgdW5uZWNlc3NhcnkuIEl0IA0KPj4gc2hvdWxkIGJlIGNsZWFyIGZyb20g dGhlIGludHJvZHVjdGlvbiB0byB0aGUgbGlzdCB3aGV0aGVyIHRoZSBpbmRpdmlkdWFsIA0KPj4g ZW50cmllcyBzaG91bGQgYmUgY29tYmluZWQgb3Igc2VsZWN0ZWQgZnJvbS4gW1Fpbl06IE9rYXku ID4gSW4gc2VjdGlvbiAzLjEgd2hlcmUgeW91IHNheSAiUlRQIG1heSBiZSB1c2VkIHRvIG11bHRp Y2FzdCBncm91cHMiIGRpZCANCj4+IHlvdSBtZWFuICJSVFAgbWF5IGJlIHNlbnQgdG8gbXVsdGlj YXN0IGdyb3VwcyIgb3IgIlJUUCBtYXkgYmUgdXNlZCB3aXRoIA0KPj4gbXVsdGljYXN0IGdyb3Vw cyI/IFtRaW5dOiBJIHRoaW5rIGl0IHNob3VsZCBiZSB0aGUgbGF0dGVyIGNhc2UsaS5lLiwiIFJU UCBtYXkgYmUgdXNlZCB3aXRoIA0KPiBtdWx0aWNhc3QgZ3JvdXBzIi4gPiANCj4+IEluIHNlY3Rp b24gMy4yICJUaGUgZm9sbG93aW5nIGFyZSBmb3VyIHVzZSBjYXNlcyBidXQgYXJlIG5vdCBsaW1p dGVkIA0KPj4gdG86IiBkb2VzIG5vdCBwYXJzZS4gVGhlIGJ1bGxldHMgYXJlbid0IHJlYWxseSB1 c2UgY2FzZXMgYXMgbXVjaCBhcyB0aGV5IA0KPj4gYXJlIG1lY2hhbmlzbXMuIFdvdWxkIGl0IG1h a2UgbW9yZSBzZW5zZSB0byBzYXkgIkhlcmUgYXJlIGZvdXIgDQo+PiBtZWNoYW5pc21zIHRoYXQg aGF2ZSBiZWVuIGNyZWF0ZWQgdG8gYWRkcmVzcyB0aGUgbmVlZCBmb3IgbW9yZSBmcmVxdWVudCAN Cj4+IHJlcG9ydGluZy4gVGhpcyBsaXN0IGlzIG5vdCBpbnRlbmRlZCB0byBiZSBleGhhdXN0aXZl LiIgVGhlIHRoaXJkIGJ1bGxldCANCj4+IGluIHRoYXQgbGlzdCBzaG91bGQgc2F5ICJSVENQIGFu ZCBSVENQIFhSIGFyZSIgaW5zdGVhZCBvZiAiUlRDUCBvciBSVENQIA0KPj4gWFIgaXMiLiBbUWlu XTogT2theSwgYnV0IEkgaGF2ZSBpbmNvcnBvcmF0ZWQgdGhlIGtleXBvaW50cyBvZiBzZWN0aW9u IDMuMiBpbnRvIHNlY3Rpb24gMy4xLiA+IFRoZSBidWxsZXRzIGluIHNlY3Rpb24gNCB3b3VsZCBi ZSBiZXR0ZXIgYXMgc3Vic2VjdGlvbnMgd2l0aCB0aXRsZXMgDQo+PiAodGFrZW4gZnJvbSB0aGUg Zmlyc3QgcGhyYXNlIG9mIHRoZSBidWxsZXQpLiBbUWluXTogT2theS4gPiBJIHN1Z2dlc3QgdGhp cyBhbHRlcm5hdGl2ZSBmb3IgdGhlIGZpcnN0IGZ1bGwgc2VudGVuY2UgaW4gdGhlIGZpcnN0IA0K Pj4gYnVsbGV0IG9mIHNlY3Rpb24gNCA6ICJBIGNvbXBvdW5kIG1ldHJpY3MgYmxvY2sgaXMgZGVz aWduZWQgdG8gY29udGFpbiBhIA0KPj4gbGFyZ2UgbnVtYmVyIG9mIHBhcmFtZXRlcnMgZnJvbSBk aWZmZXJlbnQgY2xhc3NlcyBmb3IgYSBzcGVjaWZpYyANCj4+IGFwcGxpY2F0aW9uIGluIGEgc2lu Z2xlIGJsb2NrLiIgW1Fpbl06IE9rYXkuID4gU2VjdGlvbiA1J3MgdGl0bGUgc2hvdWxkIGJlICJH dWlkZWxpbmVzIGZvciByZXBvcnRpbmciIGluc3RlYWQgb2YgDQo+PiAiR3VpZGVsaW5lIGZvciBy ZXBvcnRpbmciIFtRaW5dOiBPa2F5LiA+IEluIHNlY3Rpb24gNS4xIEkgc3VnZ2VzdCAianVzdGlm eSB0aGUgb3ZlcmhlYWQsIiBpbnN0ZWFkIG9mICJqdXN0aWZ5IHRoZSANCj4+IG92ZXJoZWFkcywi IFtRaW5dOiBPa2F5LiA+IFNlY3Rpb24gNyAtIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBmaXJz dCBwYXJhZ3JhcGggZG9lcyBub3QgcGFyc2UuIFRoZSANCj4+IHNlY29uZCBwYXJhZ3JhcGggKHdo aWNoIGlzIGEgc2luZ2xlIHNlbnRlbmNlKSBzaG91bGQgYmUgY2xhcmlmaWVkIC0gYW4gDQo+PiBN Q1UgaXMgbm90IGEgdG9wb2xvZ3kuIFtRaW5dOiBPa2F5LiBIb3cgYWJvdXQgcmV2aXNpbmcgdGhl bSBhcyBmb2xsb3dzOiBPTEQgVGV4dDogIiBUaGUgdG9wb2xvZ2llcyBpbiB0aGlzIGNhdGVnb3J5 IGFyZSBUb3BvLVZpZGVvLVN3aXRjaC1NQ1UgYW5kIFRvcG8tUlRDUC10ZXJtaW5hdGluZy1NQ1Uu IFN1Y2ggdG9wb2xvZ2llcyBiYXNlZCBvbiBzeXN0ZW1zIGRvIG5vdCBiZWhhdmUgYWNjb3JkaW5n IHRvIHRoZSBSVFAgcHJvdG9jb2wgW1JGQzM1NTBdLiBDb25zaWRlcmluZyB0aGUgTUNVIGFuZCB0 cmFuc2xhdG9yIGFyZSB0d28gdHlwaWNhbCB0b3BvbG9naWVzIGluIHRoZSB0d28gY2F0ZWdvcmll cyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1lbnQgd2lsbCB0YWtlIHRoZW0gYXMgdHdvIHR5 cGljYWwgZXhhbXBsZXMgdG8gZXhwbGFpbiBob3cgUlRDUCBYUiByZXBvcnQgd29ya3MgaW4gZGlm ZmVyZW50IFJGQzUxMTcgdG9wb2xvZ2llcy4gIiBORVcgVGV4dDogIiBUaGUgdG9wb2xvZ2llcyBp biB0aGlzIGNhdGVnb3J5IGFyZSBUb3BvLVZpZGVvLVN3aXRjaC1NQ1UgYW5kIFRvcG8tUlRDUC10 ZXJtaW5hdGluZy1NQ1UuIFN1Y2ggdG9wb2xvZ2llcyBiYXNlZCBvbiBzeXN0ZW1zIChlLmcuLE1D VSkgZG8gbm90IGJlaGF2ZSBhY2NvcmRpbmcgdG8gdGhlIFJUUCBwcm90b2NvbCBbUkZDMzU1MF0u IENvbnNpZGVyaW5nIHRoZSBNQ1UgYW5kIHRyYW5zbGF0b3IgYXJlIHR3byB0eXBpY2FsIGludGVy bWVkaWFyeSBzeXN0ZW1zIGluIHRoZSB0d28gY2F0ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRo aXMgZG9jdW1lbnQgd2lsbCB0YWtlIHRoZW0gYXMgdHdvIHR5cGljYWwgZXhhbXBsZXMgdG8gZXhw bGFpbiBob3cgUlRDUCBYUiByZXBvcnQgd29ya3MgaW4gZGlmZmVyZW50IFJGQzUxMTcgdG9wb2xv Z2llcy4gIiA+IFRoZSBsYXN0IHR3byBzZW50ZW5jZXMgb2YgdGhlIGZpcnN0DQo+IHBhcmFncmFw aCBvZiB0aGUgc2VjdXJpdHkgDQo+PiBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFkZCBub3RoaW5n IHRvIHRoZSBkb2N1bWVudC4gSSBzdWdnZXN0IGRlbGV0aW5nIHRoZW0uIFtRaW5dOiBPa2F5LiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBdWRp by9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4gYXZ0IGF0IGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dCA+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiAqIFJlZmVyZW5jZXM6IA0KPiAqIFtBVlRD T1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMg DQo+ICogRnJvbTogUm9iZXJ0IFNwYXJrcw0KPiAqIFByZXYgYnkgRGF0ZTogW0FWVENPUkVdIFBy b3RvY29sIEFjdGlvbjogJ0V4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIGZv ciBSVFAgb3ZlciANCj4gVURQJyB0byBQcm9wb3NlZCBTdGFuZGFyZCAoZHJhZnQtaWV0Zi1hdnRj b3JlLWVjbi1mb3ItcnRwLTA4LnR4dCkgDQo+ICogUHJldmlvdXMgYnkgdGhyZWFkOiBbQVZUQ09S RV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzIA0K PiAqIE5leHQgYnkgdGhyZWFkOiBbQVZUQ09SRV0gUHJvdG9jb2wgQWN0aW9uOiAnRXhwbGljaXQg Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgZm9yIFJUUCBvdmVyIA0KPiBVRFAnIHRvIFBy b3Bvc2VkIFN0YW5kYXJkIChkcmFmdC1pZXRmLWF2dGNvcmUtZWNuLWZvci1ydHAtMDgudHh0KSAN Cj4gKiBJbmRleChlcyk6IA0KPiAqIERhdGUNCj4gKiBUaHJlYWQNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0 IENvcmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCg0KDQotLSANCkNvbGluIFBlcmtpbnMNCmh0dHA6Ly9j c3BlcmtpbnMub3JnLw0KDQoNCg== From bill.wu@huawei.com Tue May 22 20:26:05 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5734721F8554 for ; Tue, 22 May 2012 20:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 nY367t4gPLY9 for ; Tue, 22 May 2012 20:26:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11B7121F854B for ; Tue, 22 May 2012 20:26:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE17032; Tue, 22 May 2012 23:26:01 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 20:23:42 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 20:23:40 -0700 Received: from w53375 (10.138.41.149) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 11:23:36 +0800 Message-ID: From: Qin Wu To: Albrecht Schwarz , Colin Perkins References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> <1337739393.9307.YahooMailNeo@web171006.mail.ukl.yahoo.com> Date: Wed, 23 May 2012 11:23:35 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0221_01CD38D6.7E53CB70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 03:26:05 -0000 ------=_NextPart_000_0221_01CD38D6.7E53CB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksQWxicmVjaHQ6DQpUaGFuayBmb3Igc2hhcmluZywgSSBoYXZlIGJlZW4gYXdhcmUgb2YgdGhp cyB3b3JrIGJlaW5nIHByb2dyZXNzZWQgaW4gU0cgMTYuDQoNClJlZ2FyZHMhDQotUWluDQogIC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEFsYnJlY2h0IFNjaHdhcnogDQog IFRvOiBDb2xpbiBQZXJraW5zIDsgUWluIFd1IA0KICBDYzogYXZ0QGlldGYub3JnIA0KICBTZW50 OiBXZWRuZXNkYXksIE1heSAyMywgMjAxMiAxMDoxNiBBTQ0KICBTdWJqZWN0OiBSZTogW0FWVENP UkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMw0K DQoNCiAgRllJLCANCg0KICBJVFUtVCBTRzE2IGhhcyBhIHdvcmsgaXRlbSBmb3Igc3VjaCBraW5k IG9mIG1pZGRsZWJveGVzIGFuZCBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIHN1cHBvcnQ6DQoNCiAg aHR0cDovL3d3dy5pdHUuaW50L0lUVS1UL3dvcmtwcm9nL3dwX2l0ZW0uYXNweD9pc249ODQwNw0K ICAiR3VpZGVsaW5lcyBvbiB0aGUgdXNlIG9mIEguMjQ4IGNhcGFiaWxpdGllcyBmb3IgcGVyZm9y bWFuY2UgbW9uaXRvcmluZyBpbiBSVFAgbmV0d29ya3MgaW4gSC4yNDggUHJvZmlsZXMiDQoNCg0K ICAuLi4gYW5kIHRoZSBJVFUtVCB3b3JrIGlzIHJlZmVycmluZyB0byBNT05BUkNILg0KDQoNCiAg LUFsYnJlY2h0DQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgVm9uOiBDb2xp biBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz4NCiAgICBBbjogUWluIFd1IDxiaWxsLnd1QGh1 YXdlaS5jb20+IA0KICAgIENDOiBBbGJyZWNodCBTY2h3YXJ6IDxhbGJyZWNodHNjaHdhcnpAeWFo b28uZGU+OyBhdnRAaWV0Zi5vcmcgDQogICAgR2VzZW5kZXQ6IDEzOjA0IERpZW5zdGFnLCAyMi5N YWkgMjAxMg0KICAgIEJldHJlZmY6IFJlOiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzDQoNCg0KICAgIEkgYWxzbyBkb24ndCBhZ3Jl ZSB3aXRoIGRlbGV0aW5nIFNlY3Rpb24gMy4zIGZyb20gdGhlIG1vbmFyY2ggZHJhZnQuIA0KDQog ICAgVGhlIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBiZSBjbGVhciB0aGF0IHRoZXJlIGFyZSB2YWxp ZCBzY2VuYXJpb3MgZm9yIFJUUCBtb25pdG9yaW5nIHdpdGhpbiBhIG5ldHdvcmssIGVpdGhlciBp biBzb21lIG1pZGRsZWJveCB0aGF0IGNvbXByaXNlcyBwYXJ0IG9mIGFuIFJUUCBzZXNzaW9uLCBv ciBpbiBhIHRoaXJkLXBhcnR5IG1vbml0b3JpbmcgZGV2aWNlIHVzZWQgZm9yIG5ldHdvcmsgbWFu YWdlbWVudCBwdXJwb3Nlcy4gU2VjdGlvbiAzLjMgaXMgYSByZWFzb25hYmxlIHBsYWNlIHRvIGRp c2N1c3MgdGhlc2UsIGFuZCB0byBleHBsYWluIHdoeSB0aGUgbWV0cmljcyB0aGF0IGNhbiBiZSBy ZXBvcnRlZCBmcm9tIG1pZGRsZWJveGVzIGFyZSBkaWZmZXJlbnQgdG8gdGhvc2UgdGhhdCBjYW4g YmUgY2FwdHVyZWQgYXQgZW5kIHN5c3RlbXMuDQoNCiAgICBDb2xpbg0KDQoNCg0KICAgIE9uIDIy IE1heSAyMDEyLCBhdCAwNzo1MywgUWluIFd1IHdyb3RlOg0KICAgID4gSGksOg0KICAgID4gLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICA+IEZyb206ICJBbGJyZWNodCBTY2h3YXJ6 IiA8YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPg0KICAgID4gVG86IDxiaWxsLnd1QGh1YXdlaS5j b20+DQogICAgPiBDYzogPGF2dEBpZXRmLm9yZz47IDxyanNwYXJrc0Bub3N0cnVtLmNvbT4NCiAg ICA+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMiwgMjAxMiAxMToxOCBBTQ0KICAgID4gU3ViamVjdDog UmU6IFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1v bmFyY2gtMTMNCiAgICA+IA0KICAgID4gDQogICAgPiBEZWFyIEFsbCwNCiAgICA+IA0KICAgID4g Y29uY2VybmluZyB0aGUgcmVzb2x1dGlvbiBwcm9wb3NhbCBmb3IgY2xhdXNlIDMuMzoNCiAgICA+ IEkgZG9uJ3QgYWdyZWUgaW4ganVzdCBkZWxldGluZyBhZ2FpbiB0aGF0IHNlY3Rpb24hDQogICAg PiBUaGVyZSB3YXMgcXVpdGUgYSBsb25nIGRlYmF0ZSBmb3IgaW5jb3Jwb3JhdGluZyBzdWNoIGEg Y2xhdXNlLg0KICAgID4gVGhlIG9yaWdpbmFsIHRleHQgcHJvcG9zYWwgd2FzIG11Y2ggbW9yZSBk ZXRhaWxlZC4gUGVyaGFwcyB0aGUgc2hvcnRlbmluZyB0byBqdXN0IGEgc2luZ2xlIHBhcmFncmFw aCBpcyB0aGUgbWFpbiBjYXVzZSBmb3IgdW5jbGFyaXR5Lg0KICAgID4gVGh1cywgaW5zdGVhZCBv ZiByZW1vdmluZyBwcmV2aW91cyBhZ3JlZWQgdGV4dCwgd2UganVzdCByYXRoZXIgZXh0ZW5kIGl0 IGFnYWluLg0KICAgID4gDQogICAgPiANCiAgICA+IFtRaW5dOiANCiAgICA+IFRoZSByZWFzb24g SSBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgc2VjdGlvbiAzLjMgaXMgDQogICAgPiBhLiBJIHRoaW5r IFJvYmVydCBpcyBjb3JyZWN0LiBUaGUgc2V0IG9mIG1lYW5pbmdmdWwgbWV0cmljcyBpc24ndCBj aGFuZ2VkIGF0IGFsbCAgd2hlcmV2ZXIgeW91IGNvbGxlY3QgdGhlbS4gSXQgc2VlbXMgbGl0dGxl IHNlbnNlIA0KICAgID4gICAgdG8gc2F5ICJ0aGUgbG9jYXRpb24gb2YgdGhlIFJUUCBTZW5kZXIv UmVjZWl2ZXIgZW50aXRpZXMgbWF5IGltcGFjdCBhIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3Mu ICIgDQogICAgPiBiLiBXaGVyZSB0byBnYXRoZXIgb3IgbWVhc3VyZSBtZXRyaWNzIGNhbiBiZSBp bmRpY2F0ZWQgYnkgdGhlIGRlZmluaXRpb24gb2YgVHJhbnNwb3J0IG1ldHJpY3MsIEVuZCBzeXN0 ZW0gbWV0cmljcyBhbmQgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcy4NCiAgICA+IGMuIFNlY3Rp b24gMy4zIHNlZW1zIHRvIGRpc2N1c3Mgd2hlcmUgdG8gZ2F0aGVyIHdoYXQgbWV0cmljcy4gUmVj b21tZW5kYXRpb24gSVRVLVQgRy4xMDgxIGhhdmUgYWxyZWFkeSBkZWZpbmVkIGZpdmUgbW9uaXRv cmluZyBwb2ludHMgDQogICAgPiAgICB3aGVyZSB0aGUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnRz IGNhbiBiZSBtYWRlLg0KICAgID4gDQogICAgPj4gSSB0aGluayB0aGUgZGVmaW5pdGlvbiBvZiBh cHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGhhcyBhbHJlYWR5IGNsYXJpZmllZCB0aGF0ICBhcHBs aWNhdGlvbiBsZXZlbCBtZXRyaWNzIGlzIG5vcm1hbGx5IGdhdGhlcmVkIGZyb20gdXNlciBlbmRw b2ludC4gDQogICAgPiANCiAgICA+IE5vLiBXZSBkaWQgZGlzY3VzcyB0aGlzIGFscmVhZHkgZXh0 ZW5zaXZlbHkuDQogICAgPiBBbiBSVFAgbWVkaWEgdHJhbnNsYXRvciBjb3VsZCBwcm92aWRlIGFw cGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgYmVjYXVzZSBlLmcuIHRlcm1pbmF0aW5nIHRoZSBhcHBs aWNhdGlvbiBwcm90b2NvbCBsYXllci4NCiAgICA+IFN1Y2ggYW4gUlRQIHRvcG9sb2d5IGlzIE5P VCBsb2NhdGVkIGluIGFuIHVzZXIgZW5kcG9pbnQhDQogICAgPiANCiAgICA+IFtRaW5dOiBTb3Jy eSwgSSBzaG91bGQgY29ycmVjdCBtZSB0byBzYXkgUW9FIG1ldHJpYyBpcyB1c3VzYWxseSBtZWFz dXJlZCBhdCB0aGUgdXNlciBlbmRwb2ludC4NCiAgICA+IA0KICAgID4gUmVnYXJkcywNCiAgICA+ IEFsYnJlY2h0DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4g W0RhdGUgUHJldl1bRGF0ZSBOZXh0XVtUaHJlYWQgUHJldl1bVGhyZWFkIE5leHRdW0RhdGUgSW5k ZXhdW1RocmVhZCBJbmRleF0gDQogICAgPiBSZTogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmll dyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMw0KICAgID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICA+IA0KICAgID4gKiBUbzogUm9iZXJ0IFNwYXJrcyA8cmpz cGFya3MgYXQgbm9zdHJ1bS5jb20+LCBJRVRGIEFWVENvcmUgV0cgPGF2dCBhdCBpZXRmLm9yZz4s IDxkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhdCB0b29scy5pZXRmLm9yZz4NCiAgICA+ICog U3ViamVjdDogUmU6IFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1h dnRjb3JlLW1vbmFyY2gtMTMNCiAgICA+ICogRnJvbTogUWluIFd1IDxiaWxsLnd1IGF0IGh1YXdl aS5jb20+DQogICAgPiAqIERhdGU6IEZyaSwgMTggTWF5IDIwMTIgMTg6Mzc6NTYgKzA4MDANCiAg ICA+ICogRGVsaXZlcmVkLXRvOiBhdnQgYXQgaWV0ZmEuYW1zbC5jb20NCiAgICA+ICogTGlzdC1h cmNoaXZlOiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2F2dD4NCiAgICA+ ICogTGlzdC1oZWxwOiA8bWFpbHRvOmF2dC1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4N CiAgICA+ICogTGlzdC1pZDogQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2Ug PGF2dC5pZXRmLm9yZz4NCiAgICA+ICogTGlzdC1wb3N0OiA8bWFpbHRvOmF2dEBpZXRmLm9yZz4N CiAgICA+ICogTGlzdC1zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2F2dD4sIDxtYWlsdG86YXZ0LXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3Jp YmU+DQogICAgPiAqIExpc3QtdW5zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL29wdGlvbnMvYXZ0PiwgPG1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXVu c3Vic2NyaWJlPg0KICAgID4gKiBSZWZlcmVuY2VzOiA8NEZCMkUzMjMuMzA5MDQwNiBhdCBub3N0 cnVtLmNvbT4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAN CiAgICA+IEhpLFJvYmVydDoNCiAgICA+IFRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldy4g cGxlYXNlIHNlZSBteSByZXBsaWVzIGlubGluZSBiZWxvd3MuIFJlZ2FyZHMhDQogICAgPiAtUWlu DQogICAgPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICAgID4gRnJvbTogIlJvYmVy dCBTcGFya3MiIDxyanNwYXJrcyBhdCBub3N0cnVtLmNvbT4NCiAgICA+IFRvOiAiSUVURiBBVlRD b3JlIFdHIiA8YXZ0IGF0IGlldGYub3JnPjsgPGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoIGF0 IHRvb2xzLmlldGYub3JnPg0KICAgID4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTYsIDIwMTIgNzox MyBBTQ0KICAgID4gU3ViamVjdDogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFm dC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMyA+IFN1bW1hcnk6IFRoZXJlIGFyZSBpc3N1ZXMgdG8g cmVzb2x2ZSB3aXRoIGEgcmV2aXNlZCBJRCBiZWZvcmUgDQogICAgPj4gcHJvZ3Jlc3NpbmcgdG8g SUVURiBMQy4NCiAgICA+PiANCiAgICA+PiBJdCdzIGEgc3RydWdnbGUgdG8gc2VlIHRoZSBfYXJj aGl0ZWN0dXJlXyB0aGlzIGRvY3VtZW50IGlzIHN1cHBvc2VkIHRvIA0KICAgID4+IGRlc2NyaWJl LiBJIHN1c3BlY3QgbW9zdCBvZiB0aGUgd29ya2luZyBncm91cCBlbmVyZ3kgd2VudCBpbnRvIFNl Y3Rpb24gNSANCiAgICA+PiAodGhlIGd1aWRlbGluZXMgZm9yIHdyaXRpbmcgWFIgYmxvY2sgZGVm aW5pdGlvbnMpIC0gdGhlIHJlc3Qgb2YgdGhlIA0KICAgID4+IGRvY3VtZW50IG5lZWRzIGEgc2lt aWxhciBsZXZlbCBvZiBhdHRlbnRpb24gdG8gZGV0YWlsLg0KICAgID4+IA0KICAgID4+IFRoZXJl IGFyZSB0d28gbWFqb3IgaXNzdWVzIHRoYXQgSSd2ZSB0YWdnZWQgd2l0aCBhICgqKS4gSSBmb2xs b3dlZCBhIA0KICAgID4+IG1vc3RseSBkb2N1bWVudC1vcmRlciBmbG93IGluc3RlYWQgb2YgZ3Jv dXBpbmcgdGhlIG1ham9yIGlzc3VlcyBhdCB0aGUgdG9wLg0KICAgID4+IA0KICAgID4+ICgqKSBH aXZlbiB0aGUgZG9jdW1lbnQncyB0aXRsZSwgaXQgc2hvdWxkIGJlIHZlcnkgZWFzeSB0byBhbnN3 ZXIgIldoYXQgDQogICAgPj4gaXMgdGhlIG1vbml0b3JpbmcgYXJjaGl0ZWN0dXJlPyIgZm9yIHBl b3BsZSB3aG8gYXJlIHJlYWRpbmcgdGhpcyBkcmFmdCANCiAgICA+PiBmb3IgdGhlIGZpcnN0IHRp bWUuDQogICAgPj4gVGhlIGtleSBtZXNzYWdlIGlzIHRoYXQgdGhlIG1vbml0b3JpbmcgYXJjaGl0 ZWN0dXJlIGNvbnNpc3RzIG9mIE1vbml0b3JzIA0KICAgID4+IHRoYXQgZXhjaGFuZ2UgaW5mb3Jt YXRpb24gdXNpbmcgUlRDUCBNZXRyaWMgQmxvY2tzLiBbUWluXTogQWdyZWUuID5UaGUgdGV4dCBz aG91bGQgc2F5IA0KICAgID4+IHRoYXQuIFtRaW5dOiBPa2F5LiA+IFRoZXJlIGlzIGEgbG90IG9m IHByb3NlIGluIHNlY3Rpb24gMyBhbmQgdmlzdWFsIGRldGFpbCBpbiB0aGUgDQogICAgPj4gZGlh Z3JhbSBpbiBGaWd1cmUgMSB0aGF0IG1ha2VzIHRoYXQgZXh0cmVtZWx5IGRpZmZpY3VsdCB0byBz ZWUuIA0KICAgID4+IFNpbXBsaWZ5aW5nIHRoZSBmaWd1cmUgYnkgcmVtb3ZpbmcgdGhlIGRldGFp bHMgYWJvdXQgYXBwbGljYXRpb25zIGFuZCANCiAgICA+PiB0cmFuc3BvcnRzLCBvciBhdCBsZWFz dCBtb3ZpbmcgdGhlbSB0byBhIHNlY29uZCBmaWd1cmUsIG1ha2luZyB0aGUgDQogICAgPj4gTW9u aXRvciBib3hlcyBzdGFuZCBvdXQsIGFuZCBtYWtpbmcgdGhlIHR5cGVzIG9mIGluZm9ybWF0aW9u IGZsb3dzICh0aGUgDQogICAgPj4gYXJyb3dzKSB2aXN1YWxseSBkaXN0aW5jdGl2ZSB3b3VsZCBo ZWxwLiBTaW1wbGlmeSB0aGUgcHJvc2UgKG11Y2ggb2YgaXQgDQogICAgPj4gY291bGQgYmUgcmVt b3ZlZCkgdG8gZm9jdXMgb24gdGhhdCBrZXkgbWVzc2FnZS4gW1Fpbl06IEFncmVlLCBJIHByb3Bv c2UgdG8gcmVtb3ZlIHRoZSBmaWd1cmUgMSBhbmQgc3F1ZWV6ZSB0aGUgc2VjdGlvbiAzLjEgYXMg Zm9sbG93czogIiAzLjEuIE92ZXJ2aWV3IFRoZSBSVFAgbW9uaXRvcmluZyBhcmNoaXRlY3R1cmUg Y29tcHJpc2VzIHRoZSBmb2xsb3dpbmcgdHdvIGtleSBmdW5jdGlvbmFsIGNvbXBvbmVudHMgc2hv d24gYmVsb3c6IG8gUlRQIE1vbml0b3IgbyBSVFAgTWV0cmljIEJsb2NrIFN0cnVjdHVyZSBSVFAg TW9uaXRvciBpcyB0aGUgZnVuY3Rpb25hbCBjb21wb25lbnQgZGVmaW5lZCBpbiB0aGUgUmVhbC10 aW1lIFRyYW5zcG9ydCBQcm90b2NvbCBbUkZDMzU1MF0uIEl0IGFjdHMgYXMgYSBzb3VyY2Ugb2Yg aW5mb3JtYXRpb24gZ2F0aGVyZWQgZm9yIG1vbml0b3JpbmcgcHVycG9zZXMgYW5kIGV4Y2hhbmdl cyBpbmZvcm1hdGlvbiB3aXRoIHRoZSBvdGhlciBSVFAgbW9uaXRvcnMgdXNpbmcgUlRDUCBNZXRy aWMgQmxvY2tzLiBBY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gb2YgbW9uaXRvciBpbiB0aGUg UlRQIFByb3RvY29sIFtSRkMzNTUwXSwgdGhlIGVuZCBzeXN0ZW0gdGhhdCBydW5zIGFuIGFwcGxp Y2F0aW9uIHByb2dyYW0gdGhhdCBzZW5kcyBvciByZWNlaXZlcyBSVFAgZGF0YSBwYWNrZXRzLCBh biBpbnRlcm1lZGlhdGUtIHN5c3RlbSB0aGF0IGZvcndhcmRzIFJUUCBwYWNrZXRzIHRvIEVuZC1k ZXZpY2VzIG9yIGEgdGhpcmQgcGFydHkgdGhhdCBvYnNlcnZlcyB0aGUgUlRQIGFuZCBSVENQIHRy YWZmaWMgYnV0IGRvZXMgbm90IG1ha2UgaXRzZWxmIHZpc2libGUgdG8gdGhlIFJUUCBTZXNzaW9u IHBhcnRpY2lwYW50cyAoaS5lLiwgdGhlIHRoaXJkIHBhcnR5IG1vbml0b3IgZGVwaWN0ZWQgaW4g ZmlndXJlIDEpIGNhbiBhY3QgYXMgdGhlDQogICAgPiBSVFAgbW9uaXRvci4gVGhlIHRoaXJkIHBh cnR5IG1vbml0b3Igc2hvdWxkIGJlIHBsYWNlZCBvbiB0aGUgUlRQL1JUQ1AgcGF0aHMgYmV0d2Vl biB0aGUgc2VuZGVyLCBpbnRlcm1lZGlhdGUgYW5kIHRoZSByZWNlaXZlci4gVGhlIFJUUCBtb25p dG9yIGFsc28gZXhwb3NlcyByZWFsIHRpbWUgQXBwbGljYXRpb24gUW9TL1FvRSBtZXRyaWMgaW5m b3JtYXRpb24gaW4gdGhlIGFwcHJvcHJpYXRlIHJlcG9ydCBibG9jayBmb3JtYXQgKGUuZy4sUlRD UCBYUiBvciBvdGhlIG5vbi1SVFAgbWVhbnMpIHRvIHRoZSBtYW5hZ2VtZW50IHN5c3RlbS4gU3Vj aCBpbmZvcm1hdGlvbiBjYW4gYmUgZm9ybXVsYXRlZCBhcyBkaWZmZXJlbnQgbWV0cmljIHR5cGVz LCBlLmcuLGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpYywgdHJhbnNwb3J0IGxldmVsIG1ldHJpYywg ZW5kIHN5c3RlbSBtZXRyaWMsIGludGVydmFsIG1ldHJpYywgY3VtdWxhdGl2ZSBtZXRyaWMsIHNh bXBsZWQgbWV0cmljLCBkaXJlY3QgbWV0cmljLCBjb21wb3NlZCBtZXRyaWMsZXRjLiBCb3RoIHRo ZSBSVENQIG9yIFJUQ1AgWFIgY2FuIGJlIGV4dGVuZGVkIHRvIGNvbnZleSB0aGVzZSBtZXRyaWNz LiBUaGUgZGV0YWlscyBvbiB0cmFuc3BvcnQgcHJvdG9jb2xzIGZvciB0aGVzZSBtZXRyaWMgYXJl IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMi4gUlRQIG1heSBiZSB1c2VkIHRvIG11bHRpY2FzdCBn cm91cHMsIGJvdGggQW55IFNvdXJjZSBNdWx0aWNhc3QgKEFTTSkgYW5kIFNvdXJjZSBTcGVjaWZp YyBNdWx0aWNhc3QgKFNTTSkuIFRoZXNlIGdyb3VwcyBjYW4gYmUgbW9uaXRvcmVkIHVzaW5nIFJU Q1AuIEluIHRoZSBBU00gY2FzZSwgdGhlIG1vbml0b3IgaXMgYSBtZW1iZXIgb2YgdGhlIG11bHRp Y2FzdCBncm91cCBhbmQgbGlzdGVucyB0byBSVENQIFhSIHJlcG9ydHMgZnJvbSBhbGwgbWVtYmVy cyBvZiB0aGUgQVNNDQogICAgPiBncm91cC4gSW4gdGhlIFNTTSBjYXNlLCB0aGVyZSBpcyBhIHVu aWNhc3QgZmVlZGJhY2sgdGFyZ2V0IHRoYXQgcmVjZWl2ZXMgUlRDUCBmZWVkYmFjayBmcm9tIHJl Y2VpdmVycyBhbmQgZGlzdHJpYnV0ZXMgaXQgdG8gb3RoZXIgbWVtYmVycyBvZiB0aGUgU1NNIGdy b3VwIChzZWUgZmlndXJlIDEgb2YgUkZDNTc2MCkuIFRoZSBtb25pdG9yIHdpbGwgbmVlZCB0byBi ZSBjby1sb2NhdGVkIHdpdGggdGhlIGZlZWRiYWNrIHRhcmdldCB0byByZWNlaXZlIGFsbCBmZWVk YmFjayBmcm9tIHRoZSByZWNlaXZlcnMgKHRoaXMgbWF5IGFsc28gYmUgYW4gaW50ZXJtZWRpYXRl IHN5c3RlbSkuIEluIGJvdGggQVNNIGFuZCBTU00gc2NlbmFyaW9zLCByZWNlaXZlcnMgY2FuIHNl bmQgUlRDUCBYUiByZXBvcnRzIHRvIGVuaGFuY2UgdGhlIHJlY2VwdGlvbiBxdWFsaXR5IHJlcG9y dGluZy4gIiA+IEluIHRoZSBkZWZpbml0aW9uIG9mIENvbXBvc2VkIG1ldHJpY3MsIHRoZSBzZW50 ZW5jZSAiQW4gZXhhbXBsZSBpcyBhIA0KICAgID4+IG1ldHJpYyBjYWxjdWxhdGVkIGJhc2VkIG9u IGRlcml2ZWQgbWV0cmljcyB0aGF0IGhhdmUgYmVlbiBtZWFzdXJlZC4iIA0KICAgID4+IG1ha2Vz IGxpdHRsZSBzZW5zZS4gW1Fpbl0gVGhlIGRlcml2ZWQgbWV0cmljcyBpbiB0aGUgc2VudGVuY2Ug c2hvdWxkIGJlZW4gY29ycmVjdGVkIGFzICJkaXJlY3QgbWV0cmljIi4gPkRpZCB5b3UgbWVhbiBz b21ldGhpbmcgbGlrZSAiQW4gZXhhbXBsZSBpcyBhIG1ldHJpYyANCiAgICA+PiBkZXJpdmVkIGJ5 IGFsZ29yaXRobWljYWxseSBjb21iaW5pbmcgbWVhc3VyZWQgbWV0cmljcy4iPyBbUWluXTpJIGFn cmVlIHdpdGggeW91ciBzdWdnZXN0ZWQgdGV4dCBhbmQgbGlrZSB0byBhZG9wdCB5b3VyIHN1Z2dl c3Rpb24uID4gVGhlIGRlZmluaXRpb25zIG9mIEludGVydmFsLCBDdW11bGF0aXZlLCBhbmQgU2Ft cGxlZCBtZXRyaWNzIGFyZSBub3QgY2xlYXIuIFtRaW5dOiBJIGFncmVlIHRoZSBkZWZpbml0aW9u IGZvciB0aGVzZSB0aHJlZSBtZXRyaWNzIG5lZWQgdG8gYmUgbW9yZSBjbGVhZXIsIEkgcHJvcG9z ZXMgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2VzOiBORVcgVGV4dDogIiBJbnRlcnZhbCBtZXRy aWNzIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVkIHZhbHVlcyBhcmUgbWVhc3VyZWQgaW4g dGhlIG1vc3QgcmVjZW50IG1lYXN1cmVtZW50IGludGVydmFsIGR1cmF0aW9uIGJldHdlZW4gc3Vj Y2Vzc2l2ZSBtZXRyaWNzIHJlcG9ydHMuIFN1Y2ggbWVhc3VyZW1lbnQgaW50ZXJ2YWwgaXMgZXF1 YWwgdG8gb25lIFJUQ1AgcmVwb3J0IGludGVydmFsIChSRkMzNTUwLFNlY3Rpb24gNi4yKS4gQ3Vt dWxhdGl2ZSBtZXRyaWNzIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVkIHZhbHVlcyBhcHBs eSB0byB0aGUgYWNjdW11bGF0aW9uIHBlcmlvZCBjaGFyYWN0ZXJpc3RpYyBvZiBjdW11bGF0aXZl IG1lYXN1cmVtZW50cy4gVGhlIHJlcG9ydGVkIHZhbHVlcyBhcmUgbWVhc3VyZWQgZHVyaW5nIHRo ZSBhY2N1bXVsYXRpb24gcGVyaW9kLiBUaGUgYWNjdW11bGF0aW9uIHBlcmlvZCBzcGFucyBvdmVy IG1vcmUgdGhhbiBvbmUgUlRDUCByZXBvcnQgaW50ZXJ2YWxzLiBTYW1wbGVkIG1ldHJpY3MgTWV0 cmljcyBvZiB3aGljaCB0aGUgcmVwb3J0ZWQgdmFsdWVzIG9ubHkgYXBwbHkgdG8gdGhlIHZhbHVl IG9mIGEgY29udGludW91c2x5IG1lYXN1cmVkIG9yDQogICAgPiBjYWxjdWxhdGVkIG1ldHJpYyB0 aGF0IGhhcyBiZWVuIHNhbXBsZWQgYXQgYW55IGdpdmVuIGluc3RhbmNlIG9mIHRoZSBSVENQIHJl cG9ydCBpbnRlcnZhbC4gT25lIGV4YW1wbGUgb2Ygc3VjaCBtZXRyaWMgaXMgdGhlIGludGVyLWFy cml2YWwgaml0dGVyIGRlc2NyaWJlZCBpbiB0aGUgc2VjdGlvbiA2LjQuMSBvZiBSRkMzNTUwLiAi ID4gSWYgdGhlIGRpc2N1c3Npb24gYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDMuMSBpcyBrZXB0LCB0 aGUgcmVmZXJlbmNlIHRvIA0KICAgID4+IFJGQzU3NjAgc2hvdWxkIGJlIGEgcmVhbCByZWZlcmVu Y2UsIGFuZCBSRkM1NzYwIHNob3VsZCBhcHBlYXIgaW4gdGhlIA0KICAgID4+IHJlZmVyZW5jZSBz ZWN0aW9uLiBbUWluXTogT2theS4gPiBUaGUgcG9pbnQgb2Ygc2VjdGlvbiAzLjIgaXMgbm90IG9i dmlvdXMuIEhvdyBkb2VzIGl0IGNvbnRyaWJ1dGUgdG8gdGhlIA0KICAgID4+IGRlc2NyaXB0aW9u IG9mIHRoZSBhcmNoaXRlY3R1cmUuIEl0IG1peGVzIHRhbGtpbmcgYWJvdXQgd2hhdCByZXBvcnQg DQogICAgPj4gYmxvY2tzIGFyZSB3aXRoIG9jY2FzaW9uYWxseSBuZWVkaW5nIHRvIHNlbmQgdGhl bSBtb3JlIGZyZXF1ZW50bHkuIFRob3NlIA0KICAgID4+IHBvaW50cyBjb3VsZCBiZSBtYWRlIHNl cGFyYXRlbHkgYW5kIG1vcmUgc2ltcGx5LiBbUWluXTogT2theS4gSSBsaWtlIHRvIGluY29ycG9y YXRlIHRoZSBrZXkgcG9pbnRzIGluIHRoZSBzZWN0aW9uIDMuMiBpbnRvIHNlY3Rpb24gMy4xID4g U2VjdGlvbiAzLjMgaXMgbm90IGNsZWFyIC0gaXQgc3RhcnRzIG9mZiBzYXlpbmcgdGhhdCB0aGUg bG9jYXRpb24gb2YgdGhlIA0KICAgID4+IHNlbmRlciBhbmQgcmVjZWl2ZXIgbWF5IGNoYW5nZSB3 aGF0IG1ldHJpY3MgYXJlIG1lYW5pbmdmdWwuIEl0J3Mgbm90IA0KICAgID4+IGNsZWFyIHdoYXQg eW91IG1lYW4gYnkgbG9jYXRpb24uIFlvdSBjZXJ0YWlubHkgZG9uJ3QgbWVhbiBnZW9zcGF0aWFs IA0KICAgID4+IGNvb3JkaW5hdGVzLiBEbyB5b3UgbWVhbiBhbnl0aGluZyBvdGhlciB0aGFuIHdo ZXRoZXIgdGhlIGVsZW1lbnQgaXMgDQogICAgPj4gdHJ1c3RlZCBvciB1bnRydXN0ZWQgYnkgdGhl IG9wZXJhdGlvbnMgbmV0d29yaz8gSWYgc28sIHNheSB0aGF0LiBUaGUgDQogICAgPj4gcmVzdCBv ZiB0aGUgcGFyYWdyYXBoIG9ubHkgc3BlYWtzIHRvIHdoYXQgZWxlbWVudCBjb2xsZWN0cyB0aGUg bWV0cmljcy4gW1Fpbl0gU2VjdGlvbiAzLjMgaXMgb25seSB1c2VkIHRvIGRlc2NyaWJlIHdoZXJl IG9yIGZyb20gd2hpY2ggUlRQIGVudGl0eSB0byBnYXRoZXIgdGhlIG1ldHJpY3MgKGkuZS4sIG1l YXN1cmVtZW50IHBvaW50KSBpbiB0aGUgcGh5c2ljYWwgbmV0d29yayBhbmQgaXMgbm90IGZvY3Vz IG9mIHRoaXMgZG9jdW1lbnQuIFNlY29uZGx5LCBJIHRoaW5rIHRoZSBkZWZpbml0aW9uIG9mIGFw cGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgaGFzIGFscmVhZHkgY2xhcmlmaWVkIHRoYXQgYXBwbGlj YXRpb24gbGV2ZWwgbWV0cmljcyBpcyBub3JtYWxseSBnYXRoZXJlZCBmcm9tIHVzZXIgZW5kcG9p bnQuID4gSXQncyBub3QgY2xlYXIgdGhhdCB0aGUgc2V0IG9mIG1lYW5pbmdmdWwgbWV0cmljcyBp cyBjaGFuZ2VkIGF0IGFsbCAtIA0KICAgID4+IGp1c3Qgd2hlcmUgeW91IGNvbGxlY3QgdGhlbS4g SWYgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MgZG9lcyBpbiANCiAgICA+PiBmYWN0IGNo YW5nZSwgdGhlcmUgbmVlZHMgdG8gYmUgYWRkaXRpb25hbCBkaXNjdXNzaW9uIGhlcmUuIFtRaW5d OiBUaGUgbWV0cmljcyBhY3R1YWxseSBkb2Vzbid0IGNoYW5nZS5TaW5jZSB0aGUgZGVmaW5pdGlv biBvZiBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIEhhdmUgYWxyZWFkeSBjb252ZXllZCB0aGUg bWVhbmluZyBvZiB3aGF0IHNlY3Rpb24gMy4zIHdhbnRzIHRvIGRlc2NyaWJlLCBJIHByb3Bvc2Ug dG8gcmVtb3ZlIHRoaXMgc2VjdGlvbi4gPiBTZWN0aW9uIDQncyBmaXJzdCBwYXJhZ3JhcGg6IElz ICJwcm9iYWJseSIgdGhlIGJlc3QgdGhlIHdvcmtpbmcgZ3JvdXAgDQogICAgPj4gY2FuIHNheT8g W1Fpbl06Tm8sIHdpbGwgcmVtb3ZlIHRoaXMgd29yZC4gPiBUaGUgbGFzdCB0d28gc2VudGVuY2Vz IG9mIHRoZSBzZWNvbmQgYnVsbGV0IGluIHNlY3Rpb24gNCBkbyBub3QgcGFyc2UuIA0KICAgID4+ IFBsZWFzZSBzaW1wbGlmeSB0aGVtLiBbUWluXTogT2theSwgaG93IGFib3V0IGNoYW5nZSB0aGVt IGFzIGZvbGxvd3M6IE5FVyBUZXh0OiAiIFdpdGggdGhlc2UgbWluaW1hbCBudW1iZXIgb2YgUlRD UCBzdGF0aXN0aWNzIHBhcmFtZXRlcnMgbWFwcGVkIHRvIG5vbi1SVENQIG1lYXN1cmVtZW50cywg aXQgaXMgaGFyZCB0byBwcm92aWRlIGFjY3VyYXRlIG1lYXN1cmVzIG9mIHJlYWwgdGltZSBhcHBs aWNhdGlvbiBxdWFsaXR5LGNvbmR1Y3QgZGV0YWlsZWQgZGF0YSBhbmFseXNpcyBhbmQgY3JlYXRl cyBhbGVydHMgdGltbHkgdG8gdGhlIHVzZXJzLiBUaGVyZWZvcmUgY29ycmVsYXRpb24gYmV0d2Vl biBSVENQIFhSIGFuZCBub24tUlRQIGRhdGEgc2hvdWxkIGJlIHByb3ZpZGVkLiAiID4gVGhlIGZp cnN0IGZ1bGwgc2VudGVuY2Ugb2YgdGhlIHRoaXJkIGJ1bGxldCBpbiBzZWN0aW9uIDQgZG9lcyBu b3QgbWFrZSANCiAgICA+PiBzZW5zZS4gVGhlIHdob2xlIGJ1bGxldCBjb3VsZCBiZSBjbGFyaWZp ZWQuIFtRaW5dOiBBZ3JlZSBhbmQgd2lsbCByZW1vdmUgdGhlIGZpcnN0IHNlbnRlbmNlLiA+IFRo ZSBmb3VydGggYnVsbGV0IGluIHNlY3Rpb24gNCBhbmQgc2VjdGlvbiA1LjUgc2hvdWxkIGNhbGwg b3V0IHRoYXQgDQogICAgPj4gUkZDMzYxMSBhbHJlYWR5IHNldCBCbG9jayBUeXBlIDI1NSBhc2lk ZSBmb3IgZnV0dXJlIGV4dGVuc2lvbnMsIA0KICAgID4+IGFudGljaXBhdGluZyB0aGUgcG90ZW50 aWFsIG5lZWQgdG8gZXh0ZW5kIHRoZSBibG9jayB0eXBlIHNwYWNlLiBbUWluXTogT2theSwgSG93 IGFib3V0IHJldmlzaW5nIHRoZSBzZWN0aW9uIDQsYnVsbGV0IDQgYXMgZm9sbG93czogIiBDb25z dW1wdGlvbiBvZiBYUiBibG9jayBjb2RlIHBvaW50cy4gVGhlIFJUQ1AgWFIgYmxvY2sgbmFtZXNw YWNlIGlzIGxpbWl0ZWQgYnkgdGhlIDgtYml0IGJsb2NrIHR5cGUgZmllbGQgaW4gdGhlIFJUQ1Ag WFIgaGVhZGVyLiBTcGFjZSBleGhhdXN0aW9uIG1heSBiZSBhIGNvbmNlcm4gaW4gdGhlIGZ1dHVy ZS4gQW50aWNpcGF0aW5nIHRoZSBwb3RlbnRpYWwgbmVlZCB0byBleHRlbmQgdGhlIGJsb2NrIHR5 cGUgc3BhY2UsIGl0IGlzIG5vdGVkIGluIFtSRkMzNjExXSB0aGF0IEJsb2NrIFR5cGUgMjU1IGlz IHJlc2VydmVkIGZvciBmdXR1cmUgZXh0ZW5zaW9ucywgIiA+IEluIHNlY3Rpb24gNSwgY29uc2lk ZXIgbmFtaW5nIHRoZSBzdWJzZWN0aW9ucyB3aXRoIHRoZSBhY3R1YWwgZ3VpZGVsaW5lIA0KICAg ID4+IGluc3RlYWQgb2YgdGhlIHByb2JsZW0gdGhlIGd1aWRlbGluZSBpcyB0cnlpbmcgdG8gYWRk cmVzcy4NCiAgICA+PiA1LjEuIE1ldHJpYyBibG9ja3Mgc2hvdWxkIGNvbnRhaW4gYSBzaW5nbGUg bWV0cmljIFtRaW5dOiBJIHN1Z2dlc3QgdG8gY2hhbmdlIGl0IGFzICJDb250YWluIHRoZSBzaW5n bGUgbWV0cmljcyBpbiB0aGUgbWV0cmljIGJsb2NrIiA+IDUuMi4gSW5jbHVkZSB0aGUgcGF5bG9h ZCB0eXBlIGFuZCBmb3JtYXQgcGFyYW1ldGVycyBpbiB0aGUgbWV0cmljIGJsb2NrIFtRaW5dOiBP a2F5LiA+IDUuMy4gVXNlIFJUQ1AgU0RFUyB0byBjb3JyZWxhdGUgWFIgcmVwb3J0cyB3aXRoIG5v bi1SVFAgZGF0YSBbUWluXTogT2theS4gPiA1LjQuIERvbid0IHJlcGVhdCBtZWFzdXJlbWVudCBp bmZvcm1hdGlvbiBhY3Jvc3MgbWV0cmljIGJsb2Nrcw0KICAgID4+IA0KICAgID4gW1Fpbl06IEl0 IGlzIG5vdCBwb3NzaWJsZSBjb21wbGV0ZWx5IHRvIGF2b2lkIG1lYXN1cmVtZW50IGluZm9ybWF0 aW9uIHJlcGVhdGl0aW9uLiBlLmcuLCBmb3IgcGFja2V0IGxvc3Mgcm9idXN0bmVzcyBpZiB0aGUg cmVwb3J0IGJsb2NrcyBmb3IgdGhlIHNhbWUgaW50ZXJ2YWwgc3BhbiBvdmVyIG1vcmUgdGhhbiBv bmUgUlRDUCBwYWNrZXQgdGhlbiBlYWNoIG11c3QgaGF2ZSB0aGUgc2FtZSBtZWFzdXJlbWVudCBp ZGVudGl0eSBpbmZvcm1hdGlvbiBTbyBJIHN1Z2dlc3QgdG8gY2hhbmdlIGl0IGFzOiAicmVkdWNl IG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIGFjcm9zcyBtZXRyaWMgYmxvY2tzIiA+IFRoaXMgcG9p bnRzIG91dCBhIHN0cnVjdHVyYWwgcHJvYmxlbSB3aXRoIHRoZSBzZWN0aW9uLiBXaHkgaXMgNS41 IGhlcmU/IA0KICAgID4+IEl0J3Mgbm90IGEgZ3VpZGVsaW5lLiBbUWluXTogQWdyZWUgYW5kIGFs c28gYXMgZGlzY3Vzc2VkLFNwYWNlIGV4aGF1c3Rpb24gaXMgbm90IGJpZyBpc3N1ZS4gSG93IGFi b3V0IHJlbW92ZSB0aGlzIHNlY3Rpb24/ID4gKCopIEFuZCBpdCByYWlzZXMgYSBxdWVzdGlvbiBh Ym91dCB3aGF0IHRoZSBkb2N1bWVudCBpcyB0cnlpbmcgdG8gDQogICAgPj4gYWNoaWV2ZSB3aXRo IHNlY3Rpb24gNS40LiBUaGF0IHNlY3Rpb24gY2xhaW1zIHRoZSBkb2N1bWVudCBpcyBwcm9wb3Np bmcgDQogICAgPj4gYSBuZXcgWFIgYmxvY2sgdHlwZSB0byBoZWxwIGF2b2lkIGR1cGxpY2F0aW9u LCBidXQgaXQgZG9lc24ndCBhY3R1YWxseSANCiAgICA+PiBkZWZpbmUgdGhlIG5ldyBibG9jayB0 eXBlLiBJcyB0aGUgZ3VpZGVsaW5lIHNheWluZyBzaW1wbHkgZG9uJ3QgcmVwZWF0IA0KICAgID4+ IG1lYXN1cmVtZW50cyBvciBpdHMgdGhlIGd1aWRlbGluZSBzYXlpbmcgInVzZSB0aGlzIG5ldyBY UiBibG9jayB0eXBlIHdlIA0KICAgID4+IGhhdmVuJ3QgZGVmaW5lZCB5ZXQiPyBbUWluXTogSnVz dCB0byBjbGFyaWZ5LCB3ZSBoYXZlIGFscmVhZHkgZGVmaW5lZCBvbmUgbmV3IFhSIEJsb2NrIHR5 cGUgdG8gaGVscCBhdm9pZCBvciByZWR1Y2UgZHVwbGljYXRpb24uIEl0IGlzIG1lYXN1cmVtZW50 IGluZm9ybWF0aW9uIGJsb2NrLiBUaGUgcmVsZXZhbnQgZHJhZnQgaXMgYXZhaWxhYmxlIGF0OiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFz LWlkZW50aXR5LTA2ID5UaGUgc2VjdGlvbiBuZWVkcyBtb3JlIGNsYXJpdHkuIElmIGl0IHJlYWxs eSBpcyANCiAgICA+PiB0cnlpbmcgdG8gZGVmaW5lIGEgbmV3IHR5cGUsIHRoZXJlJ3MgbW9yZSB3 b3JrIHRvIGJlIGRvbmUuIFtRaW5dOiBJbiBvcmRlciB0byBhdm9pZCBzdWNoIGNvbmZ1c2lvbiwg SSBwcm9wb3NlZCB0byBkbyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgc2VjdGlvbiA1LjQ6 IE9MRCBUZXh0OiAiIFRoaXMgbWVtbyBwcm9wb3NlcyB0byBkZWZpbmUgYSBuZXcgWFIgQmxvY2sg dGhhdCB3aWxsIGJlIHVzZWQgdG8gY29udmV5IHRoZSBjb21tb24gdGltZSBwZXJpb2QgYW5kIHRo ZSBudW1iZXIgb2YgcGFja2V0cyBzZW50IGR1cmluZyB0aGlzIHBlcmlvZC4gIiBOZXcgdGV4dDog IiBUaGlzIG1lbW8gcHJvcG9zZXMgdG8gZGVmaW5lIGEgbmV3IFhSIEJsb2NrIChpLmUuLCB0aGUg TWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gYmxvY2tbSS5ELWlldGYteHJibG9jay1ydGNwLXhyLW1l YXMtaWRlbnRpdHldKSB0aGF0IHdpbGwgYmUgdXNlZCB0byBjb252ZXkgdGhlIGNvbW1vbiB0aW1l IHBlcmlvZCBhbmQgdGhlIG51bWJlciBvZiBwYWNrZXRzIHNlbnQgZHVyaW5nIHRoaXMgcGVyaW9k LiAiID4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIHBhcnRpY3VsYXJseSB0 aGUgdGhpcmQgcGFyYWdyYXBoLCANCiAgICA+PiBuZWVkcyB0byBiZSBjbGVhcmVyLiBXaGF0IGV4 YWN0bHkgZG8geW91IG1lYW4gYnkgIm1vbml0b3Jpbmcgc2hvdWxkIGJlIA0KICAgID4+IHByb2hp Yml0ZWQiLCBhbmQgaG93IGlzIHRoZSBmYWN0IHRoYXQgdGhpcmQgcGFydHkgbW9uaXRvcnMgZG9u J3Qgc2VuZCANCiAgICA+PiBSVENQIHJlbGV2YW50PyBEaWQgeW91IGludGVuZCB0aG9zZSB0byBi ZSBzZXBhcmF0ZSBwb2ludHM/IFtRaW5dOiBZZXMsIHRoZXkgYXJlIG9uIHRoZSBkaWZmZXJlbnQg cG9ydC4gU3VjaCBtb25pdG9yIG1heSByZWNlaXZlIFJUUCBwYWNrZXQgYnV0IGRvZXMgbm90IHNl bmQgUlRDUCBwYWNrZXQuID4gRWRpdG9yaWFsIE5pdHMgYW5kIFN1Z2dlc3Rpb25zOg0KICAgID4+ IA0KICAgID4+IFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgdGhlIGludHJvZHVjdGlvbiBpcyBvdmVy bHkgY29tcGxleCwgYW5kIHdvbid0IGFnZSANCiAgICA+PiB3ZWxsLiBJIHN1Z2dlc3QgcmVwbGFj aW5nIGl0IHdpdGg6ICJNdWx0aW1lZGlhIHNlcnZpY2VzIHVzaW5nIHRoZSANCiAgICA+PiBSZWFs LVRpbWUgUHJvdG9jb2wgKFJUUCkgYXJlIHNlZWluZyBpbmNyZWFzZWQgdXNlLiBTdGFuZGFyZCBt ZXRob2RzIGZvciANCiAgICA+PiBnYXRoZXJpbmcgUlRQIHBlcmZvcm1hbmNlIG1ldHJpY3MgZnJv bSB0aGVzZSBhcHBsaWNhdGlvbnMgYXJlIG5lZWRlZCB0byANCiAgICA+PiBtYW5hZ2UgdW5jZXJ0 YWludGllcyBpbiB0aGUgYmVoYXZpb3IgYW5kIGF2YWlsYWJpbGl0eSBvZiB0aGVpciANCiAgICA+ PiBzZXJ2aWNlcy4iIFRoZW4gcmVwbGFjZSAiVGhlc2UgcmFwaWRseSBlbWVyZ2luZyBzdGFuZGFy ZHMsIiB3aXRoIA0KICAgID4+ICJTdGFuZGFyZHMiLiBbUWluXTogT2theS4gPiBJbnRyb2R1Y3Rp b24gcGFyYWdyYXBoIDMgc2VudGVuY2UgMiBzaG91bGQgc3RhcnQgIlRoZSBSVENQIEd1aWRlbGlu ZXMgDQogICAgPj4gW1JGQzU5NjhdIi4gSXQgd291bGQgYmUgZXZlbiBiZXR0ZXIgdG8gdXNlIHRo ZSBmdWxsIHRpdGxlIGZyb20gNTk2ODogDQogICAgPj4gJ1RoZSAiR3VpZGVsaW5lcyBmb3IgRXh0 ZW5kaW5nIHRoZSBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkiIFtSRkM1OTY4XScgW1Fpbl06 IE9rYXkuID4gVGhpcyBtYXkgYmVjb21lIG1vb3QgYXMgc2VjdGlvbiAzIGlzIG1vZGlmaWVkIHRv IG1ha2UgaXRzIG1haW4gcG9pbnQgDQogICAgPj4gbW9yZSBvYnZpb3VzLCBidXQgUkZDMzU1MCBk b2VzIG5vdCBjaGFyYWN0ZXJpemUgTW9uaXRvcnMgYXMgImEgc291cmNlIG9mIA0KICAgID4+IGlu Zm9ybWF0aW9uIi4gVGhhdCBjb3VsZCBiZSBtaXN1bmRlcnN0b29kLiBQbGVhc2UgY2hvb3NlIGFu b3RoZXIgd29yZC4gDQogICAgPj4gUGVyaGFwcyAicmVwb3NpdG9yeSI/IFtRaW5dOiBPa2F5LCBy ZXBvc2l0b3J5IGxvb2tzIGdvb2QgdG8gbWUuID4gSW4gYnVsbGV0IGxpc3RzLCBzdGFydGluZyBh biBlbnRyeSB3aXRoICJvciIgb3IgImFuZCIgaXMgdW5uZWNlc3NhcnkuIEl0IA0KICAgID4+IHNo b3VsZCBiZSBjbGVhciBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIGxpc3Qgd2hldGhlciB0 aGUgaW5kaXZpZHVhbCANCiAgICA+PiBlbnRyaWVzIHNob3VsZCBiZSBjb21iaW5lZCBvciBzZWxl Y3RlZCBmcm9tLiBbUWluXTogT2theS4gPiBJbiBzZWN0aW9uIDMuMSB3aGVyZSB5b3Ugc2F5ICJS VFAgbWF5IGJlIHVzZWQgdG8gbXVsdGljYXN0IGdyb3VwcyIgZGlkIA0KICAgID4+IHlvdSBtZWFu ICJSVFAgbWF5IGJlIHNlbnQgdG8gbXVsdGljYXN0IGdyb3VwcyIgb3IgIlJUUCBtYXkgYmUgdXNl ZCB3aXRoIA0KICAgID4+IG11bHRpY2FzdCBncm91cHMiPyBbUWluXTogSSB0aGluayBpdCBzaG91 bGQgYmUgdGhlIGxhdHRlciBjYXNlLGkuZS4sIiBSVFAgbWF5IGJlIHVzZWQgd2l0aCANCiAgICA+ IG11bHRpY2FzdCBncm91cHMiLiA+IA0KICAgID4+IEluIHNlY3Rpb24gMy4yICJUaGUgZm9sbG93 aW5nIGFyZSBmb3VyIHVzZSBjYXNlcyBidXQgYXJlIG5vdCBsaW1pdGVkIA0KICAgID4+IHRvOiIg ZG9lcyBub3QgcGFyc2UuIFRoZSBidWxsZXRzIGFyZW4ndCByZWFsbHkgdXNlIGNhc2VzIGFzIG11 Y2ggYXMgdGhleSANCiAgICA+PiBhcmUgbWVjaGFuaXNtcy4gV291bGQgaXQgbWFrZSBtb3JlIHNl bnNlIHRvIHNheSAiSGVyZSBhcmUgZm91ciANCiAgICA+PiBtZWNoYW5pc21zIHRoYXQgaGF2ZSBi ZWVuIGNyZWF0ZWQgdG8gYWRkcmVzcyB0aGUgbmVlZCBmb3IgbW9yZSBmcmVxdWVudCANCiAgICA+ PiByZXBvcnRpbmcuIFRoaXMgbGlzdCBpcyBub3QgaW50ZW5kZWQgdG8gYmUgZXhoYXVzdGl2ZS4i IFRoZSB0aGlyZCBidWxsZXQgDQogICAgPj4gaW4gdGhhdCBsaXN0IHNob3VsZCBzYXkgIlJUQ1Ag YW5kIFJUQ1AgWFIgYXJlIiBpbnN0ZWFkIG9mICJSVENQIG9yIFJUQ1AgDQogICAgPj4gWFIgaXMi LiBbUWluXTogT2theSwgYnV0IEkgaGF2ZSBpbmNvcnBvcmF0ZWQgdGhlIGtleXBvaW50cyBvZiBz ZWN0aW9uIDMuMiBpbnRvIHNlY3Rpb24gMy4xLiA+IFRoZSBidWxsZXRzIGluIHNlY3Rpb24gNCB3 b3VsZCBiZSBiZXR0ZXIgYXMgc3Vic2VjdGlvbnMgd2l0aCB0aXRsZXMgDQogICAgPj4gKHRha2Vu IGZyb20gdGhlIGZpcnN0IHBocmFzZSBvZiB0aGUgYnVsbGV0KS4gW1Fpbl06IE9rYXkuID4gSSBz dWdnZXN0IHRoaXMgYWx0ZXJuYXRpdmUgZm9yIHRoZSBmaXJzdCBmdWxsIHNlbnRlbmNlIGluIHRo ZSBmaXJzdCANCiAgICA+PiBidWxsZXQgb2Ygc2VjdGlvbiA0IDogIkEgY29tcG91bmQgbWV0cmlj cyBibG9jayBpcyBkZXNpZ25lZCB0byBjb250YWluIGEgDQogICAgPj4gbGFyZ2UgbnVtYmVyIG9m IHBhcmFtZXRlcnMgZnJvbSBkaWZmZXJlbnQgY2xhc3NlcyBmb3IgYSBzcGVjaWZpYyANCiAgICA+ PiBhcHBsaWNhdGlvbiBpbiBhIHNpbmdsZSBibG9jay4iIFtRaW5dOiBPa2F5LiA+IFNlY3Rpb24g NSdzIHRpdGxlIHNob3VsZCBiZSAiR3VpZGVsaW5lcyBmb3IgcmVwb3J0aW5nIiBpbnN0ZWFkIG9m IA0KICAgID4+ICJHdWlkZWxpbmUgZm9yIHJlcG9ydGluZyIgW1Fpbl06IE9rYXkuID4gSW4gc2Vj dGlvbiA1LjEgSSBzdWdnZXN0ICJqdXN0aWZ5IHRoZSBvdmVyaGVhZCwiIGluc3RlYWQgb2YgImp1 c3RpZnkgdGhlIA0KICAgID4+IG92ZXJoZWFkcywiIFtRaW5dOiBPa2F5LiA+IFNlY3Rpb24gNyAt IHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggZG9lcyBub3QgcGFyc2Uu IFRoZSANCiAgICA+PiBzZWNvbmQgcGFyYWdyYXBoICh3aGljaCBpcyBhIHNpbmdsZSBzZW50ZW5j ZSkgc2hvdWxkIGJlIGNsYXJpZmllZCAtIGFuIA0KICAgID4+IE1DVSBpcyBub3QgYSB0b3BvbG9n eS4gW1Fpbl06IE9rYXkuIEhvdyBhYm91dCByZXZpc2luZyB0aGVtIGFzIGZvbGxvd3M6IE9MRCBU ZXh0OiAiIFRoZSB0b3BvbG9naWVzIGluIHRoaXMgY2F0ZWdvcnkgYXJlIFRvcG8tVmlkZW8tU3dp dGNoLU1DVSBhbmQgVG9wby1SVENQLXRlcm1pbmF0aW5nLU1DVS4gU3VjaCB0b3BvbG9naWVzIGJh c2VkIG9uIHN5c3RlbXMgZG8gbm90IGJlaGF2ZSBhY2NvcmRpbmcgdG8gdGhlIFJUUCBwcm90b2Nv bCBbUkZDMzU1MF0uIENvbnNpZGVyaW5nIHRoZSBNQ1UgYW5kIHRyYW5zbGF0b3IgYXJlIHR3byB0 eXBpY2FsIHRvcG9sb2dpZXMgaW4gdGhlIHR3byBjYXRlZ29yaWVzIG1lbnRpb25lZCBhYm92ZSwg dGhpcyBkb2N1bWVudCB3aWxsIHRha2UgdGhlbSBhcyB0d28gdHlwaWNhbCBleGFtcGxlcyB0byBl eHBsYWluIGhvdyBSVENQIFhSIHJlcG9ydCB3b3JrcyBpbiBkaWZmZXJlbnQgUkZDNTExNyB0b3Bv bG9naWVzLiAiIE5FVyBUZXh0OiAiIFRoZSB0b3BvbG9naWVzIGluIHRoaXMgY2F0ZWdvcnkgYXJl IFRvcG8tVmlkZW8tU3dpdGNoLU1DVSBhbmQgVG9wby1SVENQLXRlcm1pbmF0aW5nLU1DVS4gU3Vj aCB0b3BvbG9naWVzIGJhc2VkIG9uIHN5c3RlbXMgKGUuZy4sTUNVKSBkbyBub3QgYmVoYXZlIGFj Y29yZGluZyB0byB0aGUgUlRQIHByb3RvY29sIFtSRkMzNTUwXS4gQ29uc2lkZXJpbmcgdGhlIE1D VSBhbmQgdHJhbnNsYXRvciBhcmUgdHdvIHR5cGljYWwgaW50ZXJtZWRpYXJ5IHN5c3RlbXMgaW4g dGhlIHR3byBjYXRlZ29yaWVzIG1lbnRpb25lZCBhYm92ZSwgdGhpcyBkb2N1bWVudCB3aWxsIHRh a2UgdGhlbSBhcyB0d28gdHlwaWNhbCBleGFtcGxlcyB0byBleHBsYWluIGhvdyBSVENQIFhSIHJl cG9ydCB3b3JrcyBpbiBkaWZmZXJlbnQgUkZDNTExNyB0b3BvbG9naWVzLiAiID4gVGhlIGxhc3Qg dHdvIHNlbnRlbmNlcyBvZiB0aGUgZmlyc3QNCiAgICA+IHBhcmFncmFwaCBvZiB0aGUgc2VjdXJp dHkgDQogICAgPj4gY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhZGQgbm90aGluZyB0byB0aGUgZG9j dW1lbnQuIEkgc3VnZ2VzdCBkZWxldGluZyB0aGVtLiBbUWluXTogT2theS4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+IEF1ZGlvL1ZpZGVv IFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQogICAgPj4gYXZ0IGF0IGlldGYub3JnDQogICAg Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQgPg0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IA0KICAgID4gKiBSZWZlcmVuY2Vz OiANCiAgICA+ICogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2 dGNvcmUtbW9uYXJjaC0xMyANCiAgICA+ICogRnJvbTogUm9iZXJ0IFNwYXJrcw0KICAgID4gKiBQ cmV2IGJ5IERhdGU6IFtBVlRDT1JFXSBQcm90b2NvbCBBY3Rpb246ICdFeHBsaWNpdCBDb25nZXN0 aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBmb3IgUlRQIG92ZXIgDQogICAgPiBVRFAnIHRvIFByb3Bv c2VkIFN0YW5kYXJkIChkcmFmdC1pZXRmLWF2dGNvcmUtZWNuLWZvci1ydHAtMDgudHh0KSANCiAg ICA+ICogUHJldmlvdXMgYnkgdGhyZWFkOiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzIA0KICAgID4gKiBOZXh0IGJ5IHRocmVhZDog W0FWVENPUkVdIFByb3RvY29sIEFjdGlvbjogJ0V4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0 aW9uIChFQ04pIGZvciBSVFAgb3ZlciANCiAgICA+IFVEUCcgdG8gUHJvcG9zZWQgU3RhbmRhcmQg KGRyYWZ0LWlldGYtYXZ0Y29yZS1lY24tZm9yLXJ0cC0wOC50eHQpIA0KICAgID4gKiBJbmRleChl cyk6IA0KICAgID4gKiBEYXRlDQogICAgPiAqIFRocmVhZA0KICAgID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IEF1ZGlvL1ZpZGVvIFRyYW5z cG9ydCBDb3JlIE1haW50ZW5hbmNlDQogICAgPiBhdnRAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCg0KDQogICAgLS0gDQogICAgQ29s aW4gUGVya2lucw0KICAgIGh0dHA6Ly9jc3BlcmtpbnMub3JnLw0KDQoNCg0KDQoNCg== ------=_NextPart_000_0221_01CD38D6.7E53CB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTIyMiI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGksQWxicmVjaHQ6PC9ESVY+DQo8RElW PlRoYW5rIGZvciBzaGFyaW5nLCBJIGhhdmUgYmVlbiBhd2FyZSBvZiB0aGlzIHdvcmsgYmVpbmcg cHJvZ3Jlc3NlZCBpbiBTRyANCjE2LjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIz NDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyE8L0RJVj4NCjxE SVY+LVFpbjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAg MnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4t TEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIgDQpkaXI9bHRyPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IEJBQ0tHUk9V TkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxl PWFsYnJlY2h0c2Nod2FyekB5YWhvby5kZSANCiAgaHJlZj0ibWFpbHRvOmFsYnJlY2h0c2Nod2Fy ekB5YWhvby5kZSI+QWxicmVjaHQgU2Nod2FyejwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWNzcEBjc3Blcmtp bnMub3JnIA0KICBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmciPkNvbGluIFBlcmtpbnM8 L0E+IDsgPEEgDQogIHRpdGxlPWJpbGwud3VAaHVhd2VpLmNvbSBocmVmPSJtYWlsdG86YmlsbC53 dUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1hdnRAaWV0Zi5vcmcgDQogIGhy ZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gV2VkbmVzZGF5 LCBNYXkgMjMsIDIwMTIgMTA6MTYgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSZTogW0FWVENPUkVdIFN1YmplY3Q6IEFE IHJldmlldyBvZiANCiAgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTM8L0RJVj4NCiAgPERJ Vj48QlI+PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiAjZmZmOyBG T05ULUZBTUlMWTogQ291cmllciBOZXcsIGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5z LXNlcmlmOyBDT0xPUjogIzAwMDsgRk9OVC1TSVpFOiAxMHB0Ij4NCiAgPERJVj5GWUksIDxCUj48 L0RJVj4NCiAgPERJVj5JVFUtVCBTRzE2IGhhcyBhIHdvcmsgaXRlbSBmb3Igc3VjaCBraW5kIG9m IG1pZGRsZWJveGVzIGFuZCBwZXJmb3JtYW5jZSANCiAgbW9uaXRvcmluZyBzdXBwb3J0OjxCUj48 L0RJVj4NCiAgPERJVj48QSANCiAgaHJlZj0iaHR0cDovL3d3dy5pdHUuaW50L0lUVS1UL3dvcmtw cm9nL3dwX2l0ZW0uYXNweD9pc249ODQwNyI+aHR0cDovL3d3dy5pdHUuaW50L0lUVS1UL3dvcmtw cm9nL3dwX2l0ZW0uYXNweD9pc249ODQwNzwvQT48L0RJVj4NCiAgPERJVj4iPFNQQU4gaWQ9Y3Rs MDBfQ29udGVudFBsYWNlSG9sZGVyMV9ycHRfbWFpbl9jdGwwMF9sYmxfc3ViamVjdD5HdWlkZWxp bmVzIA0KICBvbiB0aGUgdXNlIG9mIEguMjQ4IGNhcGFiaWxpdGllcyBmb3IgcGVyZm9ybWFuY2Ug bW9uaXRvcmluZyBpbiBSVFAgbmV0d29ya3MgaW4gDQogIEguMjQ4IFByb2ZpbGVzPC9TUEFOPiI8 L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+Li4uIGFuZCB0aGUgSVRVLVQgd29yayBp cyByZWZlcnJpbmcgdG8gTU9OQVJDSC48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+ LUFsYnJlY2h0PEJSPjxTUEFOPjwvU1BBTj48L0RJVj4NCiAgPERJVj48QlI+PFNQQU4+PC9TUEFO PjwvRElWPg0KICA8RElWPjxTUEFOPjwvU1BBTj48L0RJVj4NCiAgPERJVj48QlI+DQogIDxCTE9D S1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigxNiwxNiwyNTUpIDJweCBzb2xpZDsg TUFSR0lOLVRPUDogNXB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweCI+DQog ICAgPERJViANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIgTmV3LCBjb3VyaWVyLCBt b25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZjsgRk9OVC1TSVpFOiAxMHB0Ij4NCiAgICA8RElW IHN0eWxlPSJGT05ULUZBTUlMWTogdGltZXMgbmV3IHJvbWFuLCBuZXcNCiAgICAgeW9yaywgdGlt ZXMsIHNlcmlmOyBGT05ULVNJWkU6IDEycHQiPg0KICAgIDxESVYgZGlyPWx0cj48Rk9OVCBzaXpl PTIgZmFjZT1BcmlhbD4NCiAgICA8SFIgU0laRT0xPg0KICAgIDxCPjxTUEFOIHN0eWxlPSJGT05U LVdFSUdIVDogYm9sZCI+Vm9uOjwvU1BBTj48L0I+IENvbGluIFBlcmtpbnMgJmx0OzxBIA0KICAg IGhyZWY9Im1haWx0bzpjc3BAY3NwZXJraW5zLm9yZyI+Y3NwQGNzcGVya2lucy5vcmc8L0E+Jmd0 OzxCUj48Qj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkFuOjwvU1BBTj48 L0I+IFFpbiBXdSAmbHQ7PEEgDQogICAgaHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+ YmlsbC53dUBodWF3ZWkuY29tPC9BPiZndDsgPEJSPjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05U LVdFSUdIVDogYm9sZCI+Q0M6PC9TUEFOPjwvQj4gQWxicmVjaHQgU2Nod2FyeiAmbHQ7PEEgDQog ICAgaHJlZj0ibWFpbHRvOmFsYnJlY2h0c2Nod2FyekB5YWhvby5kZSI+YWxicmVjaHRzY2h3YXJ6 QHlhaG9vLmRlPC9BPiZndDs7IDxBIA0KICAgIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2 dEBpZXRmLm9yZzwvQT4gPEJSPjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9s ZCI+R2VzZW5kZXQ6PC9TUEFOPjwvQj4gMTM6MDQgRGllbnN0YWcsIDIyLk1haSANCiAgICAyMDEy PEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+QmV0cmVmZjo8L1NQQU4+PC9C PiBSZTogW0FWVENPUkVdIA0KICAgIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2 dGNvcmUtbW9uYXJjaC0xMzxCUj48L0ZPTlQ+PC9ESVY+PEJSPkkgDQogICAgYWxzbyBkb24ndCBh Z3JlZSB3aXRoIGRlbGV0aW5nIFNlY3Rpb24gMy4zIGZyb20gdGhlIG1vbmFyY2ggZHJhZnQuIA0K ICAgIDxCUj48QlI+VGhlIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBiZSBjbGVhciB0aGF0IHRoZXJl IGFyZSB2YWxpZCBzY2VuYXJpb3MgDQogICAgZm9yIFJUUCBtb25pdG9yaW5nIHdpdGhpbiBhIG5l dHdvcmssIGVpdGhlciBpbiBzb21lIG1pZGRsZWJveCB0aGF0IGNvbXByaXNlcyANCiAgICBwYXJ0 IG9mIGFuIFJUUCBzZXNzaW9uLCBvciBpbiBhIHRoaXJkLXBhcnR5IG1vbml0b3JpbmcgZGV2aWNl IHVzZWQgZm9yIA0KICAgIG5ldHdvcmsgbWFuYWdlbWVudCBwdXJwb3Nlcy4gU2VjdGlvbiAzLjMg aXMgYSByZWFzb25hYmxlIHBsYWNlIHRvIGRpc2N1c3MgDQogICAgdGhlc2UsIGFuZCB0byBleHBs YWluIHdoeSB0aGUgbWV0cmljcyB0aGF0IGNhbiBiZSByZXBvcnRlZCBmcm9tIG1pZGRsZWJveGVz IA0KICAgIGFyZSBkaWZmZXJlbnQgdG8gdGhvc2UgdGhhdCBjYW4gYmUgY2FwdHVyZWQgYXQgZW5k IA0KICAgIHN5c3RlbXMuPEJSPjxCUj5Db2xpbjxCUj48QlI+PEJSPjxCUj5PbiAyMiBNYXkgMjAx MiwgYXQgMDc6NTMsIFFpbiBXdSANCiAgICB3cm90ZTo8QlI+Jmd0OyBIaSw6PEJSPiZndDsgLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8QlI+Jmd0OyBGcm9tOiANCiAgICAiQWxicmVjaHQg U2Nod2FyeiIgJmx0OzxBIGhyZWY9Im1haWx0bzphbGJyZWNodHNjaHdhcnpAeWFob28uZGUiIA0K ICAgIHltYWlsdG89Im1haWx0bzphbGJyZWNodHNjaHdhcnpAeWFob28uZGUiPmFsYnJlY2h0c2No d2FyekB5YWhvby5kZTwvQT4mZ3Q7PEJSPiZndDsgDQogICAgVG86ICZsdDs8QSBocmVmPSJtYWls dG86YmlsbC53dUBodWF3ZWkuY29tIiANCiAgICB5bWFpbHRvPSJtYWlsdG86YmlsbC53dUBodWF3 ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L0E+Jmd0OzxCUj4mZ3Q7IENjOiANCiAgICAmbHQ7 PEEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyIgDQogICAgeW1haWx0bz0ibWFpbHRvOmF2dEBp ZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9BPiZndDs7ICZsdDs8QSANCiAgICBocmVmPSJtYWlsdG86 cmpzcGFya3NAbm9zdHJ1bS5jb20iIA0KICAgIHltYWlsdG89Im1haWx0bzpyanNwYXJrc0Bub3N0 cnVtLmNvbSI+cmpzcGFya3NAbm9zdHJ1bS5jb208L0E+Jmd0OzxCUj4mZ3Q7IA0KICAgIFNlbnQ6 IFR1ZXNkYXksIE1heSAyMiwgMjAxMiAxMToxOCBBTTxCUj4mZ3Q7IFN1YmplY3Q6IFJlOiBbQVZU Q09SRV0gU3ViamVjdDogDQogICAgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25h cmNoLTEzPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgRGVhciANCiAgICBBbGwsPEJSPiZndDsg PEJSPiZndDsgY29uY2VybmluZyB0aGUgcmVzb2x1dGlvbiBwcm9wb3NhbCBmb3IgY2xhdXNlIA0K ICAgIDMuMzo8QlI+Jmd0OyBJIGRvbid0IGFncmVlIGluIGp1c3QgZGVsZXRpbmcgYWdhaW4gdGhh dCBzZWN0aW9uITxCUj4mZ3Q7IA0KICAgIFRoZXJlIHdhcyBxdWl0ZSBhIGxvbmcgZGViYXRlIGZv ciBpbmNvcnBvcmF0aW5nIHN1Y2ggYSBjbGF1c2UuPEJSPiZndDsgVGhlIA0KICAgIG9yaWdpbmFs IHRleHQgcHJvcG9zYWwgd2FzIG11Y2ggbW9yZSBkZXRhaWxlZC4gUGVyaGFwcyB0aGUgc2hvcnRl bmluZyB0byANCiAgICBqdXN0IGEgc2luZ2xlIHBhcmFncmFwaCBpcyB0aGUgbWFpbiBjYXVzZSBm b3IgdW5jbGFyaXR5LjxCUj4mZ3Q7IFRodXMsIA0KICAgIGluc3RlYWQgb2YgcmVtb3ZpbmcgcHJl dmlvdXMgYWdyZWVkIHRleHQsIHdlIGp1c3QgcmF0aGVyIGV4dGVuZCBpdCANCiAgICBhZ2Fpbi48 QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyBbUWluXTogPEJSPiZndDsgVGhlIHJlYXNvbiBJIHBy b3Bvc2UgdG8gDQogICAgcmVtb3ZlIHRoZSBzZWN0aW9uIDMuMyBpcyA8QlI+Jmd0OyBhLiBJIHRo aW5rIFJvYmVydCBpcyBjb3JyZWN0LiBUaGUgc2V0IG9mIA0KICAgIG1lYW5pbmdmdWwgbWV0cmlj cyBpc24ndCBjaGFuZ2VkIGF0IGFsbCZuYnNwOyB3aGVyZXZlciB5b3UgY29sbGVjdCB0aGVtLiBJ dCANCiAgICBzZWVtcyBsaXR0bGUgc2Vuc2UgPEJSPiZndDsmbmJzcDsgJm5ic3A7IHRvIHNheSAi dGhlIGxvY2F0aW9uIG9mIHRoZSBSVFAgDQogICAgU2VuZGVyL1JlY2VpdmVyIGVudGl0aWVzIG1h eSBpbXBhY3QgYSBzZXQgb2YgbWVhbmluZ2Z1bCBtZXRyaWNzLiAiIDxCUj4mZ3Q7IA0KICAgIGIu IFdoZXJlIHRvIGdhdGhlciBvciBtZWFzdXJlIG1ldHJpY3MgY2FuIGJlIGluZGljYXRlZCBieSB0 aGUgZGVmaW5pdGlvbiBvZiANCiAgICBUcmFuc3BvcnQgbWV0cmljcywgRW5kIHN5c3RlbSBtZXRy aWNzIGFuZCBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzLjxCUj4mZ3Q7IA0KICAgIGMuIFNlY3Rp b24gMy4zIHNlZW1zIHRvIGRpc2N1c3Mgd2hlcmUgdG8gZ2F0aGVyIHdoYXQgbWV0cmljcy4gUmVj b21tZW5kYXRpb24gDQogICAgSVRVLVQgRy4xMDgxIGhhdmUgYWxyZWFkeSBkZWZpbmVkIGZpdmUg bW9uaXRvcmluZyBwb2ludHMgPEJSPiZndDsmbmJzcDsgDQogICAgJm5ic3A7IHdoZXJlIHRoZSBw ZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMgY2FuIGJlIG1hZGUuPEJSPiZndDsgPEJSPiZndDsmZ3Q7 IA0KICAgIEkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2YgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmlj cyBoYXMgYWxyZWFkeSBjbGFyaWZpZWQgDQogICAgdGhhdCZuYnNwOyBhcHBsaWNhdGlvbiBsZXZl bCBtZXRyaWNzIGlzIG5vcm1hbGx5IGdhdGhlcmVkIGZyb20gdXNlciANCiAgICBlbmRwb2ludC4g PEJSPiZndDsgPEJSPiZndDsgTm8uIFdlIGRpZCBkaXNjdXNzIHRoaXMgYWxyZWFkeSANCiAgICBl eHRlbnNpdmVseS48QlI+Jmd0OyBBbiBSVFAgbWVkaWEgdHJhbnNsYXRvciBjb3VsZCBwcm92aWRl IGFwcGxpY2F0aW9uIGxldmVsIA0KICAgIG1ldHJpY3MgYmVjYXVzZSBlLmcuIHRlcm1pbmF0aW5n IHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCBsYXllci48QlI+Jmd0OyANCiAgICBTdWNoIGFuIFJU UCB0b3BvbG9neSBpcyBOT1QgbG9jYXRlZCBpbiBhbiB1c2VyIGVuZHBvaW50ITxCUj4mZ3Q7IDxC Uj4mZ3Q7IA0KICAgIFtRaW5dOiBTb3JyeSwgSSBzaG91bGQgY29ycmVjdCBtZSB0byBzYXkgUW9F IG1ldHJpYyBpcyB1c3VzYWxseSBtZWFzdXJlZCBhdCANCiAgICB0aGUgdXNlciBlbmRwb2ludC48 QlI+Jmd0OyA8QlI+Jmd0OyBSZWdhcmRzLDxCUj4mZ3Q7IEFsYnJlY2h0PEJSPiZndDsgDQogICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBbRGF0ZSBQcmV2XVtEYXRl IE5leHRdW1RocmVhZCANCiAgICBQcmV2XVtUaHJlYWQgTmV4dF1bRGF0ZSBJbmRleF1bVGhyZWFk IEluZGV4XSA8QlI+Jmd0OyBSZTogW0FWVENPUkVdIFN1YmplY3Q6IA0KICAgIEFEIHJldmlldyBv ZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMzxCUj4mZ3Q7IA0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgPEJSPiZndDsgKiBUbzogUm9iZXJ0IFNwYXJr cyANCiAgICAmbHQ7cmpzcGFya3MgYXQgbm9zdHJ1bS5jb20mZ3Q7LCBJRVRGIEFWVENvcmUgV0cg Jmx0O2F2dCBhdCBpZXRmLm9yZyZndDssIA0KICAgICZsdDtkcmFmdC1pZXRmLWF2dGNvcmUtbW9u YXJjaCBhdCB0b29scy5pZXRmLm9yZyZndDs8QlI+Jmd0OyAqIFN1YmplY3Q6IFJlOiANCiAgICBb QVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNo LTEzPEJSPiZndDsgKiANCiAgICBGcm9tOiBRaW4gV3UgJmx0O2JpbGwud3UgYXQgaHVhd2VpLmNv bSZndDs8QlI+Jmd0OyAqIERhdGU6IEZyaSwgMTggTWF5IDIwMTIgDQogICAgMTg6Mzc6NTYgKzA4 MDA8QlI+Jmd0OyAqIERlbGl2ZXJlZC10bzogYXZ0IGF0IGlldGZhLmFtc2wuY29tPEJSPiZndDsg KiANCiAgICBMaXN0LWFyY2hpdmU6ICZsdDs8QSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvYXZ0IiANCiAgICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9hdnQ8L0E+Jmd0OzxCUj4mZ3Q7ICogDQogICAgTGlzdC1oZWxw OiAmbHQ7bWFpbHRvOjxBIGhyZWY9Im1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZyIgDQogICAg eW1haWx0bz0ibWFpbHRvOmF2dC1yZXF1ZXN0QGlldGYub3JnIj5hdnQtcmVxdWVzdEBpZXRmLm9y ZzwvQT4/c3ViamVjdD1oZWxwJmd0OzxCUj4mZ3Q7IA0KICAgICogTGlzdC1pZDogQXVkaW8vVmlk ZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgDQogICAgJmx0O2F2dC5pZXRmLm9yZyZndDs8 QlI+Jmd0OyAqIExpc3QtcG9zdDogJmx0O21haWx0bzo8QSANCiAgICBocmVmPSJtYWlsdG86YXZ0 QGlldGYub3JnIiANCiAgICB5bWFpbHRvPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5v cmc8L0E+Jmd0OzxCUj4mZ3Q7ICogTGlzdC1zdWJzY3JpYmU6IA0KICAgICZsdDs8QSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dCIgDQogICAgdGFyZ2V0PV9i bGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvQT4mZ3Q7LCAN CiAgICAmbHQ7bWFpbHRvOjxBIGhyZWY9Im1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZyIgDQog ICAgeW1haWx0bz0ibWFpbHRvOmF2dC1yZXF1ZXN0QGlldGYub3JnIj5hdnQtcmVxdWVzdEBpZXRm Lm9yZzwvQT4/c3ViamVjdD1zdWJzY3JpYmUmZ3Q7PEJSPiZndDsgDQogICAgKiBMaXN0LXVuc3Vi c2NyaWJlOiAmbHQ7PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9vcHRpb25z L2F2dCIgDQogICAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL29w dGlvbnMvYXZ0PC9BPiZndDssIA0KICAgICZsdDttYWlsdG86PEEgaHJlZj0ibWFpbHRvOmF2dC1y ZXF1ZXN0QGlldGYub3JnIiANCiAgICB5bWFpbHRvPSJtYWlsdG86YXZ0LXJlcXVlc3RAaWV0Zi5v cmciPmF2dC1yZXF1ZXN0QGlldGYub3JnPC9BPj9zdWJqZWN0PXVuc3Vic2NyaWJlJmd0OzxCUj4m Z3Q7IA0KICAgICogUmVmZXJlbmNlczogJmx0OzRGQjJFMzIzLjMwOTA0MDYgYXQgbm9zdHJ1bS5j b20mZ3Q7PEJSPiZndDsgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ Jmd0OyA8QlI+Jmd0OyBIaSxSb2JlcnQ6PEJSPiZndDsgVGhhbmsgDQogICAgZm9yIHlvdXIgdmFs dWFibGUgcmV2aWV3LiBwbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lIGJlbG93cy4gDQogICAg UmVnYXJkcyE8QlI+Jmd0OyAtUWluPEJSPiZndDsgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSA8QlI+Jmd0OyBGcm9tOiANCiAgICAiUm9iZXJ0IFNwYXJrcyIgJmx0O3Jqc3BhcmtzIGF0IG5v c3RydW0uY29tJmd0OzxCUj4mZ3Q7IFRvOiAiSUVURiBBVlRDb3JlIA0KICAgIFdHIiAmbHQ7YXZ0 IGF0IGlldGYub3JnJmd0OzsgJmx0O2RyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoIGF0IA0KICAg IHRvb2xzLmlldGYub3JnJmd0OzxCUj4mZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDEy IDc6MTMgQU08QlI+Jmd0OyANCiAgICBTdWJqZWN0OiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzICZndDsgDQogICAgU3VtbWFyeTog VGhlcmUgYXJlIGlzc3VlcyB0byByZXNvbHZlIHdpdGggYSByZXZpc2VkIElEIGJlZm9yZSA8QlI+ Jmd0OyZndDsgDQogICAgcHJvZ3Jlc3NpbmcgdG8gSUVURiBMQy48QlI+Jmd0OyZndDsgPEJSPiZn dDsmZ3Q7IEl0J3MgYSBzdHJ1Z2dsZSB0byBzZWUgdGhlIA0KICAgIF9hcmNoaXRlY3R1cmVfIHRo aXMgZG9jdW1lbnQgaXMgc3VwcG9zZWQgdG8gPEJSPiZndDsmZ3Q7IGRlc2NyaWJlLiBJIHN1c3Bl Y3QgDQogICAgbW9zdCBvZiB0aGUgd29ya2luZyBncm91cCBlbmVyZ3kgd2VudCBpbnRvIFNlY3Rp b24gNSA8QlI+Jmd0OyZndDsgKHRoZSANCiAgICBndWlkZWxpbmVzIGZvciB3cml0aW5nIFhSIGJs b2NrIGRlZmluaXRpb25zKSAtIHRoZSByZXN0IG9mIHRoZSA8QlI+Jmd0OyZndDsgDQogICAgZG9j dW1lbnQgbmVlZHMgYSBzaW1pbGFyIGxldmVsIG9mIGF0dGVudGlvbiB0byBkZXRhaWwuPEJSPiZn dDsmZ3Q7IA0KICAgIDxCUj4mZ3Q7Jmd0OyBUaGVyZSBhcmUgdHdvIG1ham9yIGlzc3VlcyB0aGF0 IEkndmUgdGFnZ2VkIHdpdGggYSAoKikuIEkgDQogICAgZm9sbG93ZWQgYSA8QlI+Jmd0OyZndDsg bW9zdGx5IGRvY3VtZW50LW9yZGVyIGZsb3cgaW5zdGVhZCBvZiBncm91cGluZyB0aGUgDQogICAg bWFqb3IgaXNzdWVzIGF0IHRoZSB0b3AuPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyAoKikgR2l2 ZW4gdGhlIGRvY3VtZW50J3MgDQogICAgdGl0bGUsIGl0IHNob3VsZCBiZSB2ZXJ5IGVhc3kgdG8g YW5zd2VyICJXaGF0IDxCUj4mZ3Q7Jmd0OyBpcyB0aGUgbW9uaXRvcmluZyANCiAgICBhcmNoaXRl Y3R1cmU/IiBmb3IgcGVvcGxlIHdobyBhcmUgcmVhZGluZyB0aGlzIGRyYWZ0IDxCUj4mZ3Q7Jmd0 OyBmb3IgdGhlIA0KICAgIGZpcnN0IHRpbWUuPEJSPiZndDsmZ3Q7IFRoZSBrZXkgbWVzc2FnZSBp cyB0aGF0IHRoZSBtb25pdG9yaW5nIGFyY2hpdGVjdHVyZSANCiAgICBjb25zaXN0cyBvZiBNb25p dG9ycyA8QlI+Jmd0OyZndDsgdGhhdCBleGNoYW5nZSBpbmZvcm1hdGlvbiB1c2luZyBSVENQIA0K ICAgIE1ldHJpYyBCbG9ja3MuIFtRaW5dOiBBZ3JlZS4gJmd0O1RoZSB0ZXh0IHNob3VsZCBzYXkg PEJSPiZndDsmZ3Q7IHRoYXQuIA0KICAgIFtRaW5dOiBPa2F5LiAmZ3Q7IFRoZXJlIGlzIGEgbG90 IG9mIHByb3NlIGluIHNlY3Rpb24gMyBhbmQgdmlzdWFsIGRldGFpbCBpbiANCiAgICB0aGUgPEJS PiZndDsmZ3Q7IGRpYWdyYW0gaW4gRmlndXJlIDEgdGhhdCBtYWtlcyB0aGF0IGV4dHJlbWVseSBk aWZmaWN1bHQgdG8gDQogICAgc2VlLiA8QlI+Jmd0OyZndDsgU2ltcGxpZnlpbmcgdGhlIGZpZ3Vy ZSBieSByZW1vdmluZyB0aGUgZGV0YWlscyBhYm91dCANCiAgICBhcHBsaWNhdGlvbnMgYW5kIDxC Uj4mZ3Q7Jmd0OyB0cmFuc3BvcnRzLCBvciBhdCBsZWFzdCBtb3ZpbmcgdGhlbSB0byBhIA0KICAg IHNlY29uZCBmaWd1cmUsIG1ha2luZyB0aGUgPEJSPiZndDsmZ3Q7IE1vbml0b3IgYm94ZXMgc3Rh bmQgb3V0LCBhbmQgbWFraW5nIA0KICAgIHRoZSB0eXBlcyBvZiBpbmZvcm1hdGlvbiBmbG93cyAo dGhlIDxCUj4mZ3Q7Jmd0OyBhcnJvd3MpIHZpc3VhbGx5IA0KICAgIGRpc3RpbmN0aXZlIHdvdWxk IGhlbHAuIFNpbXBsaWZ5IHRoZSBwcm9zZSAobXVjaCBvZiBpdCA8QlI+Jmd0OyZndDsgY291bGQg YmUgDQogICAgcmVtb3ZlZCkgdG8gZm9jdXMgb24gdGhhdCBrZXkgbWVzc2FnZS4gW1Fpbl06IEFn cmVlLCBJIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZSANCiAgICBmaWd1cmUgMSBhbmQgc3F1ZWV6ZSB0 aGUgc2VjdGlvbiAzLjEgYXMgZm9sbG93czogIiAzLjEuIE92ZXJ2aWV3IFRoZSBSVFAgDQogICAg bW9uaXRvcmluZyBhcmNoaXRlY3R1cmUgY29tcHJpc2VzIHRoZSBmb2xsb3dpbmcgdHdvIGtleSBm dW5jdGlvbmFsIA0KICAgIGNvbXBvbmVudHMgc2hvd24gYmVsb3c6IG8gUlRQIE1vbml0b3IgbyBS VFAgTWV0cmljIEJsb2NrIFN0cnVjdHVyZSBSVFAgDQogICAgTW9uaXRvciBpcyB0aGUgZnVuY3Rp b25hbCBjb21wb25lbnQgZGVmaW5lZCBpbiB0aGUgUmVhbC10aW1lIFRyYW5zcG9ydCANCiAgICBQ cm90b2NvbCBbUkZDMzU1MF0uIEl0IGFjdHMgYXMgYSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZ2F0 aGVyZWQgZm9yIA0KICAgIG1vbml0b3JpbmcgcHVycG9zZXMgYW5kIGV4Y2hhbmdlcyBpbmZvcm1h dGlvbiB3aXRoIHRoZSBvdGhlciBSVFAgbW9uaXRvcnMgDQogICAgdXNpbmcgUlRDUCBNZXRyaWMg QmxvY2tzLiBBY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gb2YgbW9uaXRvciBpbiB0aGUgUlRQ IA0KICAgIFByb3RvY29sIFtSRkMzNTUwXSwgdGhlIGVuZCBzeXN0ZW0gdGhhdCBydW5zIGFuIGFw cGxpY2F0aW9uIHByb2dyYW0gdGhhdCANCiAgICBzZW5kcyBvciByZWNlaXZlcyBSVFAgZGF0YSBw YWNrZXRzLCBhbiBpbnRlcm1lZGlhdGUtIHN5c3RlbSB0aGF0IGZvcndhcmRzIA0KICAgIFJUUCBw YWNrZXRzIHRvIEVuZC1kZXZpY2VzIG9yIGEgdGhpcmQgcGFydHkgdGhhdCBvYnNlcnZlcyB0aGUg UlRQIGFuZCBSVENQIA0KICAgIHRyYWZmaWMgYnV0IGRvZXMgbm90IG1ha2UgaXRzZWxmIHZpc2li bGUgdG8gdGhlIFJUUCBTZXNzaW9uIHBhcnRpY2lwYW50cyANCiAgICAoaS5lLiwgdGhlIHRoaXJk IHBhcnR5IG1vbml0b3IgZGVwaWN0ZWQgaW4gZmlndXJlIDEpIGNhbiBhY3QgYXMgdGhlPEJSPiZn dDsgDQogICAgUlRQIG1vbml0b3IuIFRoZSB0aGlyZCBwYXJ0eSBtb25pdG9yIHNob3VsZCBiZSBw bGFjZWQgb24gdGhlIFJUUC9SVENQIHBhdGhzIA0KICAgIGJldHdlZW4gdGhlIHNlbmRlciwgaW50 ZXJtZWRpYXRlIGFuZCB0aGUgcmVjZWl2ZXIuIFRoZSBSVFAgbW9uaXRvciBhbHNvIA0KICAgIGV4 cG9zZXMgcmVhbCB0aW1lIEFwcGxpY2F0aW9uIFFvUy9Rb0UgbWV0cmljIGluZm9ybWF0aW9uIGlu IHRoZSBhcHByb3ByaWF0ZSANCiAgICByZXBvcnQgYmxvY2sgZm9ybWF0IChlLmcuLFJUQ1AgWFIg b3Igb3RoZSBub24tUlRQIG1lYW5zKSB0byB0aGUgbWFuYWdlbWVudCANCiAgICBzeXN0ZW0uIFN1 Y2ggaW5mb3JtYXRpb24gY2FuIGJlIGZvcm11bGF0ZWQgYXMgZGlmZmVyZW50IG1ldHJpYyB0eXBl cywgDQogICAgZS5nLixhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWMsIHRyYW5zcG9ydCBsZXZlbCBt ZXRyaWMsIGVuZCBzeXN0ZW0gbWV0cmljLCANCiAgICBpbnRlcnZhbCBtZXRyaWMsIGN1bXVsYXRp dmUgbWV0cmljLCBzYW1wbGVkIG1ldHJpYywgZGlyZWN0IG1ldHJpYywgY29tcG9zZWQgDQogICAg bWV0cmljLGV0Yy4gQm90aCB0aGUgUlRDUCBvciBSVENQIFhSIGNhbiBiZSBleHRlbmRlZCB0byBj b252ZXkgdGhlc2UgDQogICAgbWV0cmljcy4gVGhlIGRldGFpbHMgb24gdHJhbnNwb3J0IHByb3Rv Y29scyBmb3IgdGhlc2UgbWV0cmljIGFyZSBkZXNjcmliZWQgDQogICAgaW4gU2VjdGlvbiAzLjIu IFJUUCBtYXkgYmUgdXNlZCB0byBtdWx0aWNhc3QgZ3JvdXBzLCBib3RoIEFueSBTb3VyY2UgDQog ICAgTXVsdGljYXN0IChBU00pIGFuZCBTb3VyY2UgU3BlY2lmaWMgTXVsdGljYXN0IChTU00pLiBU aGVzZSBncm91cHMgY2FuIGJlIA0KICAgIG1vbml0b3JlZCB1c2luZyBSVENQLiBJbiB0aGUgQVNN IGNhc2UsIHRoZSBtb25pdG9yIGlzIGEgbWVtYmVyIG9mIHRoZSANCiAgICBtdWx0aWNhc3QgZ3Jv dXAgYW5kIGxpc3RlbnMgdG8gUlRDUCBYUiByZXBvcnRzIGZyb20gYWxsIG1lbWJlcnMgb2YgdGhl IA0KICAgIEFTTTxCUj4mZ3Q7IGdyb3VwLiBJbiB0aGUgU1NNIGNhc2UsIHRoZXJlIGlzIGEgdW5p Y2FzdCBmZWVkYmFjayB0YXJnZXQgdGhhdCANCiAgICByZWNlaXZlcyBSVENQIGZlZWRiYWNrIGZy b20gcmVjZWl2ZXJzIGFuZCBkaXN0cmlidXRlcyBpdCB0byBvdGhlciBtZW1iZXJzIG9mIA0KICAg IHRoZSBTU00gZ3JvdXAgKHNlZSBmaWd1cmUgMSBvZiBSRkM1NzYwKS4gVGhlIG1vbml0b3Igd2ls bCBuZWVkIHRvIGJlIA0KICAgIGNvLWxvY2F0ZWQgd2l0aCB0aGUgZmVlZGJhY2sgdGFyZ2V0IHRv IHJlY2VpdmUgYWxsIGZlZWRiYWNrIGZyb20gdGhlIA0KICAgIHJlY2VpdmVycyAodGhpcyBtYXkg YWxzbyBiZSBhbiBpbnRlcm1lZGlhdGUgc3lzdGVtKS4gSW4gYm90aCBBU00gYW5kIFNTTSANCiAg ICBzY2VuYXJpb3MsIHJlY2VpdmVycyBjYW4gc2VuZCBSVENQIFhSIHJlcG9ydHMgdG8gZW5oYW5j ZSB0aGUgcmVjZXB0aW9uIA0KICAgIHF1YWxpdHkgcmVwb3J0aW5nLiAiICZndDsgSW4gdGhlIGRl ZmluaXRpb24gb2YgQ29tcG9zZWQgbWV0cmljcywgdGhlIA0KICAgIHNlbnRlbmNlICJBbiBleGFt cGxlIGlzIGEgPEJSPiZndDsmZ3Q7IG1ldHJpYyBjYWxjdWxhdGVkIGJhc2VkIG9uIGRlcml2ZWQg DQogICAgbWV0cmljcyB0aGF0IGhhdmUgYmVlbiBtZWFzdXJlZC4iIDxCUj4mZ3Q7Jmd0OyBtYWtl cyBsaXR0bGUgc2Vuc2UuIFtRaW5dIFRoZSANCiAgICBkZXJpdmVkIG1ldHJpY3MgaW4gdGhlIHNl bnRlbmNlIHNob3VsZCBiZWVuIGNvcnJlY3RlZCBhcyAiZGlyZWN0IG1ldHJpYyIuIA0KICAgICZn dDtEaWQgeW91IG1lYW4gc29tZXRoaW5nIGxpa2UgIkFuIGV4YW1wbGUgaXMgYSBtZXRyaWMgPEJS PiZndDsmZ3Q7IGRlcml2ZWQgDQogICAgYnkgYWxnb3JpdGhtaWNhbGx5IGNvbWJpbmluZyBtZWFz dXJlZCBtZXRyaWNzLiI/IFtRaW5dOkkgYWdyZWUgd2l0aCB5b3VyIA0KICAgIHN1Z2dlc3RlZCB0 ZXh0IGFuZCBsaWtlIHRvIGFkb3B0IHlvdXIgc3VnZ2VzdGlvbi4gJmd0OyBUaGUgZGVmaW5pdGlv bnMgb2YgDQogICAgSW50ZXJ2YWwsIEN1bXVsYXRpdmUsIGFuZCBTYW1wbGVkIG1ldHJpY3MgYXJl IG5vdCBjbGVhci4gW1Fpbl06IEkgYWdyZWUgdGhlIA0KICAgIGRlZmluaXRpb24gZm9yIHRoZXNl IHRocmVlIG1ldHJpY3MgbmVlZCB0byBiZSBtb3JlIGNsZWFlciwgSSBwcm9wb3NlcyB0byBkbyAN CiAgICB0aGUgZm9sbG93aW5nIGNoYW5nZXM6IE5FVyBUZXh0OiAiIEludGVydmFsIG1ldHJpY3Mg TWV0cmljcyBvZiB3aGljaCB0aGUgDQogICAgcmVwb3J0ZWQgdmFsdWVzIGFyZSBtZWFzdXJlZCBp biB0aGUgbW9zdCByZWNlbnQgbWVhc3VyZW1lbnQgaW50ZXJ2YWwgDQogICAgZHVyYXRpb24gYmV0 d2VlbiBzdWNjZXNzaXZlIG1ldHJpY3MgcmVwb3J0cy4gU3VjaCBtZWFzdXJlbWVudCBpbnRlcnZh bCBpcyANCiAgICBlcXVhbCB0byBvbmUgUlRDUCByZXBvcnQgaW50ZXJ2YWwgKFJGQzM1NTAsU2Vj dGlvbiA2LjIpLiBDdW11bGF0aXZlIG1ldHJpY3MgDQogICAgTWV0cmljcyBvZiB3aGljaCB0aGUg cmVwb3J0ZWQgdmFsdWVzIGFwcGx5IHRvIHRoZSBhY2N1bXVsYXRpb24gcGVyaW9kIA0KICAgIGNo YXJhY3RlcmlzdGljIG9mIGN1bXVsYXRpdmUgbWVhc3VyZW1lbnRzLiBUaGUgcmVwb3J0ZWQgdmFs dWVzIGFyZSBtZWFzdXJlZCANCiAgICBkdXJpbmcgdGhlIGFjY3VtdWxhdGlvbiBwZXJpb2QuIFRo ZSBhY2N1bXVsYXRpb24gcGVyaW9kIHNwYW5zIG92ZXIgbW9yZSB0aGFuIA0KICAgIG9uZSBSVENQ IHJlcG9ydCBpbnRlcnZhbHMuIFNhbXBsZWQgbWV0cmljcyBNZXRyaWNzIG9mIHdoaWNoIHRoZSBy ZXBvcnRlZCANCiAgICB2YWx1ZXMgb25seSBhcHBseSB0byB0aGUgdmFsdWUgb2YgYSBjb250aW51 b3VzbHkgbWVhc3VyZWQgb3I8QlI+Jmd0OyANCiAgICBjYWxjdWxhdGVkIG1ldHJpYyB0aGF0IGhh cyBiZWVuIHNhbXBsZWQgYXQgYW55IGdpdmVuIGluc3RhbmNlIG9mIHRoZSBSVENQIA0KICAgIHJl cG9ydCBpbnRlcnZhbC4gT25lIGV4YW1wbGUgb2Ygc3VjaCBtZXRyaWMgaXMgdGhlIGludGVyLWFy cml2YWwgaml0dGVyIA0KICAgIGRlc2NyaWJlZCBpbiB0aGUgc2VjdGlvbiA2LjQuMSBvZiBSRkMz NTUwLiAiICZndDsgSWYgdGhlIGRpc2N1c3Npb24gYXQgdGhlIA0KICAgIGVuZCBvZiBzZWN0aW9u IDMuMSBpcyBrZXB0LCB0aGUgcmVmZXJlbmNlIHRvIDxCUj4mZ3Q7Jmd0OyBSRkM1NzYwIHNob3Vs ZCBiZSANCiAgICBhIHJlYWwgcmVmZXJlbmNlLCBhbmQgUkZDNTc2MCBzaG91bGQgYXBwZWFyIGlu IHRoZSA8QlI+Jmd0OyZndDsgcmVmZXJlbmNlIA0KICAgIHNlY3Rpb24uIFtRaW5dOiBPa2F5LiAm Z3Q7IFRoZSBwb2ludCBvZiBzZWN0aW9uIDMuMiBpcyBub3Qgb2J2aW91cy4gSG93IGRvZXMgDQog ICAgaXQgY29udHJpYnV0ZSB0byB0aGUgPEJSPiZndDsmZ3Q7IGRlc2NyaXB0aW9uIG9mIHRoZSBh cmNoaXRlY3R1cmUuIEl0IG1peGVzIA0KICAgIHRhbGtpbmcgYWJvdXQgd2hhdCByZXBvcnQgPEJS PiZndDsmZ3Q7IGJsb2NrcyBhcmUgd2l0aCBvY2Nhc2lvbmFsbHkgbmVlZGluZyANCiAgICB0byBz ZW5kIHRoZW0gbW9yZSBmcmVxdWVudGx5LiBUaG9zZSA8QlI+Jmd0OyZndDsgcG9pbnRzIGNvdWxk IGJlIG1hZGUgDQogICAgc2VwYXJhdGVseSBhbmQgbW9yZSBzaW1wbHkuIFtRaW5dOiBPa2F5LiBJ IGxpa2UgdG8gaW5jb3Jwb3JhdGUgdGhlIGtleSANCiAgICBwb2ludHMgaW4gdGhlIHNlY3Rpb24g My4yIGludG8gc2VjdGlvbiAzLjEgJmd0OyBTZWN0aW9uIDMuMyBpcyBub3QgY2xlYXIgLSANCiAg ICBpdCBzdGFydHMgb2ZmIHNheWluZyB0aGF0IHRoZSBsb2NhdGlvbiBvZiB0aGUgPEJSPiZndDsm Z3Q7IHNlbmRlciBhbmQgDQogICAgcmVjZWl2ZXIgbWF5IGNoYW5nZSB3aGF0IG1ldHJpY3MgYXJl IG1lYW5pbmdmdWwuIEl0J3Mgbm90IDxCUj4mZ3Q7Jmd0OyBjbGVhciANCiAgICB3aGF0IHlvdSBt ZWFuIGJ5IGxvY2F0aW9uLiBZb3UgY2VydGFpbmx5IGRvbid0IG1lYW4gZ2Vvc3BhdGlhbCA8QlI+ Jmd0OyZndDsgDQogICAgY29vcmRpbmF0ZXMuIERvIHlvdSBtZWFuIGFueXRoaW5nIG90aGVyIHRo YW4gd2hldGhlciB0aGUgZWxlbWVudCBpcyANCiAgICA8QlI+Jmd0OyZndDsgdHJ1c3RlZCBvciB1 bnRydXN0ZWQgYnkgdGhlIG9wZXJhdGlvbnMgbmV0d29yaz8gSWYgc28sIHNheSANCiAgICB0aGF0 LiBUaGUgPEJSPiZndDsmZ3Q7IHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBvbmx5IHNwZWFrcyB0byB3 aGF0IGVsZW1lbnQgDQogICAgY29sbGVjdHMgdGhlIG1ldHJpY3MuIFtRaW5dIFNlY3Rpb24gMy4z IGlzIG9ubHkgdXNlZCB0byBkZXNjcmliZSB3aGVyZSBvciANCiAgICBmcm9tIHdoaWNoIFJUUCBl bnRpdHkgdG8gZ2F0aGVyIHRoZSBtZXRyaWNzIChpLmUuLCBtZWFzdXJlbWVudCBwb2ludCkgaW4g dGhlIA0KICAgIHBoeXNpY2FsIG5ldHdvcmsgYW5kIGlzIG5vdCBmb2N1cyBvZiB0aGlzIGRvY3Vt ZW50LiBTZWNvbmRseSwgSSB0aGluayB0aGUgDQogICAgZGVmaW5pdGlvbiBvZiBhcHBsaWNhdGlv biBsZXZlbCBtZXRyaWNzIGhhcyBhbHJlYWR5IGNsYXJpZmllZCB0aGF0IA0KICAgIGFwcGxpY2F0 aW9uIGxldmVsIG1ldHJpY3MgaXMgbm9ybWFsbHkgZ2F0aGVyZWQgZnJvbSB1c2VyIGVuZHBvaW50 LiAmZ3Q7IEl0J3MgDQogICAgbm90IGNsZWFyIHRoYXQgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1l dHJpY3MgaXMgY2hhbmdlZCBhdCBhbGwgLSANCiAgICA8QlI+Jmd0OyZndDsganVzdCB3aGVyZSB5 b3UgY29sbGVjdCB0aGVtLiBJZiB0aGUgc2V0IG9mIG1lYW5pbmdmdWwgbWV0cmljcyANCiAgICBk b2VzIGluIDxCUj4mZ3Q7Jmd0OyBmYWN0IGNoYW5nZSwgdGhlcmUgbmVlZHMgdG8gYmUgYWRkaXRp b25hbCBkaXNjdXNzaW9uIA0KICAgIGhlcmUuIFtRaW5dOiBUaGUgbWV0cmljcyBhY3R1YWxseSBk b2Vzbid0IGNoYW5nZS5TaW5jZSB0aGUgZGVmaW5pdGlvbiBvZiANCiAgICBhcHBsaWNhdGlvbiBs ZXZlbCBtZXRyaWNzIEhhdmUgYWxyZWFkeSBjb252ZXllZCB0aGUgbWVhbmluZyBvZiB3aGF0IHNl Y3Rpb24gDQogICAgMy4zIHdhbnRzIHRvIGRlc2NyaWJlLCBJIHByb3Bvc2UgdG8gcmVtb3ZlIHRo aXMgc2VjdGlvbi4gJmd0OyBTZWN0aW9uIDQncyANCiAgICBmaXJzdCBwYXJhZ3JhcGg6IElzICJw cm9iYWJseSIgdGhlIGJlc3QgdGhlIHdvcmtpbmcgZ3JvdXAgPEJSPiZndDsmZ3Q7IGNhbiANCiAg ICBzYXk/IFtRaW5dOk5vLCB3aWxsIHJlbW92ZSB0aGlzIHdvcmQuICZndDsgVGhlIGxhc3QgdHdv IHNlbnRlbmNlcyBvZiB0aGUgDQogICAgc2Vjb25kIGJ1bGxldCBpbiBzZWN0aW9uIDQgZG8gbm90 IHBhcnNlLiA8QlI+Jmd0OyZndDsgUGxlYXNlIHNpbXBsaWZ5IHRoZW0uIA0KICAgIFtRaW5dOiBP a2F5LCBob3cgYWJvdXQgY2hhbmdlIHRoZW0gYXMgZm9sbG93czogTkVXIFRleHQ6ICIgV2l0aCB0 aGVzZSANCiAgICBtaW5pbWFsIG51bWJlciBvZiBSVENQIHN0YXRpc3RpY3MgcGFyYW1ldGVycyBt YXBwZWQgdG8gbm9uLVJUQ1AgDQogICAgbWVhc3VyZW1lbnRzLCBpdCBpcyBoYXJkIHRvIHByb3Zp ZGUgYWNjdXJhdGUgbWVhc3VyZXMgb2YgcmVhbCB0aW1lIA0KICAgIGFwcGxpY2F0aW9uIHF1YWxp dHksY29uZHVjdCBkZXRhaWxlZCBkYXRhIGFuYWx5c2lzIGFuZCBjcmVhdGVzIGFsZXJ0cyB0aW1s eSANCiAgICB0byB0aGUgdXNlcnMuIFRoZXJlZm9yZSBjb3JyZWxhdGlvbiBiZXR3ZWVuIFJUQ1Ag WFIgYW5kIG5vbi1SVFAgZGF0YSBzaG91bGQgDQogICAgYmUgcHJvdmlkZWQuICIgJmd0OyBUaGUg Zmlyc3QgZnVsbCBzZW50ZW5jZSBvZiB0aGUgdGhpcmQgYnVsbGV0IGluIHNlY3Rpb24gNCANCiAg ICBkb2VzIG5vdCBtYWtlIDxCUj4mZ3Q7Jmd0OyBzZW5zZS4gVGhlIHdob2xlIGJ1bGxldCBjb3Vs ZCBiZSBjbGFyaWZpZWQuIA0KICAgIFtRaW5dOiBBZ3JlZSBhbmQgd2lsbCByZW1vdmUgdGhlIGZp cnN0IHNlbnRlbmNlLiAmZ3Q7IFRoZSBmb3VydGggYnVsbGV0IGluIA0KICAgIHNlY3Rpb24gNCBh bmQgc2VjdGlvbiA1LjUgc2hvdWxkIGNhbGwgb3V0IHRoYXQgPEJSPiZndDsmZ3Q7IFJGQzM2MTEg YWxyZWFkeSANCiAgICBzZXQgQmxvY2sgVHlwZSAyNTUgYXNpZGUgZm9yIGZ1dHVyZSBleHRlbnNp b25zLCA8QlI+Jmd0OyZndDsgYW50aWNpcGF0aW5nIA0KICAgIHRoZSBwb3RlbnRpYWwgbmVlZCB0 byBleHRlbmQgdGhlIGJsb2NrIHR5cGUgc3BhY2UuIFtRaW5dOiBPa2F5LCBIb3cgYWJvdXQgDQog ICAgcmV2aXNpbmcgdGhlIHNlY3Rpb24gNCxidWxsZXQgNCBhcyBmb2xsb3dzOiAiIENvbnN1bXB0 aW9uIG9mIFhSIGJsb2NrIGNvZGUgDQogICAgcG9pbnRzLiBUaGUgUlRDUCBYUiBibG9jayBuYW1l c3BhY2UgaXMgbGltaXRlZCBieSB0aGUgOC1iaXQgYmxvY2sgdHlwZSBmaWVsZCANCiAgICBpbiB0 aGUgUlRDUCBYUiBoZWFkZXIuIFNwYWNlIGV4aGF1c3Rpb24gbWF5IGJlIGEgY29uY2VybiBpbiB0 aGUgZnV0dXJlLiANCiAgICBBbnRpY2lwYXRpbmcgdGhlIHBvdGVudGlhbCBuZWVkIHRvIGV4dGVu ZCB0aGUgYmxvY2sgdHlwZSBzcGFjZSwgaXQgaXMgbm90ZWQgDQogICAgaW4gW1JGQzM2MTFdIHRo YXQgQmxvY2sgVHlwZSAyNTUgaXMgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSBleHRlbnNpb25zLCAiICZn dDsgDQogICAgSW4gc2VjdGlvbiA1LCBjb25zaWRlciBuYW1pbmcgdGhlIHN1YnNlY3Rpb25zIHdp dGggdGhlIGFjdHVhbCBndWlkZWxpbmUgDQogICAgPEJSPiZndDsmZ3Q7IGluc3RlYWQgb2YgdGhl IHByb2JsZW0gdGhlIGd1aWRlbGluZSBpcyB0cnlpbmcgdG8gDQogICAgYWRkcmVzcy48QlI+Jmd0 OyZndDsgNS4xLiBNZXRyaWMgYmxvY2tzIHNob3VsZCBjb250YWluIGEgc2luZ2xlIG1ldHJpYyAN CiAgICBbUWluXTogSSBzdWdnZXN0IHRvIGNoYW5nZSBpdCBhcyAiQ29udGFpbiB0aGUgc2luZ2xl IG1ldHJpY3MgaW4gdGhlIG1ldHJpYyANCiAgICBibG9jayIgJmd0OyA1LjIuIEluY2x1ZGUgdGhl IHBheWxvYWQgdHlwZSBhbmQgZm9ybWF0IHBhcmFtZXRlcnMgaW4gdGhlIA0KICAgIG1ldHJpYyBi bG9jayBbUWluXTogT2theS4gJmd0OyA1LjMuIFVzZSBSVENQIFNERVMgdG8gY29ycmVsYXRlIFhS IHJlcG9ydHMgDQogICAgd2l0aCBub24tUlRQIGRhdGEgW1Fpbl06IE9rYXkuICZndDsgNS40LiBE b24ndCByZXBlYXQgbWVhc3VyZW1lbnQgDQogICAgaW5mb3JtYXRpb24gYWNyb3NzIG1ldHJpYyBi bG9ja3M8QlI+Jmd0OyZndDsgPEJSPiZndDsgW1Fpbl06IEl0IGlzIG5vdCANCiAgICBwb3NzaWJs ZSBjb21wbGV0ZWx5IHRvIGF2b2lkIG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIHJlcGVhdGl0aW9u LiBlLmcuLCBmb3IgDQogICAgcGFja2V0IGxvc3Mgcm9idXN0bmVzcyBpZiB0aGUgcmVwb3J0IGJs b2NrcyBmb3IgdGhlIHNhbWUgaW50ZXJ2YWwgc3BhbiBvdmVyIA0KICAgIG1vcmUgdGhhbiBvbmUg UlRDUCBwYWNrZXQgdGhlbiBlYWNoIG11c3QgaGF2ZSB0aGUgc2FtZSBtZWFzdXJlbWVudCBpZGVu dGl0eSANCiAgICBpbmZvcm1hdGlvbiBTbyBJIHN1Z2dlc3QgdG8gY2hhbmdlIGl0IGFzOiAicmVk dWNlIG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIA0KICAgIGFjcm9zcyBtZXRyaWMgYmxvY2tzIiAm Z3Q7IFRoaXMgcG9pbnRzIG91dCBhIHN0cnVjdHVyYWwgcHJvYmxlbSB3aXRoIHRoZSANCiAgICBz ZWN0aW9uLiBXaHkgaXMgNS41IGhlcmU/IDxCUj4mZ3Q7Jmd0OyBJdCdzIG5vdCBhIGd1aWRlbGlu ZS4gW1Fpbl06IEFncmVlIA0KICAgIGFuZCBhbHNvIGFzIGRpc2N1c3NlZCxTcGFjZSBleGhhdXN0 aW9uIGlzIG5vdCBiaWcgaXNzdWUuIEhvdyBhYm91dCByZW1vdmUgDQogICAgdGhpcyBzZWN0aW9u PyAmZ3Q7ICgqKSBBbmQgaXQgcmFpc2VzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUgZG9jdW1l bnQgaXMgDQogICAgdHJ5aW5nIHRvIDxCUj4mZ3Q7Jmd0OyBhY2hpZXZlIHdpdGggc2VjdGlvbiA1 LjQuIFRoYXQgc2VjdGlvbiBjbGFpbXMgdGhlIA0KICAgIGRvY3VtZW50IGlzIHByb3Bvc2luZyA8 QlI+Jmd0OyZndDsgYSBuZXcgWFIgYmxvY2sgdHlwZSB0byBoZWxwIGF2b2lkIA0KICAgIGR1cGxp Y2F0aW9uLCBidXQgaXQgZG9lc24ndCBhY3R1YWxseSA8QlI+Jmd0OyZndDsgZGVmaW5lIHRoZSBu ZXcgYmxvY2sgdHlwZS4gDQogICAgSXMgdGhlIGd1aWRlbGluZSBzYXlpbmcgc2ltcGx5IGRvbid0 IHJlcGVhdCA8QlI+Jmd0OyZndDsgbWVhc3VyZW1lbnRzIG9yIGl0cyANCiAgICB0aGUgZ3VpZGVs aW5lIHNheWluZyAidXNlIHRoaXMgbmV3IFhSIGJsb2NrIHR5cGUgd2UgPEJSPiZndDsmZ3Q7IGhh dmVuJ3QgDQogICAgZGVmaW5lZCB5ZXQiPyBbUWluXTogSnVzdCB0byBjbGFyaWZ5LCB3ZSBoYXZl IGFscmVhZHkgZGVmaW5lZCBvbmUgbmV3IFhSIA0KICAgIEJsb2NrIHR5cGUgdG8gaGVscCBhdm9p ZCBvciByZWR1Y2UgZHVwbGljYXRpb24uIEl0IGlzIG1lYXN1cmVtZW50IA0KICAgIGluZm9ybWF0 aW9uIGJsb2NrLiBUaGUgcmVsZXZhbnQgZHJhZnQgaXMgYXZhaWxhYmxlIGF0OiA8QSANCiAgICBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14 ci1tZWFzLWlkZW50aXR5LTA2IiANCiAgICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLW1lYXMtaWRlbnRpdHktMDY8L0E+ IA0KICAgICZndDtUaGUgc2VjdGlvbiBuZWVkcyBtb3JlIGNsYXJpdHkuIElmIGl0IHJlYWxseSBp cyA8QlI+Jmd0OyZndDsgdHJ5aW5nIHRvIA0KICAgIGRlZmluZSBhIG5ldyB0eXBlLCB0aGVyZSdz IG1vcmUgd29yayB0byBiZSBkb25lLiBbUWluXTogSW4gb3JkZXIgdG8gYXZvaWQgDQogICAgc3Vj aCBjb25mdXNpb24sIEkgcHJvcG9zZWQgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhl IHNlY3Rpb24gNS40OiANCiAgICBPTEQgVGV4dDogIiBUaGlzIG1lbW8gcHJvcG9zZXMgdG8gZGVm aW5lIGEgbmV3IFhSIEJsb2NrIHRoYXQgd2lsbCBiZSB1c2VkIHRvIA0KICAgIGNvbnZleSB0aGUg Y29tbW9uIHRpbWUgcGVyaW9kIGFuZCB0aGUgbnVtYmVyIG9mIHBhY2tldHMgc2VudCBkdXJpbmcg dGhpcyANCiAgICBwZXJpb2QuICIgTmV3IHRleHQ6ICIgVGhpcyBtZW1vIHByb3Bvc2VzIHRvIGRl ZmluZSBhIG5ldyBYUiBCbG9jayAoaS5lLiwgdGhlIA0KICAgIE1lYXN1cmVtZW50IGluZm9ybWF0 aW9uIGJsb2NrW0kuRC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLWlkZW50aXR5XSkgdGhhdCAN CiAgICB3aWxsIGJlIHVzZWQgdG8gY29udmV5IHRoZSBjb21tb24gdGltZSBwZXJpb2QgYW5kIHRo ZSBudW1iZXIgb2YgcGFja2V0cyBzZW50IA0KICAgIGR1cmluZyB0aGlzIHBlcmlvZC4gIiAmZ3Q7 IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBwYXJ0aWN1bGFybHkgDQogICAg dGhlIHRoaXJkIHBhcmFncmFwaCwgPEJSPiZndDsmZ3Q7IG5lZWRzIHRvIGJlIGNsZWFyZXIuIFdo YXQgZXhhY3RseSBkbyB5b3UgDQogICAgbWVhbiBieSAibW9uaXRvcmluZyBzaG91bGQgYmUgPEJS PiZndDsmZ3Q7IHByb2hpYml0ZWQiLCBhbmQgaG93IGlzIHRoZSBmYWN0IA0KICAgIHRoYXQgdGhp cmQgcGFydHkgbW9uaXRvcnMgZG9uJ3Qgc2VuZCA8QlI+Jmd0OyZndDsgUlRDUCByZWxldmFudD8g RGlkIHlvdSANCiAgICBpbnRlbmQgdGhvc2UgdG8gYmUgc2VwYXJhdGUgcG9pbnRzPyBbUWluXTog WWVzLCB0aGV5IGFyZSBvbiB0aGUgZGlmZmVyZW50IA0KICAgIHBvcnQuIFN1Y2ggbW9uaXRvciBt YXkgcmVjZWl2ZSBSVFAgcGFja2V0IGJ1dCBkb2VzIG5vdCBzZW5kIFJUQ1AgcGFja2V0LiANCiAg ICAmZ3Q7IEVkaXRvcmlhbCBOaXRzIGFuZCBTdWdnZXN0aW9uczo8QlI+Jmd0OyZndDsgPEJSPiZn dDsmZ3Q7IFRoZSBmaXJzdCANCiAgICBwYXJhZ3JhcGggb2YgdGhlIGludHJvZHVjdGlvbiBpcyBv dmVybHkgY29tcGxleCwgYW5kIHdvbid0IGFnZSA8QlI+Jmd0OyZndDsgDQogICAgd2VsbC4gSSBz dWdnZXN0IHJlcGxhY2luZyBpdCB3aXRoOiAiTXVsdGltZWRpYSBzZXJ2aWNlcyB1c2luZyB0aGUg DQogICAgPEJSPiZndDsmZ3Q7IFJlYWwtVGltZSBQcm90b2NvbCAoUlRQKSBhcmUgc2VlaW5nIGlu Y3JlYXNlZCB1c2UuIFN0YW5kYXJkIA0KICAgIG1ldGhvZHMgZm9yIDxCUj4mZ3Q7Jmd0OyBnYXRo ZXJpbmcgUlRQIHBlcmZvcm1hbmNlIG1ldHJpY3MgZnJvbSB0aGVzZSANCiAgICBhcHBsaWNhdGlv bnMgYXJlIG5lZWRlZCB0byA8QlI+Jmd0OyZndDsgbWFuYWdlIHVuY2VydGFpbnRpZXMgaW4gdGhl IGJlaGF2aW9yIA0KICAgIGFuZCBhdmFpbGFiaWxpdHkgb2YgdGhlaXIgPEJSPiZndDsmZ3Q7IHNl cnZpY2VzLiIgVGhlbiByZXBsYWNlICJUaGVzZSANCiAgICByYXBpZGx5IGVtZXJnaW5nIHN0YW5k YXJkcywiIHdpdGggPEJSPiZndDsmZ3Q7ICJTdGFuZGFyZHMiLiBbUWluXTogT2theS4gDQogICAg Jmd0OyBJbnRyb2R1Y3Rpb24gcGFyYWdyYXBoIDMgc2VudGVuY2UgMiBzaG91bGQgc3RhcnQgIlRo ZSBSVENQIEd1aWRlbGluZXMgDQogICAgPEJSPiZndDsmZ3Q7IFtSRkM1OTY4XSIuIEl0IHdvdWxk IGJlIGV2ZW4gYmV0dGVyIHRvIHVzZSB0aGUgZnVsbCB0aXRsZSBmcm9tIA0KICAgIDU5Njg6IDxC Uj4mZ3Q7Jmd0OyAnVGhlICJHdWlkZWxpbmVzIGZvciBFeHRlbmRpbmcgdGhlIFJUUCBDb250cm9s IFByb3RvY29sIA0KICAgIChSVENQKSIgW1JGQzU5NjhdJyBbUWluXTogT2theS4gJmd0OyBUaGlz IG1heSBiZWNvbWUgbW9vdCBhcyBzZWN0aW9uIDMgaXMgDQogICAgbW9kaWZpZWQgdG8gbWFrZSBp dHMgbWFpbiBwb2ludCA8QlI+Jmd0OyZndDsgbW9yZSBvYnZpb3VzLCBidXQgUkZDMzU1MCBkb2Vz IA0KICAgIG5vdCBjaGFyYWN0ZXJpemUgTW9uaXRvcnMgYXMgImEgc291cmNlIG9mIDxCUj4mZ3Q7 Jmd0OyBpbmZvcm1hdGlvbiIuIFRoYXQgDQogICAgY291bGQgYmUgbWlzdW5kZXJzdG9vZC4gUGxl YXNlIGNob29zZSBhbm90aGVyIHdvcmQuIDxCUj4mZ3Q7Jmd0OyBQZXJoYXBzIA0KICAgICJyZXBv c2l0b3J5Ij8gW1Fpbl06IE9rYXksIHJlcG9zaXRvcnkgbG9va3MgZ29vZCB0byBtZS4gJmd0OyBJ biBidWxsZXQgDQogICAgbGlzdHMsIHN0YXJ0aW5nIGFuIGVudHJ5IHdpdGggIm9yIiBvciAiYW5k IiBpcyB1bm5lY2Vzc2FyeS4gSXQgPEJSPiZndDsmZ3Q7IA0KICAgIHNob3VsZCBiZSBjbGVhciBm cm9tIHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIGxpc3Qgd2hldGhlciB0aGUgaW5kaXZpZHVhbCAN CiAgICA8QlI+Jmd0OyZndDsgZW50cmllcyBzaG91bGQgYmUgY29tYmluZWQgb3Igc2VsZWN0ZWQg ZnJvbS4gW1Fpbl06IE9rYXkuICZndDsgDQogICAgSW4gc2VjdGlvbiAzLjEgd2hlcmUgeW91IHNh eSAiUlRQIG1heSBiZSB1c2VkIHRvIG11bHRpY2FzdCBncm91cHMiIGRpZCANCiAgICA8QlI+Jmd0 OyZndDsgeW91IG1lYW4gIlJUUCBtYXkgYmUgc2VudCB0byBtdWx0aWNhc3QgZ3JvdXBzIiBvciAi UlRQIG1heSBiZSANCiAgICB1c2VkIHdpdGggPEJSPiZndDsmZ3Q7IG11bHRpY2FzdCBncm91cHMi PyBbUWluXTogSSB0aGluayBpdCBzaG91bGQgYmUgdGhlIA0KICAgIGxhdHRlciBjYXNlLGkuZS4s IiBSVFAgbWF5IGJlIHVzZWQgd2l0aCA8QlI+Jmd0OyBtdWx0aWNhc3QgZ3JvdXBzIi4gJmd0OyAN CiAgICA8QlI+Jmd0OyZndDsgSW4gc2VjdGlvbiAzLjIgIlRoZSBmb2xsb3dpbmcgYXJlIGZvdXIg dXNlIGNhc2VzIGJ1dCBhcmUgbm90IA0KICAgIGxpbWl0ZWQgPEJSPiZndDsmZ3Q7IHRvOiIgZG9l cyBub3QgcGFyc2UuIFRoZSBidWxsZXRzIGFyZW4ndCByZWFsbHkgdXNlIA0KICAgIGNhc2VzIGFz IG11Y2ggYXMgdGhleSA8QlI+Jmd0OyZndDsgYXJlIG1lY2hhbmlzbXMuIFdvdWxkIGl0IG1ha2Ug bW9yZSBzZW5zZSANCiAgICB0byBzYXkgIkhlcmUgYXJlIGZvdXIgPEJSPiZndDsmZ3Q7IG1lY2hh bmlzbXMgdGhhdCBoYXZlIGJlZW4gY3JlYXRlZCB0byANCiAgICBhZGRyZXNzIHRoZSBuZWVkIGZv ciBtb3JlIGZyZXF1ZW50IDxCUj4mZ3Q7Jmd0OyByZXBvcnRpbmcuIFRoaXMgbGlzdCBpcyBub3Qg DQogICAgaW50ZW5kZWQgdG8gYmUgZXhoYXVzdGl2ZS4iIFRoZSB0aGlyZCBidWxsZXQgPEJSPiZn dDsmZ3Q7IGluIHRoYXQgbGlzdCANCiAgICBzaG91bGQgc2F5ICJSVENQIGFuZCBSVENQIFhSIGFy ZSIgaW5zdGVhZCBvZiAiUlRDUCBvciBSVENQIDxCUj4mZ3Q7Jmd0OyBYUiANCiAgICBpcyIuIFtR aW5dOiBPa2F5LCBidXQgSSBoYXZlIGluY29ycG9yYXRlZCB0aGUga2V5cG9pbnRzIG9mIHNlY3Rp b24gMy4yIGludG8gDQogICAgc2VjdGlvbiAzLjEuICZndDsgVGhlIGJ1bGxldHMgaW4gc2VjdGlv biA0IHdvdWxkIGJlIGJldHRlciBhcyBzdWJzZWN0aW9ucyANCiAgICB3aXRoIHRpdGxlcyA8QlI+ Jmd0OyZndDsgKHRha2VuIGZyb20gdGhlIGZpcnN0IHBocmFzZSBvZiB0aGUgYnVsbGV0KS4gW1Fp bl06IA0KICAgIE9rYXkuICZndDsgSSBzdWdnZXN0IHRoaXMgYWx0ZXJuYXRpdmUgZm9yIHRoZSBm aXJzdCBmdWxsIHNlbnRlbmNlIGluIHRoZSANCiAgICBmaXJzdCA8QlI+Jmd0OyZndDsgYnVsbGV0 IG9mIHNlY3Rpb24gNCA6ICJBIGNvbXBvdW5kIG1ldHJpY3MgYmxvY2sgaXMgDQogICAgZGVzaWdu ZWQgdG8gY29udGFpbiBhIDxCUj4mZ3Q7Jmd0OyBsYXJnZSBudW1iZXIgb2YgcGFyYW1ldGVycyBm cm9tIGRpZmZlcmVudCANCiAgICBjbGFzc2VzIGZvciBhIHNwZWNpZmljIDxCUj4mZ3Q7Jmd0OyBh cHBsaWNhdGlvbiBpbiBhIHNpbmdsZSBibG9jay4iIFtRaW5dOiANCiAgICBPa2F5LiAmZ3Q7IFNl Y3Rpb24gNSdzIHRpdGxlIHNob3VsZCBiZSAiR3VpZGVsaW5lcyBmb3IgcmVwb3J0aW5nIiBpbnN0 ZWFkIG9mIA0KICAgIDxCUj4mZ3Q7Jmd0OyAiR3VpZGVsaW5lIGZvciByZXBvcnRpbmciIFtRaW5d OiBPa2F5LiAmZ3Q7IEluIHNlY3Rpb24gNS4xIEkgDQogICAgc3VnZ2VzdCAianVzdGlmeSB0aGUg b3ZlcmhlYWQsIiBpbnN0ZWFkIG9mICJqdXN0aWZ5IHRoZSA8QlI+Jmd0OyZndDsgDQogICAgb3Zl cmhlYWRzLCIgW1Fpbl06IE9rYXkuICZndDsgU2VjdGlvbiA3IC0gdGhlIGxhc3Qgc2VudGVuY2Ug b2YgdGhlIGZpcnN0IA0KICAgIHBhcmFncmFwaCBkb2VzIG5vdCBwYXJzZS4gVGhlIDxCUj4mZ3Q7 Jmd0OyBzZWNvbmQgcGFyYWdyYXBoICh3aGljaCBpcyBhIA0KICAgIHNpbmdsZSBzZW50ZW5jZSkg c2hvdWxkIGJlIGNsYXJpZmllZCAtIGFuIDxCUj4mZ3Q7Jmd0OyBNQ1UgaXMgbm90IGEgDQogICAg dG9wb2xvZ3kuIFtRaW5dOiBPa2F5LiBIb3cgYWJvdXQgcmV2aXNpbmcgdGhlbSBhcyBmb2xsb3dz OiBPTEQgVGV4dDogIiBUaGUgDQogICAgdG9wb2xvZ2llcyBpbiB0aGlzIGNhdGVnb3J5IGFyZSBU b3BvLVZpZGVvLVN3aXRjaC1NQ1UgYW5kIA0KICAgIFRvcG8tUlRDUC10ZXJtaW5hdGluZy1NQ1Uu IFN1Y2ggdG9wb2xvZ2llcyBiYXNlZCBvbiBzeXN0ZW1zIGRvIG5vdCBiZWhhdmUgDQogICAgYWNj b3JkaW5nIHRvIHRoZSBSVFAgcHJvdG9jb2wgW1JGQzM1NTBdLiBDb25zaWRlcmluZyB0aGUgTUNV IGFuZCB0cmFuc2xhdG9yIA0KICAgIGFyZSB0d28gdHlwaWNhbCB0b3BvbG9naWVzIGluIHRoZSB0 d28gY2F0ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgDQogICAgZG9jdW1lbnQgd2lsbCB0 YWtlIHRoZW0gYXMgdHdvIHR5cGljYWwgZXhhbXBsZXMgdG8gZXhwbGFpbiBob3cgUlRDUCBYUiAN CiAgICByZXBvcnQgd29ya3MgaW4gZGlmZmVyZW50IFJGQzUxMTcgdG9wb2xvZ2llcy4gIiBORVcg VGV4dDogIiBUaGUgdG9wb2xvZ2llcyANCiAgICBpbiB0aGlzIGNhdGVnb3J5IGFyZSBUb3BvLVZp ZGVvLVN3aXRjaC1NQ1UgYW5kIFRvcG8tUlRDUC10ZXJtaW5hdGluZy1NQ1UuIA0KICAgIFN1Y2gg dG9wb2xvZ2llcyBiYXNlZCBvbiBzeXN0ZW1zIChlLmcuLE1DVSkgZG8gbm90IGJlaGF2ZSBhY2Nv cmRpbmcgdG8gdGhlIA0KICAgIFJUUCBwcm90b2NvbCBbUkZDMzU1MF0uIENvbnNpZGVyaW5nIHRo ZSBNQ1UgYW5kIHRyYW5zbGF0b3IgYXJlIHR3byB0eXBpY2FsIA0KICAgIGludGVybWVkaWFyeSBz eXN0ZW1zIGluIHRoZSB0d28gY2F0ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1l bnQgDQogICAgd2lsbCB0YWtlIHRoZW0gYXMgdHdvIHR5cGljYWwgZXhhbXBsZXMgdG8gZXhwbGFp biBob3cgUlRDUCBYUiByZXBvcnQgd29ya3MgDQogICAgaW4gZGlmZmVyZW50IFJGQzUxMTcgdG9w b2xvZ2llcy4gIiAmZ3Q7IFRoZSBsYXN0IHR3byBzZW50ZW5jZXMgb2YgdGhlIA0KICAgIGZpcnN0 PEJSPiZndDsgcGFyYWdyYXBoIG9mIHRoZSBzZWN1cml0eSA8QlI+Jmd0OyZndDsgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiANCiAgICBhZGQgbm90aGluZyB0byB0aGUgZG9jdW1lbnQuIEkgc3VnZ2Vz dCBkZWxldGluZyB0aGVtLiBbUWluXTogT2theS4gJmd0OyANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7Jmd0OyBBdWRpby9WaWRlbyAN CiAgICBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZTxCUj4mZ3Q7Jmd0OyBhdnQgYXQgaWV0Zi5v cmc8QlI+Jmd0OyZndDsgPEEgDQogICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hdnQiIA0KICAgIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hdnQ8L0E+ICZndDs8QlI+Jmd0OyANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IDxCUj4mZ3Q7ICogUmVmZXJlbmNlczogPEJSPiZn dDsgKiANCiAgICBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0 Y29yZS1tb25hcmNoLTEzIDxCUj4mZ3Q7ICogDQogICAgRnJvbTogUm9iZXJ0IFNwYXJrczxCUj4m Z3Q7ICogUHJldiBieSBEYXRlOiBbQVZUQ09SRV0gUHJvdG9jb2wgQWN0aW9uOiANCiAgICAnRXhw bGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgZm9yIFJUUCBvdmVyIDxCUj4mZ3Q7 IFVEUCcgdG8gDQogICAgUHJvcG9zZWQgU3RhbmRhcmQgKGRyYWZ0LWlldGYtYXZ0Y29yZS1lY24t Zm9yLXJ0cC0wOC50eHQpIDxCUj4mZ3Q7ICogDQogICAgUHJldmlvdXMgYnkgdGhyZWFkOiBbQVZU Q09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIA0KICAgIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25h cmNoLTEzIDxCUj4mZ3Q7ICogTmV4dCBieSB0aHJlYWQ6IFtBVlRDT1JFXSBQcm90b2NvbCANCiAg ICBBY3Rpb246ICdFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBmb3IgUlRQ IG92ZXIgPEJSPiZndDsgVURQJyANCiAgICB0byBQcm9wb3NlZCBTdGFuZGFyZCAoZHJhZnQtaWV0 Zi1hdnRjb3JlLWVjbi1mb3ItcnRwLTA4LnR4dCkgPEJSPiZndDsgKiANCiAgICBJbmRleChlcyk6 IDxCUj4mZ3Q7ICogRGF0ZTxCUj4mZ3Q7ICogVGhyZWFkPEJSPiZndDsgDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBBdWRpby9WaWRl byANCiAgICBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZTxCUj4mZ3Q7IDxBIGhyZWY9Im1haWx0 bzphdnRAaWV0Zi5vcmciIA0KICAgIHltYWlsdG89Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBp ZXRmLm9yZzwvQT48QlI+Jmd0OyA8QSANCiAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2F2dCIgDQogICAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvQT48QlI+PEJSPjxCUj48QlI+LS0gDQogICAgPEJS PkNvbGluIFBlcmtpbnM8QlI+PEEgaHJlZj0iaHR0cDovL2NzcGVya2lucy5vcmcvIiANCiAgICB0 YXJnZXQ9X2JsYW5rPmh0dHA6Ly9jc3BlcmtpbnMub3JnLzwvQT48QlI+PEJSPjxCUj48QlI+PEJS PjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0221_01CD38D6.7E53CB70-- From albrechtschwarz@yahoo.de Tue May 22 19:16:43 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9A421F86E3 for ; Tue, 22 May 2012 19:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 66ovz2FTTInM for ; Tue, 22 May 2012 19:16:41 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ukl.yahoo.com (nm4-vm0.bullet.mail.ukl.yahoo.com [217.146.183.230]) by ietfa.amsl.com (Postfix) with SMTP id 7693021F86E1 for ; Tue, 22 May 2012 19:16:40 -0700 (PDT) Received: from [217.146.183.216] by nm4.bullet.mail.ukl.yahoo.com with NNFMP; 23 May 2012 02:16:34 -0000 Received: from [217.146.183.42] by tm9.bullet.mail.ukl.yahoo.com with NNFMP; 23 May 2012 02:16:34 -0000 Received: from [127.0.0.1] by omp1027.mail.ukl.yahoo.com with NNFMP; 23 May 2012 02:16:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 84516.34689.bm@omp1027.mail.ukl.yahoo.com Received: (qmail 10744 invoked by uid 60001); 23 May 2012 02:16:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1337739393; bh=h7knXHkCviPJ8BZBaSljetWFrqZQijNKRaWT0uhEFuU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=edwbZs/Ic7MmAet3C+NmiUCNMwwcY4UZoO6LUxgQrBIoPjMfcBKtvAMDEbhNUCLaSi1mHu0NB5+XMqxJeYw6B5tJmptfhiyOE0ea23Brt0o/QAuTmwr9ZHgFqLW9dfCKmJBH+TSKlTxRikGmmg7isQMH7VITeY8JNNVBtKmFRng= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GC8vhxG+CjJTyqylKOL7E4uc0tjmRlxcjpRItqkZgrEqntGtUOoAzlR7WV74lfSKFE6f922+/ANaMD64GafoHwthkfHt4BYf7ayqN3DwOM1bywnP4ZnLIpJyErzaPMBAeXVHn1I3WFeTvlftVxnVsv10P2Nh0tEz6MEf4f86Ev0=; X-YMail-OSG: 9pPQZtIVM1mTflLktQ._upCG8Ram_pPH49XKRy7QfYOBmyN PMEKd2VKdqXLNQGRTgkSl_xCVrgRfhNzDP_x5y7p30iZvG39kvHJe24YIZjZ SI_1UuhomPf.JZ5_0HbxAYkIqi8uta7QX0ms1rhxt5B0LCjSFSa8f9FVkoeI Cwyu3RE58gmvu.VUqvVa3V_INvG3_5GB_7_DBE73lObdxvlYpR.9lwLneLXL 4uQXlzBAiktDsjyS5XXrpyo0eu9b1UgpCEM92sh0oGHVpZbhNe9U7AyfnKDT h4an.CIJqp_v_uqUT2a10KZJgtUD3_UzajReOPv7fK9k1lMBrg8PV0diulLN 7Tt3Czfm1WY7ybF3XxA7IvLZIbGDny2lqNC5Ui1XHzI0J6K54ohD6nAOGqSj uKo.vpyM14lbqElN1pDwAgAYZoDkFOmR7xG_1uDQUmUbNp2EfzvnWzSIqfsk d2cDyDgttiKCM1WScp8tacWrhVa03LLRqeFKGwmkR3raL0uB3TMQWak_FRGs GcOjiJk6p8z5RFW4s4bnX59Z81cy01GRNxF_1GY2rosxqybj5PYqaRhFve2s xW6kDAnIFuSawF1jf3dvwFPdAFe96Jm6z4NBOsX62pfunoR4L8.qY6ekzC7j VvhEVz9ptldOIX6qhpNePyU1nt.Ekj5XpYReU76xhD3nwU1k7CyUhhGHy.l_ uAqdl07E_bJDqMEI- Received: from [125.207.177.35] by web171006.mail.ukl.yahoo.com via HTTP; Wed, 23 May 2012 03:16:33 BST X-Mailer: YahooMailWebService/0.8.118.349524 References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> Message-ID: <1337739393.9307.YahooMailNeo@web171006.mail.ukl.yahoo.com> Date: Wed, 23 May 2012 03:16:33 +0100 (BST) From: Albrecht Schwarz To: Colin Perkins , Qin Wu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2073204126-2040779349-1337739393=:9307" X-Mailman-Approved-At: Tue, 22 May 2012 23:24:51 -0700 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Albrecht Schwarz List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 02:57:42 -0000 --2073204126-2040779349-1337739393=:9307 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FYI, =0A=0AITU-T SG16 has a work item for such kind of middleboxes and perf= ormance monitoring support:=0A=0Ahttp://www.itu.int/ITU-T/workprog/wp_item.= aspx?isn=3D8407=0A"Guidelines on the use of H.248 capabilities for performa= nce monitoring in RTP networks in H.248 Profiles"=0A=0A... and the ITU-T wo= rk is referring to MONARCH.=0A=0A-Albrecht=0A=0A=0A=0A=0A=0A=0A>___________= _____________________=0A> Von: Colin Perkins =0A>An: Qin= Wu =0A>CC: Albrecht Schwarz ; avt@ietf.org =0A>Gesendet: 13:04 Dienstag, 22.Mai 2012=0A>Betreff: Re: [= AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13=0A> =0A>I also= don't agree with deleting Section 3.3 from the monarch draft. =0A>=0A>The = architecture needs to be clear that there are valid scenarios for RTP monit= oring within a network, either in some middlebox that comprises part of an = RTP session, or in a third-party monitoring device used for network managem= ent purposes. Section 3.3 is a reasonable place to discuss these, and to ex= plain why the metrics that can be reported from middleboxes are different t= o those that can be captured at end systems.=0A>=0A>Colin=0A>=0A>=0A>=0A>On= 22 May 2012, at 07:53, Qin Wu wrote:=0A>> Hi,:=0A>> ----- Original Message= ----- =0A>> From: "Albrecht Schwarz" =0A>> To: <= bill.wu@huawei.com>=0A>> Cc: ; =0A>> Se= nt: Tuesday, May 22, 2012 11:18 AM=0A>> Subject: Re: [AVTCORE] Subject: AD = review of draft-ietf-avtcore-monarch-13=0A>> =0A>> =0A>> Dear All,=0A>> =0A= >> concerning the resolution proposal for clause 3.3:=0A>> I don't agree in= just deleting again that section!=0A>> There was quite a long debate for i= ncorporating such a clause.=0A>> The original text proposal was much more d= etailed. Perhaps the shortening to just a single paragraph is the main caus= e for unclarity.=0A>> Thus, instead of removing previous agreed text, we ju= st rather extend it again.=0A>> =0A>> =0A>> [Qin]: =0A>> The reason I propo= se to remove the section 3.3 is =0A>> a. I think Robert is correct. The set= of meaningful metrics isn't changed at all=A0 wherever you collect them. I= t seems little sense =0A>>=A0 =A0 to say "the location of the RTP Sender/Re= ceiver entities may impact a set of meaningful metrics. " =0A>> b. Where to= gather or measure metrics can be indicated by the definition of Transport = metrics, End system metrics and application level metrics.=0A>> c. Section = 3.3 seems to discuss where to gather what metrics. Recommendation ITU-T G.1= 081 have already defined five monitoring points =0A>>=A0 =A0 where the perf= ormance measurements can be made.=0A>> =0A>>> I think the definition of app= lication level metrics has already clarified that=A0 application level metr= ics is normally gathered from user endpoint. =0A>> =0A>> No. We did discuss= this already extensively.=0A>> An RTP media translator could provide appli= cation level metrics because e.g. terminating the application protocol laye= r.=0A>> Such an RTP topology is NOT located in an user endpoint!=0A>> =0A>>= [Qin]: Sorry, I should correct me to say QoE metric is ususally measured a= t the user endpoint.=0A>> =0A>> Regards,=0A>> Albrecht=0A>> _______________= _________________=0A>> [Date Prev][Date Next][Thread Prev][Thread Next][Dat= e Index][Thread Index] =0A>> Re: [AVTCORE] Subject: AD review of draft-ietf= -avtcore-monarch-13=0A>> ________________________________=0A>> =0A>> * To: = Robert Sparks , IETF AVTCore WG ,= =0A>> * Subject: Re: [AVTCOR= E] Subject: AD review of draft-ietf-avtcore-monarch-13=0A>> * From: Qin Wu = =0A>> * Date: Fri, 18 May 2012 18:37:56 +0800=0A>> *= Delivered-to: avt at ietfa.amsl.com=0A>> * List-archive: =0A>> * List-help: =0A>> * List-id: Audio/Video Transport Core Maintenance =0A>> * List-post: =0A>> * List-subscribe: , =0A>> * List-unsubscribe: , =0A>> * Refer= ences: <4FB2E323.3090406 at nostrum.com>=0A>> _____________________________= ___=0A>> =0A>> Hi,Robert:=0A>> Thank for your valuable review. please see m= y replies inline belows. Regards!=0A>> -Qin=0A>> ----- Original Message ---= -- =0A>> From: "Robert Sparks" =0A>> To: "IETF AVT= Core WG" ; = =0A>> Sent: Wednesday, May 16, 2012 7:13 AM=0A>> Subject: [AVTCORE] Subject= : AD review of draft-ietf-avtcore-monarch-13 > Summary: There are issues to= resolve with a revised ID before =0A>>> progressing to IETF LC.=0A>>> =0A>= >> It's a struggle to see the _architecture_ this document is supposed to = =0A>>> describe. I suspect most of the working group energy went into Secti= on 5 =0A>>> (the guidelines for writing XR block definitions) - the rest of= the =0A>>> document needs a similar level of attention to detail.=0A>>> = =0A>>> There are two major issues that I've tagged with a (*). I followed a= =0A>>> mostly document-order flow instead of grouping the major issues at = the top.=0A>>> =0A>>> (*) Given the document's title, it should be very eas= y to answer "What =0A>>> is the monitoring architecture?" for people who ar= e reading this draft =0A>>> for the first time.=0A>>> The key message is th= at the monitoring architecture consists of Monitors =0A>>> that exchange in= formation using RTCP Metric Blocks. [Qin]: Agree. >The text should say =0A>= >> that. [Qin]: Okay. > There is a lot of prose in section 3 and visual det= ail in the =0A>>> diagram in Figure 1 that makes that extremely difficult t= o see. =0A>>> Simplifying the figure by removing the details about applicat= ions and =0A>>> transports, or at least moving them to a second figure, mak= ing the =0A>>> Monitor boxes stand out, and making the types of information= flows (the =0A>>> arrows) visually distinctive would help. Simplify the pr= ose (much of it =0A>>> could be removed) to focus on that key message. [Qin= ]: Agree, I propose to remove the figure 1 and squeeze the section 3.1 as f= ollows: " 3.1. Overview The RTP monitoring architecture comprises the follo= wing two key functional components shown below: o RTP Monitor o RTP Metric = Block Structure RTP Monitor is the functional component defined in the Real= -time Transport Protocol [RFC3550]. It acts as a source of information gath= ered for monitoring purposes and exchanges information with the other RTP m= onitors using RTCP Metric Blocks. According to the definition of monitor in= the RTP Protocol [RFC3550], the end system that runs an application progra= m that sends or receives RTP data packets, an intermediate- system that for= wards RTP packets to End-devices or a third party that observes the RTP and= RTCP traffic but does not make itself visible to the RTP Session participa= nts (i.e., the third party monitor depicted in figure 1) can act as the=0A>= > RTP monitor. The third party monitor should be placed on the RTP/RTCP pat= hs between the sender, intermediate and the receiver. The RTP monitor also = exposes real time Application QoS/QoE metric information in the appropriate= report block format (e.g.,RTCP XR or othe non-RTP means) to the management= system. Such information can be formulated as different metric types, e.g.= ,application level metric, transport level metric, end system metric, inter= val metric, cumulative metric, sampled metric, direct metric, composed metr= ic,etc. Both the RTCP or RTCP XR can be extended to convey these metrics. T= he details on transport protocols for these metric are described in Section= 3.2. RTP may be used to multicast groups, both Any Source Multicast (ASM) = and Source Specific Multicast (SSM). These groups can be monitored using RT= CP. In the ASM case, the monitor is a member of the multicast group and lis= tens to RTCP XR reports from all members of the ASM=0A>> group. In the SSM = case, there is a unicast feedback target that receives RTCP feedback from r= eceivers and distributes it to other members of the SSM group (see figure 1= of RFC5760). The monitor will need to be co-located with the feedback targ= et to receive all feedback from the receivers (this may also be an intermed= iate system). In both ASM and SSM scenarios, receivers can send RTCP XR rep= orts to enhance the reception quality reporting. " > In the definition of C= omposed metrics, the sentence "An example is a =0A>>> metric calculated bas= ed on derived metrics that have been measured." =0A>>> makes little sense. = [Qin] The derived metrics in the sentence should been corrected as "direct = metric". >Did you mean something like "An example is a metric =0A>>> derive= d by algorithmically combining measured metrics."? [Qin]:I agree with your = suggested text and like to adopt your suggestion. > The definitions of Inte= rval, Cumulative, and Sampled metrics are not clear. [Qin]: I agree the def= inition for these three metrics need to be more cleaer, I proposes to do th= e following changes: NEW Text: " Interval metrics Metrics of which the repo= rted values are measured in the most recent measurement interval duration b= etween successive metrics reports. Such measurement interval is equal to on= e RTCP report interval (RFC3550,Section 6.2). Cumulative metrics Metrics of= which the reported values apply to the accumulation period characteristic = of cumulative measurements. The reported values are measured during the acc= umulation period. The accumulation period spans over more than one RTCP rep= ort intervals. Sampled metrics Metrics of which the reported values only ap= ply to the value of a continuously measured or=0A>> calculated metric that = has been sampled at any given instance of the RTCP report interval. One exa= mple of such metric is the inter-arrival jitter described in the section 6.= 4.1 of RFC3550. " > If the discussion at the end of section 3.1 is kept, th= e reference to =0A>>> RFC5760 should be a real reference, and RFC5760 shoul= d appear in the =0A>>> reference section. [Qin]: Okay. > The point of secti= on 3.2 is not obvious. How does it contribute to the =0A>>> description of = the architecture. It mixes talking about what report =0A>>> blocks are with= occasionally needing to send them more frequently. Those =0A>>> points cou= ld be made separately and more simply. [Qin]: Okay. I like to incorporate t= he key points in the section 3.2 into section 3.1 > Section 3.3 is not clea= r - it starts off saying that the location of the =0A>>> sender and receive= r may change what metrics are meaningful. It's not =0A>>> clear what you me= an by location. You certainly don't mean geospatial =0A>>> coordinates. Do = you mean anything other than whether the element is =0A>>> trusted or untru= sted by the operations network? If so, say that. The =0A>>> rest of the par= agraph only speaks to what element collects the metrics. [Qin] Section 3.3 = is only used to describe where or from which RTP entity to gather the metri= cs (i.e., measurement point) in the physical network and is not focus of th= is document. Secondly, I think the definition of application level metrics = has already clarified that application level metrics is normally gathered f= rom user endpoint. > It's not clear that the set of meaningful metrics is c= hanged at all - =0A>>> just where you collect them. If the set of meaningfu= l metrics does in =0A>>> fact change, there needs to be additional discussi= on here. [Qin]: The metrics actually doesn't change.Since the definition of= application level metrics Have already conveyed the meaning of what sectio= n 3.3 wants to describe, I propose to remove this section. > Section 4's fi= rst paragraph: Is "probably" the best the working group =0A>>> can say? [Qi= n]:No, will remove this word. > The last two sentences of the second bullet= in section 4 do not parse. =0A>>> Please simplify them. [Qin]: Okay, how a= bout change them as follows: NEW Text: " With these minimal number of RTCP = statistics parameters mapped to non-RTCP measurements, it is hard to provid= e accurate measures of real time application quality,conduct detailed data = analysis and creates alerts timly to the users. Therefore correlation betwe= en RTCP XR and non-RTP data should be provided. " > The first full sentence= of the third bullet in section 4 does not make =0A>>> sense. The whole bul= let could be clarified. [Qin]: Agree and will remove the first sentence. > = The fourth bullet in section 4 and section 5.5 should call out that =0A>>> = RFC3611 already set Block Type 255 aside for future extensions, =0A>>> anti= cipating the potential need to extend the block type space. [Qin]: Okay, Ho= w about revising the section 4,bullet 4 as follows: " Consumption of XR blo= ck code points. The RTCP XR block namespace is limited by the 8-bit block t= ype field in the RTCP XR header. Space exhaustion may be a concern in the f= uture. Anticipating the potential need to extend the block type space, it i= s noted in [RFC3611] that Block Type 255 is reserved for future extensions,= " > In section 5, consider naming the subsections with the actual guidelin= e =0A>>> instead of the problem the guideline is trying to address.=0A>>> 5= .1. Metric blocks should contain a single metric [Qin]: I suggest to change= it as "Contain the single metrics in the metric block" > 5.2. Include the = payload type and format parameters in the metric block [Qin]: Okay. > 5.3. = Use RTCP SDES to correlate XR reports with non-RTP data [Qin]: Okay. > 5.4.= Don't repeat measurement information across metric blocks=0A>>> =0A>> [Qin= ]: It is not possible completely to avoid measurement information repeatiti= on. e.g., for packet loss robustness if the report blocks for the same inte= rval span over more than one RTCP packet then each must have the same measu= rement identity information So I suggest to change it as: "reduce measureme= nt information across metric blocks" > This points out a structural problem= with the section. Why is 5.5 here? =0A>>> It's not a guideline. [Qin]: Agr= ee and also as discussed,Space exhaustion is not big issue. How about remov= e this section? > (*) And it raises a question about what the document is t= rying to =0A>>> achieve with section 5.4. That section claims the document = is proposing =0A>>> a new XR block type to help avoid duplication, but it d= oesn't actually =0A>>> define the new block type. Is the guideline saying s= imply don't repeat =0A>>> measurements or its the guideline saying "use thi= s new XR block type we =0A>>> haven't defined yet"? [Qin]: Just to clarify,= we have already defined one new XR Block type to help avoid or reduce dupl= ication. It is measurement information block. The relevant draft is availab= le at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-meas-identity-= 06 >The section needs more clarity. If it really is =0A>>> trying to define= a new type, there's more work to be done. [Qin]: In order to avoid such co= nfusion, I proposed to do the following change to the section 5.4: OLD Text= : " This memo proposes to define a new XR Block that will be used to convey= the common time period and the number of packets sent during this period. = " New text: " This memo proposes to define a new XR Block (i.e., the Measur= ement information block[I.D-ietf-xrblock-rtcp-xr-meas-identity]) that will = be used to convey the common time period and the number of packets sent dur= ing this period. " > The Security Considerations section, particularly the = third paragraph, =0A>>> needs to be clearer. What exactly do you mean by "m= onitoring should be =0A>>> prohibited", and how is the fact that third part= y monitors don't send =0A>>> RTCP relevant? Did you intend those to be sepa= rate points? [Qin]: Yes, they are on the different port. Such monitor may r= eceive RTP packet but does not send RTCP packet. > Editorial Nits and Sugge= stions:=0A>>> =0A>>> The first paragraph of the introduction is overly comp= lex, and won't age =0A>>> well. I suggest replacing it with: "Multimedia se= rvices using the =0A>>> Real-Time Protocol (RTP) are seeing increased use. = Standard methods for =0A>>> gathering RTP performance metrics from these ap= plications are needed to =0A>>> manage uncertainties in the behavior and av= ailability of their =0A>>> services." Then replace "These rapidly emerging = standards," with =0A>>> "Standards". [Qin]: Okay. > Introduction paragraph = 3 sentence 2 should start "The RTCP Guidelines =0A>>> [RFC5968]". It would = be even better to use the full title from 5968: =0A>>> 'The "Guidelines for= Extending the RTP Control Protocol (RTCP)" [RFC5968]' [Qin]: Okay. > This = may become moot as section 3 is modified to make its main point =0A>>> more= obvious, but RFC3550 does not characterize Monitors as "a source of =0A>>>= information". That could be misunderstood. Please choose another word. =0A= >>> Perhaps "repository"? [Qin]: Okay, repository looks good to me. > In bu= llet lists, starting an entry with "or" or "and" is unnecessary. It =0A>>> = should be clear from the introduction to the list whether the individual = =0A>>> entries should be combined or selected from. [Qin]: Okay. > In secti= on 3.1 where you say "RTP may be used to multicast groups" did =0A>>> you m= ean "RTP may be sent to multicast groups" or "RTP may be used with =0A>>> m= ulticast groups"? [Qin]: I think it should be the latter case,i.e.," RTP ma= y be used with =0A>> multicast groups". > =0A>>> In section 3.2 "The follow= ing are four use cases but are not limited =0A>>> to:" does not parse. The = bullets aren't really use cases as much as they =0A>>> are mechanisms. Woul= d it make more sense to say "Here are four =0A>>> mechanisms that have been= created to address the need for more frequent =0A>>> reporting. This list = is not intended to be exhaustive." The third bullet =0A>>> in that list sho= uld say "RTCP and RTCP XR are" instead of "RTCP or RTCP =0A>>> XR is". [Qin= ]: Okay, but I have incorporated the keypoints of section 3.2 into section = 3.1. > The bullets in section 4 would be better as subsections with titles = =0A>>> (taken from the first phrase of the bullet). [Qin]: Okay. > I sugges= t this alternative for the first full sentence in the first =0A>>> bullet o= f section 4 : "A compound metrics block is designed to contain a =0A>>> lar= ge number of parameters from different classes for a specific =0A>>> applic= ation in a single block." [Qin]: Okay. > Section 5's title should be "Guide= lines for reporting" instead of =0A>>> "Guideline for reporting" [Qin]: Oka= y. > In section 5.1 I suggest "justify the overhead," instead of "justify t= he =0A>>> overheads," [Qin]: Okay. > Section 7 - the last sentence of the f= irst paragraph does not parse. The =0A>>> second paragraph (which is a sing= le sentence) should be clarified - an =0A>>> MCU is not a topology. [Qin]: = Okay. How about revising them as follows: OLD Text: " The topologies in thi= s category are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such to= pologies based on systems do not behave according to the RTP protocol [RFC3= 550]. Considering the MCU and translator are two typical topologies in the = two categories mentioned above, this document will take them as two typical= examples to explain how RTCP XR report works in different RFC5117 topologi= es. " NEW Text: " The topologies in this category are Topo-Video-Switch-MCU= and Topo-RTCP-terminating-MCU. Such topologies based on systems (e.g.,MCU)= do not behave according to the RTP protocol [RFC3550]. Considering the MCU= and translator are two typical intermediary systems in the two categories = mentioned above, this document will take them as two typical examples to ex= plain how RTCP XR report works in different RFC5117 topologies. " > The las= t two sentences of the first=0A>> paragraph of the security =0A>>> consider= ations section add nothing to the document. I suggest deleting them. [Qin]:= Okay. > _______________________________________________=0A>>> Audio/Video = Transport Core Maintenance=0A>>> avt at ietf.org=0A>>> https://www.ietf.org= /mailman/listinfo/avt >=0A>> ________________________________=0A>> =0A>> * = References: =0A>> * [AVTCORE] Subject: AD review of draft-ietf-avtcore-mona= rch-13 =0A>> * From: Robert Sparks=0A>> * Prev by Date: [AVTCORE] Protocol = Action: 'Explicit Congestion Notification (ECN) for RTP over =0A>> UDP' to = Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt) =0A>> * Previous = by thread: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 = =0A>> * Next by thread: [AVTCORE] Protocol Action: 'Explicit Congestion Not= ification (ECN) for RTP over =0A>> UDP' to Proposed Standard (draft-ietf-av= tcore-ecn-for-rtp-08.txt) =0A>> * Index(es): =0A>> * Date=0A>> * Thread=0A>= > _______________________________________________=0A>> Audio/Video Transpor= t Core Maintenance=0A>> avt@ietf.org=0A>> https://www.ietf.org/mailman/list= info/avt=0A>=0A>=0A>=0A>-- =0A>Colin Perkins=0A>http://csperkins.org/=0A>= =0A>=0A>=0A>=0A>=0A> --2073204126-2040779349-1337739393=:9307 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,=
ITU-T SG16 has a work item for such kind of middleboxes and= performance monitoring support:
http://www.itu.int/ITU-T/wor= kprog/wp_item.aspx?isn=3D8407
"Guidelines on the use of H.248 capabilities= for performance monitoring in RTP networks in H.248 Profiles"
=

... and the ITU-T work is referring to MONARCH.

-Albrecht


Von:<= /span> Colin Perkins <csp@csperkins.org>
An: Qin Wu <bill.wu@huawei.com>
<= span style=3D"font-weight: bold;">CC: Albrecht Schwarz <albre= chtschwarz@yahoo.de>; avt@ietf.org
Gesendet: 13:04 Dienstag, 22.Mai 2012
Betreff: Re: [AVTCORE] Subject: AD revie= w of draft-ietf-avtcore-monarch-13

I also don't agre= e with deleting Section 3.3 from the monarch draft.

The architectur= e needs to be clear that there are valid scenarios for RTP monitoring withi= n a network, either in some middlebox that comprises part of an RTP session= , or in a third-party monitoring device used for network management purpose= s. Section 3.3 is a reasonable place to discuss these, and to explain why the metrics= that can be reported from middleboxes are different to those that can be c= aptured at end systems.

Colin



On 22 May 2012, at 07:5= 3, Qin Wu wrote:
> Hi,:
> ----- Original Message -----
>= From: "Albrecht Schwarz" <albrechtschwarz@yahoo.de>=
> To: <bill.wu@huawei.com>
> Cc: <avt@ietf.org>; <= ;rjsparks@nostrum.com>
> Sent: Tuesday, May 22, 2012 11:1= 8 AM
> Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcor= e-monarch-13
>
>
> Dear All,
>
> concernin= g the resolution proposal for clause 3.3:
> I don't agree in just deleting= again that section!
> There was quite a long debate for incorporatin= g such a clause.
> The original text proposal was much more detailed.= Perhaps the shortening to just a single paragraph is the main cause for un= clarity.
> Thus, instead of removing previous agreed text, we just ra= ther extend it again.
>
>
> [Qin]:
> The reason = I propose to remove the section 3.3 is
> a. I think Robert is correc= t. The set of meaningful metrics isn't changed at all  wherever you co= llect them. It seems little sense
>    to say "the locatio= n of the RTP Sender/Receiver entities may impact a set of meaningful metric= s. "
> b. Where to gather or measure metrics can be indicated by the= definition of Transport metrics, End system metrics and application level = metrics.
> c. Section 3.3 seems to discuss where to gather what metrics. Recommendation ITU-T G.1081 have already defined five monito= ring points
>    where the performance measurements can be= made.
>
>> I think the definition of application level met= rics has already clarified that  application level metrics is normally= gathered from user endpoint.
>
> No. We did discuss this alr= eady extensively.
> An RTP media translator could provide application= level metrics because e.g. terminating the application protocol layer.
= > Such an RTP topology is NOT located in an user endpoint!
>
&= gt; [Qin]: Sorry, I should correct me to say QoE metric is ususally measure= d at the user endpoint.
>
> Regards,
> Albrecht
> = ________________________________
> [Date Prev][Date Next][Thread Prev= ][Thread Next][Date Index][Thread Index]
> Re: [AVTCORE] Subject: AD= review of draft-ietf-avtcore-monarch-13
> ________________________________
>
> * To: Robert Sparks <= rjsparks at nostrum.com>, IETF AVTCore WG <avt at ietf.org>, <d= raft-ietf-avtcore-monarch at tools.ietf.org>
> * Subject: Re: [AVT= CORE] Subject: AD review of draft-ietf-avtcore-monarch-13
> * From: Q= in Wu <bill.wu at huawei.com>
> * Date: Fri, 18 May 2012 18:37:= 56 +0800
> * Delivered-to: avt at ietfa.amsl.com
> * List-archi= ve: <http://www.ietf.org/mail-archive/web/avt>
> * List-help: &= lt;mailto:avt-request@ietf.org?subject=3Dhelp>
> * List-i= d: Audio/Video Transport Core Maintenance <avt.ietf.org>
> * Li= st-post: <mailto:avt@ietf.org>
> * List-subscribe: <https= ://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@i= etf.org?subject=3Dsubscribe>
> * List-unsubscribe: <https://www= .ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org= ?subject=3Dunsubscribe>
> * References: <4FB2E323.3090406 a= t nostrum.com>
> ________________________________
>
>= Hi,Robert:
> Thank for your valuable review. please see my replies i= nline belows. Regards!
> -Qin
> ----- Original Message ----- > From: "Robert Sparks" <rjsparks at nostrum.com>
> To: "I= ETF AVTCore WG" <avt at ietf.org>; <draft-ietf-avtcore-monarch at tools.ietf.org>
> Sent: Wednesday, May 16, 2012 7:13 AM
> S= ubject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 > = Summary: There are issues to resolve with a revised ID before
>> = progressing to IETF LC.
>>
>> It's a struggle to see the= _architecture_ this document is supposed to
>> describe. I suspe= ct most of the working group energy went into Section 5
>> (the g= uidelines for writing XR block definitions) - the rest of the
>> = document needs a similar level of attention to detail.
>>
>= > There are two major issues that I've tagged with a (*). I followed a <= br>>> mostly document-order flow instead of grouping the major issues= at the top.
>>
>> (*) Given the document's title, it sh= ould be very easy to answer "What
>> is the monitoring architectu= re?" for people who are reading this draft
>> for the first time.
>> The key message is that the monitoring architectur= e consists of Monitors
>> that exchange information using RTCP Me= tric Blocks. [Qin]: Agree. >The text should say
>> that. [Qin]= : Okay. > There is a lot of prose in section 3 and visual detail in the =
>> diagram in Figure 1 that makes that extremely difficult to see= .
>> Simplifying the figure by removing the details about applica= tions and
>> transports, or at least moving them to a second figu= re, making the
>> Monitor boxes stand out, and making the types o= f information flows (the
>> arrows) visually distinctive would he= lp. Simplify the prose (much of it
>> could be removed) to focus = on that key message. [Qin]: Agree, I propose to remove the figure 1 and squ= eeze the section 3.1 as follows: " 3.1. Overview The RTP monitoring archite= cture comprises the following two key functional components shown below: o RTP Monitor o RTP Metric Block Structure RTP Monitor is the funct= ional component defined in the Real-time Transport Protocol [RFC3550]. It a= cts as a source of information gathered for monitoring purposes and exchang= es information with the other RTP monitors using RTCP Metric Blocks. Accord= ing to the definition of monitor in the RTP Protocol [RFC3550], the end sys= tem that runs an application program that sends or receives RTP data packet= s, an intermediate- system that forwards RTP packets to End-devices or a th= ird party that observes the RTP and RTCP traffic but does not make itself v= isible to the RTP Session participants (i.e., the third party monitor depic= ted in figure 1) can act as the
> RTP monitor. The third party monito= r should be placed on the RTP/RTCP paths between the sender, intermediate a= nd the receiver. The RTP monitor also exposes real time Application QoS/QoE= metric information in the appropriate report block format (e.g.,RTCP XR or othe non-RTP means) to the management system. Such inform= ation can be formulated as different metric types, e.g.,application level m= etric, transport level metric, end system metric, interval metric, cumulati= ve metric, sampled metric, direct metric, composed metric,etc. Both the RTC= P or RTCP XR can be extended to convey these metrics. The details on transp= ort protocols for these metric are described in Section 3.2. RTP may be use= d to multicast groups, both Any Source Multicast (ASM) and Source Specific = Multicast (SSM). These groups can be monitored using RTCP. In the ASM case,= the monitor is a member of the multicast group and listens to RTCP XR repo= rts from all members of the ASM
> group. In the SSM case, there is a = unicast feedback target that receives RTCP feedback from receivers and dist= ributes it to other members of the SSM group (see figure 1 of RFC5760). The= monitor will need to be co-located with the feedback target to receive all feedback from the receivers (this may also be an intermediate = system). In both ASM and SSM scenarios, receivers can send RTCP XR reports = to enhance the reception quality reporting. " > In the definition of Com= posed metrics, the sentence "An example is a
>> metric calculated= based on derived metrics that have been measured."
>> makes litt= le sense. [Qin] The derived metrics in the sentence should been corrected a= s "direct metric". >Did you mean something like "An example is a metric =
>> derived by algorithmically combining measured metrics."? [Qin]= :I agree with your suggested text and like to adopt your suggestion. > T= he definitions of Interval, Cumulative, and Sampled metrics are not clear. = [Qin]: I agree the definition for these three metrics need to be more cleae= r, I proposes to do the following changes: NEW Text: " Interval metrics Met= rics of which the reported values are measured in the most recent measurement interval duration between successive metrics reports. Such mea= surement interval is equal to one RTCP report interval (RFC3550,Section 6.2= ). Cumulative metrics Metrics of which the reported values apply to the acc= umulation period characteristic of cumulative measurements. The reported va= lues are measured during the accumulation period. The accumulation period s= pans over more than one RTCP report intervals. Sampled metrics Metrics of w= hich the reported values only apply to the value of a continuously measured= or
> calculated metric that has been sampled at any given instance o= f the RTCP report interval. One example of such metric is the inter-arrival= jitter described in the section 6.4.1 of RFC3550. " > If the discussion= at the end of section 3.1 is kept, the reference to
>> RFC5760 s= hould be a real reference, and RFC5760 should appear in the
>> re= ference section. [Qin]: Okay. > The point of section 3.2 is not obvious. How does it contribute to the
>> description of the arc= hitecture. It mixes talking about what report
>> blocks are with = occasionally needing to send them more frequently. Those
>> point= s could be made separately and more simply. [Qin]: Okay. I like to incorpor= ate the key points in the section 3.2 into section 3.1 > Section 3.3 is = not clear - it starts off saying that the location of the
>> send= er and receiver may change what metrics are meaningful. It's not
>&g= t; clear what you mean by location. You certainly don't mean geospatial >> coordinates. Do you mean anything other than whether the element = is
>> trusted or untrusted by the operations network? If so, say = that. The
>> rest of the paragraph only speaks to what element co= llects the metrics. [Qin] Section 3.3 is only used to describe where or fro= m which RTP entity to gather the metrics (i.e., measurement point) in the physical network and is not focus of this document. Secondly, I thi= nk the definition of application level metrics has already clarified that a= pplication level metrics is normally gathered from user endpoint. > It's= not clear that the set of meaningful metrics is changed at all -
>&= gt; just where you collect them. If the set of meaningful metrics does in <= br>>> fact change, there needs to be additional discussion here. [Qin= ]: The metrics actually doesn't change.Since the definition of application = level metrics Have already conveyed the meaning of what section 3.3 wants t= o describe, I propose to remove this section. > Section 4's first paragr= aph: Is "probably" the best the working group
>> can say? [Qin]:N= o, will remove this word. > The last two sentences of the second bullet = in section 4 do not parse.
>> Please simplify them. [Qin]: Okay, = how about change them as follows: NEW Text: " With these minimal number of RTCP statistics parameters mapped to non-RTCP measurements, it i= s hard to provide accurate measures of real time application quality,conduc= t detailed data analysis and creates alerts timly to the users. Therefore c= orrelation between RTCP XR and non-RTP data should be provided. " > The = first full sentence of the third bullet in section 4 does not make
>= > sense. The whole bullet could be clarified. [Qin]: Agree and will remo= ve the first sentence. > The fourth bullet in section 4 and section 5.5 = should call out that
>> RFC3611 already set Block Type 255 aside = for future extensions,
>> anticipating the potential need to exte= nd the block type space. [Qin]: Okay, How about revising the section 4,bull= et 4 as follows: " Consumption of XR block code points. The RTCP XR block n= amespace is limited by the 8-bit block type field in the RTCP XR header. Sp= ace exhaustion may be a concern in the future. Anticipating the potential need to extend the block type space, it is noted in [RFC3611] th= at Block Type 255 is reserved for future extensions, " > In section 5, c= onsider naming the subsections with the actual guideline
>> inste= ad of the problem the guideline is trying to address.
>> 5.1. Metr= ic blocks should contain a single metric [Qin]: I suggest to change it as "= Contain the single metrics in the metric block" > 5.2. Include the paylo= ad type and format parameters in the metric block [Qin]: Okay. > 5.3. Us= e RTCP SDES to correlate XR reports with non-RTP data [Qin]: Okay. > 5.4= . Don't repeat measurement information across metric blocks
>> > [Qin]: It is not possible completely to avoid measurement information= repeatition. e.g., for packet loss robustness if the report blocks for the= same interval span over more than one RTCP packet then each must have the = same measurement identity information So I suggest to change it as: "reduce measurement information across metric blocks" > This points out= a structural problem with the section. Why is 5.5 here?
>> It's = not a guideline. [Qin]: Agree and also as discussed,Space exhaustion is not= big issue. How about remove this section? > (*) And it raises a questio= n about what the document is trying to
>> achieve with section 5.= 4. That section claims the document is proposing
>> a new XR bloc= k type to help avoid duplication, but it doesn't actually
>> defi= ne the new block type. Is the guideline saying simply don't repeat
>= > measurements or its the guideline saying "use this new XR block type w= e
>> haven't defined yet"? [Qin]: Just to clarify, we have alread= y defined one new XR Block type to help avoid or reduce duplication. It is = measurement information block. The relevant draft is available at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-= xr-meas-identity-06 >The section needs more clarity. If it really is=
>> trying to define a new type, there's more work to be done. [Q= in]: In order to avoid such confusion, I proposed to do the following chang= e to the section 5.4: OLD Text: " This memo proposes to define a new XR Blo= ck that will be used to convey the common time period and the number of pac= kets sent during this period. " New text: " This memo proposes to define a = new XR Block (i.e., the Measurement information block[I.D-ietf-xrblock-rtcp= -xr-meas-identity]) that will be used to convey the common time period and = the number of packets sent during this period. " > The Security Consider= ations section, particularly the third paragraph,
>> needs to be = clearer. What exactly do you mean by "monitoring should be
>> prohibited", and how is the fact that third party monitors don't send
= >> RTCP relevant? Did you intend those to be separate points? [Qin]: = Yes, they are on the different port. Such monitor may receive RTP packet bu= t does not send RTCP packet. > Editorial Nits and Suggestions:
>&g= t;
>> The first paragraph of the introduction is overly complex, = and won't age
>> well. I suggest replacing it with: "Multimedia s= ervices using the
>> Real-Time Protocol (RTP) are seeing increase= d use. Standard methods for
>> gathering RTP performance metrics = from these applications are needed to
>> manage uncertainties in = the behavior and availability of their
>> services." Then replace= "These rapidly emerging standards," with
>> "Standards". [Qin]: = Okay. > Introduction paragraph 3 sentence 2 should start "The RTCP Guide= lines
>> [RFC5968]". It would be even better to use the full title from 5968:
>> 'The "Guidelines for Extending the RTP = Control Protocol (RTCP)" [RFC5968]' [Qin]: Okay. > This may become moot = as section 3 is modified to make its main point
>> more obvious, = but RFC3550 does not characterize Monitors as "a source of
>> inf= ormation". That could be misunderstood. Please choose another word.
>= ;> Perhaps "repository"? [Qin]: Okay, repository looks good to me. > = In bullet lists, starting an entry with "or" or "and" is unnecessary. It >> should be clear from the introduction to the list whether the in= dividual
>> entries should be combined or selected from. [Qin]: O= kay. > In section 3.1 where you say "RTP may be used to multicast groups= " did
>> you mean "RTP may be sent to multicast groups" or "RTP m= ay be used with
>> multicast groups"? [Qin]: I think it should be= the latter case,i.e.," RTP may be used with
> multicast groups". >
>> In section 3.2 "The following are four use case= s but are not limited
>> to:" does not parse. The bullets aren't = really use cases as much as they
>> are mechanisms. Would it make= more sense to say "Here are four
>> mechanisms that have been cr= eated to address the need for more frequent
>> reporting. This li= st is not intended to be exhaustive." The third bullet
>> in that= list should say "RTCP and RTCP XR are" instead of "RTCP or RTCP
>&g= t; XR is". [Qin]: Okay, but I have incorporated the keypoints of section 3.= 2 into section 3.1. > The bullets in section 4 would be better as subsec= tions with titles
>> (taken from the first phrase of the bullet).= [Qin]: Okay. > I suggest this alternative for the first full sentence i= n the first
>> bullet of section 4 : "A compound metrics block is= designed to contain a
>> large number of parameters from different classes for a specific
>> application in a single bloc= k." [Qin]: Okay. > Section 5's title should be "Guidelines for reporting= " instead of
>> "Guideline for reporting" [Qin]: Okay. > In se= ction 5.1 I suggest "justify the overhead," instead of "justify the
>= ;> overheads," [Qin]: Okay. > Section 7 - the last sentence of the fi= rst paragraph does not parse. The
>> second paragraph (which is a= single sentence) should be clarified - an
>> MCU is not a topolo= gy. [Qin]: Okay. How about revising them as follows: OLD Text: " The topolo= gies in this category are Topo-Video-Switch-MCU and Topo-RTCP-terminating-M= CU. Such topologies based on systems do not behave according to the RTP pro= tocol [RFC3550]. Considering the MCU and translator are two typical topolog= ies in the two categories mentioned above, this document will take them as = two typical examples to explain how RTCP XR report works in different RFC5117 topologies. " NEW Text: " The topologies in this categor= y are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems (e.g.,MCU) do not behave according to the RTP protocol [RF= C3550]. Considering the MCU and translator are two typical intermediary sys= tems in the two categories mentioned above, this document will take them as= two typical examples to explain how RTCP XR report works in different RFC5= 117 topologies. " > The last two sentences of the first
> paragrap= h of the security
>> considerations section add nothing to the do= cument. I suggest deleting them. [Qin]: Okay. > ________________________= _______________________
>> Audio/Video Transport Core Maintenance<= br>>> avt at ietf.org
>> https://www.ietf.org/mailman/listinfo/= avt >
> ________________________________
>
> * References:
> * [AVTCORE] Subject: AD review of draft-ietf-avtcore-= monarch-13
> * From: Robert Sparks
> * Prev by Date: [AVTCORE]= Protocol Action: 'Explicit Congestion Notification (ECN) for RTP over
= > UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)
= > * Previous by thread: [AVTCORE] Subject: AD review of draft-ietf-avtco= re-monarch-13
> * Next by thread: [AVTCORE] Protocol Action: 'Explic= it Congestion Notification (ECN) for RTP over
> UDP' to Proposed Sta= ndard (draft-ietf-avtcore-ecn-for-rtp-08.txt)
> * Index(es):
>= ; * Date
> * Thread
> _________________________________________= ______
> Audio/Video Transport Core Maintenance
> avt@ietf.org
>= ht= tps://www.ietf.org/mailman/listinfo/avt



--
Colin Perkins
http://cspe= rkins.org/





=
--2073204126-2040779349-1337739393=:9307-- From ron.even.tlv@gmail.com Wed May 23 00:41:42 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9221F8514 for ; Wed, 23 May 2012 00:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] 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 6HBFPO+8JKjX for ; Wed, 23 May 2012 00:41:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6DD21F84FC for ; Wed, 23 May 2012 00:41:41 -0700 (PDT) Received: by werb13 with SMTP id b13so3867412wer.31 for ; Wed, 23 May 2012 00:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=uExWfNwFsAVAIcbCM4i8Akz/HiEnh9lO7OhkZIvcb90=; b=rIkhQ9619o1cU/1LgPcpzBtZFfH8JRcOuzGu+nT198RoJZsf9KAY3BNG3ycrhVBsbb RdnCLn/Vsy0d+jcqET8x3jJvNYYrXXaQNcvdUEiU5Fl07L/vJRxLIeGDOFXlc7e8gkip 0tmKsMwdcoDLEzg3U9nWnqjmE1OOn2M5OI0x1AEFmOUxdfXIvXpQiZwgAfm51RYVKXgh poZ71lQSRWktR673DKsuz8dsQ0DbWWL1Ql4tNK9sf1CnMc4jdrn7H/fgAab7Hvjipz9+ Y8J2QFQ22oiC0LxPhonLE30pWVe0WXgqyVXWwKjIYDQ1MwE0ct2MaDimUAY3FZWc1Fy4 vxEw== Received: by 10.180.83.196 with SMTP id s4mr43313087wiy.15.1337758900549; Wed, 23 May 2012 00:41:40 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id du4sm60959464wib.10.2012.05.23.00.41.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 May 2012 00:41:39 -0700 (PDT) From: "Roni Even" To: Date: Wed, 23 May 2012 10:39:27 +0300 Message-ID: <4fbc94b3.c460b40a.6179.40b8@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CD38D0.55991060" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac04ty6GngC/btD/SlKdLniA8LS56Q== Content-Language: en-us Cc: 'Magnus Westerlund' Subject: [AVTCORE] adopting draft-williams-avtcore-clksrc-00 as a WG document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 07:41:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01CD38D0.55991060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, AVTcore have the following milestone: Nov 2012 - Submit RTP Clock Source Signaling as Proposed Standard The chairs propose to adopt http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the initial document to address this milestone. The document will also be reviewed by the SDP directorate. There are no other documents addressing this milestone so please let the chairs know if you support this action by June 6th Thanks Roni Even ------=_NextPart_000_0034_01CD38D0.55991060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

AVTcore =
 have the following milestone:
 Nov 2012 =
- Submit RTP Clock Source Signaling as Proposed =
Standard
 =

The chairs =
propose to adopt  http=
://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the =
initial document to address this =
milestone.
 =

The =
document will also be reviewed by the SDP =
directorate.
 =

There are =
no other documents addressing this milestone so please let the chairs =
know if you support this action by June =
6th
 =

Thanks=

Roni =
Even

 

------=_NextPart_000_0034_01CD38D0.55991060-- From ray.vanbrandenburg@tno.nl Wed May 23 00:51:27 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65C021F8673 for ; Wed, 23 May 2012 00:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.849 X-Spam-Level: **** X-Spam-Status: No, score=4.849 tagged_above=-999 required=5 tests=[AWL=2.623, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] 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 UviHFipD2kCC for ; Wed, 23 May 2012 00:51:26 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 57D8821F8646 for ; Wed, 23 May 2012 00:51:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,644,1330902000"; d="scan'208,217";a="69472017" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 23 May 2012 09:51:21 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.35]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Wed, 23 May 2012 09:51:20 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: New version (-01) of Leap Seconds draft Thread-Index: Ac04uLfUWBOC2FGpQYycKu7+aSlBwg== Date: Wed, 23 May 2012 07:51:20 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5BF8EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: [AVTCORE] New version (-01) of Leap Seconds draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 07:51:27 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5BF8EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, I've just uploaded a new version of the Leap Seconds draft (http://www.ietf= .org/id/draft-gross-leap-second-01.txt). The draft is meant as a small update to RFC3550 that improves RTP's reliabi= lity in the vicinity of a leap second. Among others it includes some requir= ements for RTP senders/receivers to have a functioning communicating channe= l to receive leap second scheduling updates (which, if not implemented, cou= ld mean a long-term discrepancy between sender and receiver of 1 second) an= d other requirements dealing with the short term effects of a leap second. In this -01 version of the draft we have included more references and fixed= a lot of typos. Thanks to Steve Allen for his contributions. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5BF8EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi all,
 
I’ve just uploaded a new version of the Leap Seconds draft (http://www.ietf.org/id/draft-gross-leap-second-01.txt).
 
The draft is meant as a small update to RFC3550 that improves RTP̵= 7;s reliability in the vicinity of a leap second. Among others it includes = some requirements for RTP senders/receivers to have a functioning communica= ting channel to receive leap second scheduling updates (which, if not implemented, could mean a long-term discrepancy betw= een sender and receiver of 1 second) and other requirements dealing with th= e short term effects of a leap second.
 
In this -01 version of the draft we have included more references and = fixed a lot of typos. Thanks to Steve Allen for his contributions.
 
Best regards,
 
Ray
 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5BF8EXCMBX03tsntnon_-- From ray.vanbrandenburg@tno.nl Wed May 23 01:59:58 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1607621F859F for ; Wed, 23 May 2012 01:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.793 X-Spam-Level: ** X-Spam-Status: No, score=2.793 tagged_above=-999 required=5 tests=[AWL=2.056, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] 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 jtbCZ6rvHcI9 for ; Wed, 23 May 2012 01:59:56 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id F338B21F8573 for ; Wed, 23 May 2012 01:59:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,644,1330902000"; d="scan'208,217";a="69477105" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 23 May 2012 10:59:55 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.35]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0283.003; Wed, 23 May 2012 10:59:55 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: New version (-01) of Leap Seconds draft Thread-Index: Ac04uLfUWBOC2FGpQYycKu7+aSlBwgACXTpA Date: Wed, 23 May 2012 08:59:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5DA0EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] New version (-01) of Leap Seconds draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 08:59:58 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5DA0EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Roni just pointed out that the name of the draft didn't follow the proper n= aming mechanism and the AVTCORE name was not included. Sorry about that. I have resubmitted the draft with the proper name: http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt Thanks, Ray From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brand= enburg, R. (Ray) van Sent: woensdag 23 mei 2012 9:51 To: avt@ietf.org Subject: [AVTCORE] New version (-01) of Leap Seconds draft Hi all, I've just uploaded a new version of the Leap Seconds draft (http://www.ietf= .org/id/draft-gross-leap-second-01.txt). The draft is meant as a small update to RFC3550 that improves RTP's reliabi= lity in the vicinity of a leap second. Among others it includes some requir= ements for RTP senders/receivers to have a functioning communicating channe= l to receive leap second scheduling updates (which, if not implemented, cou= ld mean a long-term discrepancy between sender and receiver of 1 second) an= d other requirements dealing with the short term effects of a leap second. In this -01 version of the draft we have included more references and fixed= a lot of typos. Thanks to Steve Allen for his contributions. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5DA0EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,<= /o:p>

 

Roni just = pointed out that the name of the draft didn’t follow the proper namin= g mechanism and the AVTCORE name was not included. Sorry about that.

 = ;

I have res= ubmitted the draft with the proper name:

 = ;

http://www.ietf.org/id/draft-gro= ss-avtcore-leap-second-00.txt

 = ;

Thanks,

 = ;

Ray=

 = ;

 = ;

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 9:51
To: avt@ietf.org
Subject: [AVTCORE] New version (-01) of Leap Seconds draft

 

Hi all,

 

I’ve just uploaded a new version = of the Leap Seconds draft (http://www.ietf.org/id/draft-gross-leap-second-01.txt= ).

 

The draft is meant as a small update to= RFC3550 that improves RTP’s reliability in the vicinity of a leap se= cond. Among others it includes some requirements for RTP senders/receivers to have a functioning communicating channel to receive leap second schedul= ing updates (which, if not implemented, could mean a long-term discrepancy = between sender and receiver of 1 second) and other requirements dealing wit= h the short term effects of a leap second.

 

In this -01 version of the draft we hav= e included more references and fixed a lot of typos. Thanks to Steve Allen = for his contributions.

 

Best regards,

 

Ray

 

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B5DA0EXCMBX03tsntnon_-- From aallison@nab.org Wed May 23 05:57:13 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D30D21F873D for ; Wed, 23 May 2012 05:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 LBODig5VBT4X for ; Wed, 23 May 2012 05:57:11 -0700 (PDT) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB8621F86FE for ; Wed, 23 May 2012 05:57:10 -0700 (PDT) Received: from unknown [208.97.234.91] by p01c11o141.mxlogic.net(mxl_mta-6.14.0-1) with SMTP id 6aedcbf4.0.62865.00-301.127934.p01c11o141.mxlogic.net (envelope-from ); Wed, 23 May 2012 06:57:11 -0600 (MDT) X-MXL-Hash: 4fbcdea714ab1c81-0215b0399259a9b6ff0511d6f5b04f95ac56762f X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD38E3.5B02E5BD" Date: Wed, 23 May 2012 08:55:39 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC6220200BE0025E@NABSREX027324.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] New version (-01) of Leap Seconds draft Thread-Index: Ac0441rKsqaz7UElT0WhJovNxIpBzw== From: "Art Allison" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=2.0 cv=DMQ4FVxb c=1 sm=0 a=tFGTPFZixTZ3yCXJchW01Q==:17 a] X-AnalysisOut: [=RqcU_iYGAjQA:10 a=BvPfnLs-15kA:10 a=BLceEmwcHowA:10 a=g0F] X-AnalysisOut: [pLpFZAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=9QhuTb1vAA] X-AnalysisOut: [AA:8 a=BMST1FQWsnwuDmLSJbQA:9 a=PAneP0cebhNLFg39s5QA:7 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=8SgyfJxrfqYA:10 a=-9UqKSle32gA:10 a=Qd000] X-AnalysisOut: [7q6B0YA:10 a=lZB815dzVvQA:10 a=joKS0OyH-SlWOfXC:21 a=MCLWu] X-AnalysisOut: [rp7rQX3bLMY:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=SCqjqv9] X-AnalysisOut: [EjTYR5hj5wbcA:9 a=z4WQpTk-aEYCyhA5KWgA:7 a=gKO2Hq4RSVkA:10] X-AnalysisOut: [ a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=uwJdCpC0CqdiOpzE:21] X-AnalysisOut: [ a=oQIzviuP_3PTSvqo:21] Subject: Re: [AVTCORE] New version (-01) of Leap Seconds draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 12:57:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD38E3.5B02E5BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I see no error, perhaps expanding the declaration of the time of the leap second by adding the following informative text will help make the sequence clearer. =20 The sequence of the second markers near the leap second transition are: =20 Day 0, 23h 59m 59s Day 0, 23h 59m 60s < leap second Day 1, 0h 0m 0s =20 =20 Art Allison=20 Senior Director Advanced Engineering, Technology=20 National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone 202 429 5418 Fax 202 775 4981=20 www.nab.org =20 Advocacy Education Innovation=20 =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Wednesday, May 23, 2012 3:51 AM To: avt@ietf.org Subject: [AVTCORE] New version (-01) of Leap Seconds draft =20 Hi all, =20 I've just uploaded a new version of the Leap Seconds draft (http://www.ietf.org/id/draft-gross-leap-second-01.txt). =20 The draft is meant as a small update to RFC3550 that improves RTP's reliability in the vicinity of a leap second. Among others it includes some requirements for RTP senders/receivers to have a functioning communicating channel to receive leap second scheduling updates (which, if not implemented, could mean a long-term discrepancy between sender and receiver of 1 second) and other requirements dealing with the short term effects of a leap second.=20 =20 In this -01 version of the draft we have included more references and fixed a lot of typos. Thanks to Steve Allen for his contributions. =20 Best regards, =20 Ray =20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------_=_NextPart_001_01CD38E3.5B02E5BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While I see no = error, perhaps expanding the declaration of the time of the leap second = by adding the following informative text will help make the sequence = clearer.

 

The = sequence of the second markers near the leap second transition = are:           &nb= sp;          =

     =             &= nbsp;           &n= bsp;

     =             &= nbsp;        Day 0,  23h 59m = 59s

     =             &= nbsp;        Day 0,  23h 59m 60s = < leap second

     =             &= nbsp;        Day = 1,     0h  0m  0s

 

 

Art Allison
Senior Director Advanced Engineering, Technology
National Association of Broadcasters
1771 N Street NW
Washington, = DC 20036
Phone  202 429 5418
Fax  202 775 = 4981
www.nab.org =
Advocacy  Education  Innovation

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: Wednesday, May 23, 2012 = 3:51 AM
To: avt@ietf.org
Subject: [AVTCORE] New = version (-01) of Leap Seconds draft

 

Hi = all,

 =

I’ve = just uploaded a new version of the Leap Seconds draft (http://www= .ietf.org/id/draft-gross-leap-second-01.txt).

 =

The draft = is meant as a small update to RFC3550 that improves RTP’s = reliability in the vicinity of a leap second. Among others it includes = some requirements for RTP senders/receivers to have a functioning = communicating channel to receive leap second scheduling updates (which, = if not implemented, could mean a long-term discrepancy between sender = and receiver of 1 second) and other requirements dealing with the short = term effects of a leap second.

 =

In this = -01 version of the draft we have included more references and fixed a = lot of typos. Thanks to Steve Allen for his = contributions.

 =

Best = regards,

 =

Ray

 =

This e-mail and its contents are subject to = the DISCLAIMER at http://www.tno.nl/emaildisclai= mer

------_=_NextPart_001_01CD38E3.5B02E5BD-- From ron.even.tlv@gmail.com Wed May 23 07:33:35 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13E921F86F8 for ; Wed, 23 May 2012 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.257, 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 BJJvxY4HY2Uz for ; Wed, 23 May 2012 07:33:34 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDFD21F86E5 for ; Wed, 23 May 2012 07:33:34 -0700 (PDT) Received: by bkty8 with SMTP id y8so7234190bkt.31 for ; Wed, 23 May 2012 07:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=rDmkPls7wOO9U1UZhj2khMp0etBz12f9U3ycX6kamAY=; b=E7G68Drn+bcajfNh0k7YGlBUOCwy6QJnja0Hr6Gt5YBI0ye5nWh+6fmDsoLAmkG/4S /Oh/DjvnoFE8qCpmG/4ac3UmrwXGx5q3jGZLf8GO0phog1AtdqvSa34ZIfgN4X/Hhcsy dtp3WKkp0/w0G5ovzmnCIoPXPHc6EGpjJzAZA5V2BeM41eY90YB0a8v24C0GnL51PY/Z uJYNPcO16ff3N8Rb7VlYKdvyGuIZHMc1d+3wtRSJI7M/PtvmpGR0OIFZrz81X3Ln+ZqP fYaf3dXKir8tghDi8eFQ+trWVNZqwV4FOZVbQMP+N5VFJp33juBHbAP9bDkR3e3GE+uO +V8w== Received: by 10.204.152.196 with SMTP id h4mr12226517bkw.131.1337783613202; Wed, 23 May 2012 07:33:33 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id ie3sm37623645bkc.1.2012.05.23.07.33.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 May 2012 07:33:32 -0700 (PDT) From: "Roni Even" To: Date: Wed, 23 May 2012 17:31:23 +0300 Message-ID: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01CD3909.E184D440" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac048LoYzASM67h6SCWUcM2QQPDa6Q== Content-Language: en-us Subject: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:33:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005D_01CD3909.E184D440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, At last IETF meeting as part of the discussion on IDMS is was agreed that support for leap seconds in RTP session is relevant to RFC3550 and not only to IDMS. We would like to take a new milestone for AVTcore Nov 2012 - Submit support for leap seconds for RTP session as Proposed Standard This will be an update to RFC 3550. We would also like to adopt http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a starting point for this goal. There are two questions to the WGs 1. Do you support the new milestone that will update RFC3550 2. Do you think that we should adopt the above individual draft as an initial document Please respond by June 6th Thanks Roni Even ------=_NextPart_000_005D_01CD3909.E184D440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At last IETF = meeting as part of the discussion on IDMS is was agreed that support for = leap seconds in RTP session is relevant to RFC3550 and not only to = IDMS.

We would like to take a new = milestone for AVTcore

 

Nov 2012 - = Submit support for leap seconds for RTP session  as Proposed = Standard

This will be an update to = RFC 3550.

 

We would also like to adopt ht= tp://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a = starting point for this goal.

 

There are = two questions to the WGs

 

1.       = Do you support the new = milestone that will update RFC3550

2.       = Do you think that we = should adopt the above individual draft as an initial = document

 

 

Please = respond by June 6th

 

Thanks

Roni = Even

 

------=_NextPart_000_005D_01CD3909.E184D440-- From marshall.eubanks@gmail.com Wed May 23 07:41:18 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86A21F8720 for ; Wed, 23 May 2012 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 L+1bj2KKGU8X for ; Wed, 23 May 2012 07:41:18 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A048221F86EF for ; Wed, 23 May 2012 07:41:17 -0700 (PDT) Received: by lagv3 with SMTP id v3so5979503lag.31 for ; Wed, 23 May 2012 07:41:16 -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:content-transfer-encoding; bh=4JYkhYlu7+xmFNtHqhVxBIC2oSg3M9URK+Y1fjWl70c=; b=qSXCSzsov2/KsBKubLYUNp25LSkKs10kvxguqkJjufk8f6p/uJcekiHihquy9MywIU BDW7R8t13BPR5Rm2pMgPFnI6lLo5zmv0NntWDoHSyayhrNXO2IBmF3HQZ0GbbkUT0cXM wVaRkVuTIiUV1flMQIrCNxzPcXoS4Av6s9qVCke8rX2AjFiVpPvmgjbwMZ8uyII1y9fm +HeZdJ6DKnbNoeuIJaFtea4swbfxJziCuhh1yyhEo34T/XDQibMw91MIQGAQPFNTlFtv Esx5mq1kpEenDA5QYqCN2LrCdrGHp1hFwOXorSHcpSc/UoYXDHcf+geIZpPxNFuGSoiu F5ZA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr17193389lab.40.1337784076621; Wed, 23 May 2012 07:41:16 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Wed, 23 May 2012 07:41:16 -0700 (PDT) In-Reply-To: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> References: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> Date: Wed, 23 May 2012 10:41:16 -0400 Message-ID: From: Marshall Eubanks To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:41:18 -0000 On Wed, May 23, 2012 at 10:31 AM, Roni Even wrote: > Hi, > > At last IETF meeting as part of the discussion on IDMS is was agreed that > support for leap seconds in RTP session is relevant to RFC3550 and not on= ly > to IDMS. > > We would like to take a new milestone for AVTcore > > > > Nov 2012 - Submit support for leap seconds for RTP session =A0as Proposed > Standard > > This will be an update to RFC 3550. > > > > We would also like to adopt > http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a starti= ng > point for this goal. > > > > There are two questions to the WGs > > > > 1.=A0=A0=A0=A0=A0=A0 Do you support the new milestone that will update RF= C3550 > Support. > 2.=A0=A0=A0=A0=A0=A0 Do you think that we should adopt the above individu= al draft as an > initial document > Need to read it first. It just came out. Marshall > > > > > Please respond by June 6th > > > > Thanks > > Roni Even > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From kevin.gross@avanw.com Wed May 23 08:28:58 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E5E21F8777 for ; Wed, 23 May 2012 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 j7afzNaugAJ6 for ; Wed, 23 May 2012 08:28:57 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 057D921F8770 for ; Wed, 23 May 2012 08:28:56 -0700 (PDT) Received: (qmail 9080 invoked by uid 0); 23 May 2012 15:28:56 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 23 May 2012 15:28:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=wAUWg4DINFZlJY17pTckH6wbc2rIWpxv0PnUzZOfQQM=; b=f33m9UCP1ICUE6f3V+JNUMzl+2VpOHsOybZ88rFKkWuSf1YuKJ6m3ZoTPpSVU8r8R/glUQUUWd9K9TDzeLYXtxL4VeV99J7WasBhfNvyANYTVP7pS6o1WrdHnZ2lEV0l; Received: from mail-wg0-f44.google.com ([74.125.82.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1SXDUd-0006d8-Hh for avt@ietf.org; Wed, 23 May 2012 09:28:55 -0600 Received: by wgbdr13 with SMTP id dr13so5055942wgb.13 for ; Wed, 23 May 2012 08:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.74.193 with SMTP id w1mr47194950wiv.4.1337786933229; Wed, 23 May 2012 08:28:53 -0700 (PDT) Received: by 10.223.115.133 with HTTP; Wed, 23 May 2012 08:28:53 -0700 (PDT) In-Reply-To: References: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> Date: Wed, 23 May 2012 09:28:53 -0600 Message-ID: From: Kevin Gross To: Marshall Eubanks Content-Type: multipart/alternative; boundary=f46d04374a0ff0b81c04c0b5ca64 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Cc: avt@ietf.org Subject: Re: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:28:58 -0000 --f46d04374a0ff0b81c04c0b5ca64 Content-Type: text/plain; charset=ISO-8859-1 The critical text in this draft was originally published on 2011-10-31 in draft-ietf-avtcore-idms-02. At IETF 83 it was decided that this should be split out as a separate draft. Kevin Gross On Wed, May 23, 2012 at 8:41 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Wed, May 23, 2012 at 10:31 AM, Roni Even > wrote: > > Hi, > > > > At last IETF meeting as part of the discussion on IDMS is was agreed that > > support for leap seconds in RTP session is relevant to RFC3550 and not > only > > to IDMS. > > > > We would like to take a new milestone for AVTcore > > > > > > > > Nov 2012 - Submit support for leap seconds for RTP session as Proposed > > Standard > > > > This will be an update to RFC 3550. > > > > > > > > We would also like to adopt > > http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a > starting > > point for this goal. > > > > > > > > There are two questions to the WGs > > > > > > > > 1. Do you support the new milestone that will update RFC3550 > > > > Support. > > > 2. Do you think that we should adopt the above individual draft as > an > > initial document > > > > Need to read it first. It just came out. > > Marshall > > > > > > > > > > > Please respond by June 6th > > > > > > > > Thanks > > > > Roni Even > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d04374a0ff0b81c04c0b5ca64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The critical text in this draft was originally published=A0on 2011-10-31=A0= in draft-ietf-avtcore-idms-02. At IETF 83 it was decided that this should b= e split out as a separate draft.

Kevin Gross
=

On Wed, May 23, 2012 at 8:41 AM, Marsh= all Eubanks <marshall.eubanks@gmail.com> wrote:
=
On Wed, May 23, 2012 at 10:31 AM, Roni Even <ron.even.tlv@gmail.com> wrote: > Hi,
>
> At last IETF meeting as part of the discussion on IDMS is was agreed t= hat
> support for leap seconds in RTP session is relevant to RFC3550 and not= only
> to IDMS.
>
> We would like to take a new milestone for AVTcore
>
>
>
> Nov 2012 - Submit support for leap seconds for RTP session =A0as Propo= sed
> Standard
>
> This will be an update to RFC 3550.
>
>
>
> We would also like to adopt
> http://www.ietf.org/id/draft-gross-avtcore-leap-secon= d-00.txt as a starting
> point for this goal.
>
>
>
> There are two questions to the WGs
>
>
>
> 1.=A0=A0=A0=A0=A0=A0 Do you support the new milestone that will update= RFC3550
>

Support.

> 2.=A0=A0=A0=A0=A0=A0 Do you think that we should adopt the above indiv= idual draft as an
> initial document
>

Need to read it first. It just came out.

Marshall

>
>
>
>
> Please respond by June 6th
>
>
>
> Thanks
>
> Roni Even
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d04374a0ff0b81c04c0b5ca64-- From eckelcu@cisco.com Wed May 23 12:29:35 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CF511E8089 for ; Wed, 23 May 2012 12:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] 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 YnnJ0WVbKRLa for ; Wed, 23 May 2012 12:29:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D313111E8076 for ; Wed, 23 May 2012 12:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4968; q=dns/txt; s=iport; t=1337801374; x=1339010974; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=eINX+2YbLEh06iVKkP+dPIknbxBub5SsfZ/YRLNEmXQ=; b=dHwcpws6UCYCmsfVusWrNJJl78k+uNKTOES4RUElDwI+bPgSLpUPRxba DAxGVWQKvBWwjX4nFMbzi8CfUrO+VvsuGFkytoQkpd3G3+6ieCVg6YO4V D4H9p3zhavwYK9r7qCbnbWBgCvu+Vojz2Py0ybQ8aHvhOq7De5lZL8qex Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHk5vU+rRDoJ/2dsb2JhbAA6CbQtgQeCFQEBAQMBAQEBDwEdCkQHBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCBqHZgQBC5sHn3QEin0RhC9gA4g/iH6RZ4Fkgwo X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208";a="43009633" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 23 May 2012 19:29:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4NJTYqG030166; Wed, 23 May 2012 19:29:34 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 12:29:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 May 2012 12:29:34 -0700 Message-ID: In-Reply-To: <4E75E88AD2C84AC6A3824697C4126DB2@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 Thread-Index: Ac04hBca/WRaC6caQDaG0qOatCglngAk+0bw References: <4FB2E323.3090406@nostrum.com> <4E75E88AD2C84AC6A3824697C4126DB2@china.huawei.com> From: "Charles Eckel (eckelcu)" To: "Qin Wu" , "Robert Sparks" , "IETF AVTCore WG" , X-OriginalArrivalTime: 23 May 2012 19:29:34.0500 (UTC) FILETIME=[6250AE40:01CD391A] Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 19:29:35 -0000 Hi Qin, The definitions section of the monarch draft needs to clearly define two important concepts: 1) direct vs. composed metrics 2) interval vs. cumulative vs. sampled metrics These are independent concepts, and the definitions need to be independent as well. For that reason, I think it is important to avoid any mixing of the two. Please see concerns regarding this inline. > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Qin Wu > Sent: Tuesday, May 22, 2012 6:31 PM > To: Robert Sparks; IETF AVTCore WG; draft-ietf-avtcore- > monarch@tools.ietf.org > Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore- > monarch-13 >=20 > >> The definitions of Interval, Cumulative, and Sampled metrics are not > clear. > > > > [Qin]: I agree the definition for these three metrics need to be more > cleaer, I proposes to do the following changes: > > > > NEW Text: > > > > " > > > > Interval metrics > > > > > > > > Metrics of which the reported values > > > > are measured in the most recent measurement interval duration > between > > > > successive metrics reports. Such measurement interval is equal > to one > > > > RTCP report interval (RFC3550,Section 6.2). > > > > > > > > > > > > Cumulative metrics > > > > > > > > Metrics of which the reported values > > > > apply to the accumulation period characteristic of cumulative > > > > measurements. The reported values are measured during the > accumulation period. > > > > The accumulation period spans over more than one RTCP report > intervals. > > > > > > > > > > > > Sampled metrics > > > > > > > > Metrics of which the reported values only > > > > apply to the value of a continuously measured or calculated > metric > > > > that has been sampled at any given instance of the RTCP report > interval. > > > > One example of such metric is the inter-arrival jitter described > in the section 6.4.1 of RFC3550. > > > > " > [Qin]: One improvement to definitions of Interval Metrics, Cumulative > Metrics and Sampled Metrics to get alignment with draft-ietf-xrblock- > rtcp-xr-meas-identity > since based on draft-ietf-xrblock-rtcp-xr-meas-identity, in some > case,the measurement interval for a metric is different from the RTCP > reporting interval, in such case, Measurement information block in the > draft-ietf-xrblock-rtcp-xr-meas-identity can be used to specify such > measurement interval. >=20 > The proposed improvement is described as follows: All three definitions that follow need to use equivalent language such that all three are clearly applicable to both direct and composed metrics. > " > Interval metrics: >=20 > Metrics calculated based on values measured over the course of a single > reporting interval. This may be the most recent RTCP reporting interval > ([RFC3550], section 6.2) or some other interval signalled using an RTCP > Measurement Information XR Block [draft-ietf-xrblock-rtcp-xr-meas- > identity]. An example interval metric is the count of the number of RTP > packets lost over the course of the last RTCP reporting interval. How about replacing "Metrics calculated based on values measured over the course ..." with "Metrics measured over the course ..."? =20 > Cumulative metrics: >=20 > Metrics derived from cumulative measurements taken over several > reporting intervals. The time period over which measurements are > accumulated can be the complete RTP session, or some other interval > signalled using an RTCP Measurement Information XR Block [draft-ietf- > xrblock-rtcp-xr-meas-identity]. An example cumulative metric is the > total number of RTP packets lost since the start of the RTP session. >=20 How about replacing "Metrics derived from cumulative measurements taken over several ..." with "Metrics measured over several ..."? > Sampled metrics: >=20 > Metrics that are sampled at a particular time instant within a > reporting interval (generally the value of some measurement as taken at > the end of the reporting interval). An example is the inter-arrival > jitter reported in RTCP SR and RR packets, which is continually updated > as each RTP data packet arrives, but only reported based on a snapshot > of the value which is sampled at the instant the reporting interval > ends. >=20 > " How about replacing "Metrics that are sampled at a particular time instant ..." with "Metrics measured at a particular time instant..."? This way the wording remains consistent across all three definitions without mixing in any terms that may be confused to adding ties specific to direct or composed metrics. Cheers, Charles > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From csp@csperkins.org Wed May 23 14:21:52 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FFB11E80C0; Wed, 23 May 2012 14:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, 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 tqQzltCUAVzR; Wed, 23 May 2012 14:21:49 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14111E8080; Wed, 23 May 2012 14:21:40 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SXIzz-0006Wa-hx; Wed, 23 May 2012 21:21:39 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins X-Priority: 3 In-Reply-To: <565CA625413A4126AF25B21F2EC5F71F@china.huawei.com> Date: Wed, 23 May 2012 22:21:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> <565CA625413A4126AF25B21F2EC5F71F@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1278) Cc: Albrecht Schwarz , avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:21:52 -0000 Qin, The text you propose is better, but I'm still not sure it's clear. I = wonder if it may be worth splitting that section into several = paragraphs, and giving a little more description. One paragraph could = discuss the possible locations for monitors: in end-systems, in = middleboxes that are an active part of an RTP session (e.g., RTP mixers = or translators), or in third-party devices that passively monitor an RTP = session. For each of these locations, you could then include a paragraph = that briefly explains the uses for monitors in that location, and the = types of metrics they're suited to monitoring, perhaps with examples.=20 Colin On 23 May 2012, at 04:22, Qin Wu wrote: > Hi, > Take Robert,Colin and Albrechet's comments into account, I propose to = rewrite section 3.3 with the following changes: > OLD TEXT: > " > 3.3. RTP Sender/Receiver entities located in network nodes >=20 > The location of the RTP Sender/Receiver entities may impact a set of > meaningful metrics. For instance, application level metrics for QoE > related performance parameters are under most conditions measured at > the user device that receives RTP data packets. However in some > cases, given the factors ( "measurement point location", = "measurement > model location", "awareness of content information", etc [P.NAMS]) > taken into account, such metrics may be measured in a network node > instead of a user device. >=20 > " > NEW TEXT: > " > 3.3. Measurement point of the RTP monitor within the network. >=20 > The RTP monitors are spread across a single domain(e.g., network = domain) or=20 > multiple domains (e.g., between network domain and service domain)in = the network. > The performance Metrics reported from the RTP monitor can be divided = into end system=20 > metrics, application level metrics, transport level metrics. Some of = these metrics=20 > may be specific to the measurement point of the RTP monitor or depend = on where=20 > the RTP monitors are located in the network. For instance, end system = metrics are only > available or measured at the RTP end system or terminal device. = Application level > metrics that reflect end to end user experience at the = application-level are measured=20 > more precise or less complicated at the RTP end system than measured = from intermediary=20 > system (e.g., the RTP media translator) in the nework. For transport = level metrics, takes > one way delay as an example, in the asymmetric network, the one way = delay measured=20 > at the RTP sender entity is different from one way delay measured at = the RTP=20 > receiver entity.=20 > " >=20 > Regards! > -Qin > ----- Original Message -----=20 > From: "Colin Perkins" > To: "Qin Wu" > Cc: "Albrecht Schwarz" ; > Sent: Tuesday, May 22, 2012 7:04 PM > Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 >=20 >=20 > I also don't agree with deleting Section 3.3 from the monarch draft.=20= >=20 > The architecture needs to be clear that there are valid scenarios for = RTP monitoring within a network, either in some middlebox that comprises = part of an RTP session, or in a third-party monitoring device used for = network management purposes. Section 3.3 is a reasonable place to = discuss these, and to explain why the metrics that can be reported from = middleboxes are different to those that can be captured at end systems. >=20 > Colin >=20 >=20 >=20 > On 22 May 2012, at 07:53, Qin Wu wrote: >> Hi,: >> ----- Original Message -----=20 >> From: "Albrecht Schwarz" >> To: >> Cc: ; >> Sent: Tuesday, May 22, 2012 11:18 AM >> Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 >>=20 >>=20 >> Dear All, >>=20 >> concerning the resolution proposal for clause 3.3: >> I don't agree in just deleting again that section! >> There was quite a long debate for incorporating such a clause. >> The original text proposal was much more detailed. Perhaps the = shortening to just a single paragraph is the main cause for unclarity. >> Thus, instead of removing previous agreed text, we just rather extend = it again. >>=20 >>=20 >> [Qin]:=20 >> The reason I propose to remove the section 3.3 is=20 >> a. I think Robert is correct. The set of meaningful metrics isn't = changed at all wherever you collect them. It seems little sense=20 >> to say "the location of the RTP Sender/Receiver entities may impact = a set of meaningful metrics. "=20 >> b. Where to gather or measure metrics can be indicated by the = definition of Transport metrics, End system metrics and application = level metrics. >> c. Section 3.3 seems to discuss where to gather what metrics. = Recommendation ITU-T G.1081 have already defined five monitoring points=20= >> where the performance measurements can be made. >>=20 >>> I think the definition of application level metrics has already = clarified that application level metrics is normally gathered from user = endpoint.=20 >>=20 >> No. We did discuss this already extensively. >> An RTP media translator could provide application level metrics = because e.g. terminating the application protocol layer. >> Such an RTP topology is NOT located in an user endpoint! >>=20 >> [Qin]: Sorry, I should correct me to say QoE metric is ususally = measured at the user endpoint. >>=20 >> Regards, >> Albrecht >> ________________________________ >> [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread = Index]=20 >> Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 >> ________________________________ >>=20 >> * To: Robert Sparks , IETF AVTCore WG , >> * Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 >> * From: Qin Wu >> * Date: Fri, 18 May 2012 18:37:56 +0800 >> * Delivered-to: avt at ietfa.amsl.com >> * List-archive: >> * List-help: >> * List-id: Audio/Video Transport Core Maintenance >> * List-post: >> * List-subscribe: , = >> * List-unsubscribe: , = >> * References: <4FB2E323.3090406 at nostrum.com> >> ________________________________ >>=20 >> Hi,Robert: >> Thank for your valuable review. please see my replies inline belows. = Regards! >> -Qin >> ----- Original Message -----=20 >> From: "Robert Sparks" >> To: "IETF AVTCore WG" ; >> Sent: Wednesday, May 16, 2012 7:13 AM >> Subject: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 > Summary: There are issues to resolve = with a revised ID before=20 >>> progressing to IETF LC. >>>=20 >>> It's a struggle to see the _architecture_ this document is supposed = to=20 >>> describe. I suspect most of the working group energy went into = Section 5=20 >>> (the guidelines for writing XR block definitions) - the rest of the=20= >>> document needs a similar level of attention to detail. >>>=20 >>> There are two major issues that I've tagged with a (*). I followed a=20= >>> mostly document-order flow instead of grouping the major issues at = the top. >>>=20 >>> (*) Given the document's title, it should be very easy to answer = "What=20 >>> is the monitoring architecture?" for people who are reading this = draft=20 >>> for the first time. >>> The key message is that the monitoring architecture consists of = Monitors=20 >>> that exchange information using RTCP Metric Blocks. [Qin]: Agree. = >The text should say=20 >>> that. [Qin]: Okay. > There is a lot of prose in section 3 and visual = detail in the=20 >>> diagram in Figure 1 that makes that extremely difficult to see.=20 >>> Simplifying the figure by removing the details about applications = and=20 >>> transports, or at least moving them to a second figure, making the=20= >>> Monitor boxes stand out, and making the types of information flows = (the=20 >>> arrows) visually distinctive would help. Simplify the prose (much of = it=20 >>> could be removed) to focus on that key message. [Qin]: Agree, I = propose to remove the figure 1 and squeeze the section 3.1 as follows: " = 3.1. Overview The RTP monitoring architecture comprises the following = two key functional components shown below: o RTP Monitor o RTP Metric = Block Structure RTP Monitor is the functional component defined in the = Real-time Transport Protocol [RFC3550]. It acts as a source of = information gathered for monitoring purposes and exchanges information = with the other RTP monitors using RTCP Metric Blocks. According to the = definition of monitor in the RTP Protocol [RFC3550], the end system that = runs an application program that sends or receives RTP data packets, an = intermediate- system that forwards RTP packets to End-devices or a third = party that observes the RTP and RTCP traffic but does not make itself = visible to the RTP Session participants (i.e., the third party monitor = depicted in figure 1) can act as the >> RTP monitor. The third party monitor should be placed on the RTP/RTCP = paths between the sender, intermediate and the receiver. The RTP monitor = also exposes real time Application QoS/QoE metric information in the = appropriate report block format (e.g.,RTCP XR or othe non-RTP means) to = the management system. Such information can be formulated as different = metric types, e.g.,application level metric, transport level metric, end = system metric, interval metric, cumulative metric, sampled metric, = direct metric, composed metric,etc. Both the RTCP or RTCP XR can be = extended to convey these metrics. The details on transport protocols for = these metric are described in Section 3.2. RTP may be used to multicast = groups, both Any Source Multicast (ASM) and Source Specific Multicast = (SSM). These groups can be monitored using RTCP. In the ASM case, the = monitor is a member of the multicast group and listens to RTCP XR = reports from all members of the ASM >> group. In the SSM case, there is a unicast feedback target that = receives RTCP feedback from receivers and distributes it to other = members of the SSM group (see figure 1 of RFC5760). The monitor will = need to be co-located with the feedback target to receive all feedback = from the receivers (this may also be an intermediate system). In both = ASM and SSM scenarios, receivers can send RTCP XR reports to enhance the = reception quality reporting. " > In the definition of Composed metrics, = the sentence "An example is a=20 >>> metric calculated based on derived metrics that have been measured."=20= >>> makes little sense. [Qin] The derived metrics in the sentence should = been corrected as "direct metric". >Did you mean something like "An = example is a metric=20 >>> derived by algorithmically combining measured metrics."? [Qin]:I = agree with your suggested text and like to adopt your suggestion. > The = definitions of Interval, Cumulative, and Sampled metrics are not clear. = [Qin]: I agree the definition for these three metrics need to be more = cleaer, I proposes to do the following changes: NEW Text: " Interval = metrics Metrics of which the reported values are measured in the most = recent measurement interval duration between successive metrics reports. = Such measurement interval is equal to one RTCP report interval = (RFC3550,Section 6.2). Cumulative metrics Metrics of which the reported = values apply to the accumulation period characteristic of cumulative = measurements. The reported values are measured during the accumulation = period. The accumulation period spans over more than one RTCP report = intervals. Sampled metrics Metrics of which the reported values only = apply to the value of a continuously measured or >> calculated metric that has been sampled at any given instance of the = RTCP report interval. One example of such metric is the inter-arrival = jitter described in the section 6.4.1 of RFC3550. " > If the discussion = at the end of section 3.1 is kept, the reference to=20 >>> RFC5760 should be a real reference, and RFC5760 should appear in the=20= >>> reference section. [Qin]: Okay. > The point of section 3.2 is not = obvious. How does it contribute to the=20 >>> description of the architecture. It mixes talking about what report=20= >>> blocks are with occasionally needing to send them more frequently. = Those=20 >>> points could be made separately and more simply. [Qin]: Okay. I like = to incorporate the key points in the section 3.2 into section 3.1 > = Section 3.3 is not clear - it starts off saying that the location of the=20= >>> sender and receiver may change what metrics are meaningful. It's not=20= >>> clear what you mean by location. You certainly don't mean geospatial=20= >>> coordinates. Do you mean anything other than whether the element is=20= >>> trusted or untrusted by the operations network? If so, say that. The=20= >>> rest of the paragraph only speaks to what element collects the = metrics. [Qin] Section 3.3 is only used to describe where or from which = RTP entity to gather the metrics (i.e., measurement point) in the = physical network and is not focus of this document. Secondly, I think = the definition of application level metrics has already clarified that = application level metrics is normally gathered from user endpoint. > = It's not clear that the set of meaningful metrics is changed at all -=20 >>> just where you collect them. If the set of meaningful metrics does = in=20 >>> fact change, there needs to be additional discussion here. [Qin]: = The metrics actually doesn't change.Since the definition of application = level metrics Have already conveyed the meaning of what section 3.3 = wants to describe, I propose to remove this section. > Section 4's first = paragraph: Is "probably" the best the working group=20 >>> can say? [Qin]:No, will remove this word. > The last two sentences = of the second bullet in section 4 do not parse.=20 >>> Please simplify them. [Qin]: Okay, how about change them as follows: = NEW Text: " With these minimal number of RTCP statistics parameters = mapped to non-RTCP measurements, it is hard to provide accurate measures = of real time application quality,conduct detailed data analysis and = creates alerts timly to the users. Therefore correlation between RTCP XR = and non-RTP data should be provided. " > The first full sentence of the = third bullet in section 4 does not make=20 >>> sense. The whole bullet could be clarified. [Qin]: Agree and will = remove the first sentence. > The fourth bullet in section 4 and section = 5.5 should call out that=20 >>> RFC3611 already set Block Type 255 aside for future extensions,=20 >>> anticipating the potential need to extend the block type space. = [Qin]: Okay, How about revising the section 4,bullet 4 as follows: " = Consumption of XR block code points. The RTCP XR block namespace is = limited by the 8-bit block type field in the RTCP XR header. Space = exhaustion may be a concern in the future. Anticipating the potential = need to extend the block type space, it is noted in [RFC3611] that Block = Type 255 is reserved for future extensions, " > In section 5, consider = naming the subsections with the actual guideline=20 >>> instead of the problem the guideline is trying to address. >>> 5.1. Metric blocks should contain a single metric [Qin]: I suggest = to change it as "Contain the single metrics in the metric block" > 5.2. = Include the payload type and format parameters in the metric block = [Qin]: Okay. > 5.3. Use RTCP SDES to correlate XR reports with non-RTP = data [Qin]: Okay. > 5.4. Don't repeat measurement information across = metric blocks >>>=20 >> [Qin]: It is not possible completely to avoid measurement information = repeatition. e.g., for packet loss robustness if the report blocks for = the same interval span over more than one RTCP packet then each must = have the same measurement identity information So I suggest to change it = as: "reduce measurement information across metric blocks" > This points = out a structural problem with the section. Why is 5.5 here?=20 >>> It's not a guideline. [Qin]: Agree and also as discussed,Space = exhaustion is not big issue. How about remove this section? > (*) And it = raises a question about what the document is trying to=20 >>> achieve with section 5.4. That section claims the document is = proposing=20 >>> a new XR block type to help avoid duplication, but it doesn't = actually=20 >>> define the new block type. Is the guideline saying simply don't = repeat=20 >>> measurements or its the guideline saying "use this new XR block type = we=20 >>> haven't defined yet"? [Qin]: Just to clarify, we have already = defined one new XR Block type to help avoid or reduce duplication. It is = measurement information block. The relevant draft is available at: = http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-meas-identity-06 = >The section needs more clarity. If it really is=20 >>> trying to define a new type, there's more work to be done. [Qin]: In = order to avoid such confusion, I proposed to do the following change to = the section 5.4: OLD Text: " This memo proposes to define a new XR Block = that will be used to convey the common time period and the number of = packets sent during this period. " New text: " This memo proposes to = define a new XR Block (i.e., the Measurement information = block[I.D-ietf-xrblock-rtcp-xr-meas-identity]) that will be used to = convey the common time period and the number of packets sent during this = period. " > The Security Considerations section, particularly the third = paragraph,=20 >>> needs to be clearer. What exactly do you mean by "monitoring should = be=20 >>> prohibited", and how is the fact that third party monitors don't = send=20 >>> RTCP relevant? Did you intend those to be separate points? [Qin]: = Yes, they are on the different port. Such monitor may receive RTP packet = but does not send RTCP packet. > Editorial Nits and Suggestions: >>>=20 >>> The first paragraph of the introduction is overly complex, and won't = age=20 >>> well. I suggest replacing it with: "Multimedia services using the=20 >>> Real-Time Protocol (RTP) are seeing increased use. Standard methods = for=20 >>> gathering RTP performance metrics from these applications are needed = to=20 >>> manage uncertainties in the behavior and availability of their=20 >>> services." Then replace "These rapidly emerging standards," with=20 >>> "Standards". [Qin]: Okay. > Introduction paragraph 3 sentence 2 = should start "The RTCP Guidelines=20 >>> [RFC5968]". It would be even better to use the full title from 5968:=20= >>> 'The "Guidelines for Extending the RTP Control Protocol (RTCP)" = [RFC5968]' [Qin]: Okay. > This may become moot as section 3 is modified = to make its main point=20 >>> more obvious, but RFC3550 does not characterize Monitors as "a = source of=20 >>> information". That could be misunderstood. Please choose another = word.=20 >>> Perhaps "repository"? [Qin]: Okay, repository looks good to me. > In = bullet lists, starting an entry with "or" or "and" is unnecessary. It=20 >>> should be clear from the introduction to the list whether the = individual=20 >>> entries should be combined or selected from. [Qin]: Okay. > In = section 3.1 where you say "RTP may be used to multicast groups" did=20 >>> you mean "RTP may be sent to multicast groups" or "RTP may be used = with=20 >>> multicast groups"? [Qin]: I think it should be the latter = case,i.e.," RTP may be used with=20 >> multicast groups". >=20 >>> In section 3.2 "The following are four use cases but are not limited=20= >>> to:" does not parse. The bullets aren't really use cases as much as = they=20 >>> are mechanisms. Would it make more sense to say "Here are four=20 >>> mechanisms that have been created to address the need for more = frequent=20 >>> reporting. This list is not intended to be exhaustive." The third = bullet=20 >>> in that list should say "RTCP and RTCP XR are" instead of "RTCP or = RTCP=20 >>> XR is". [Qin]: Okay, but I have incorporated the keypoints of = section 3.2 into section 3.1. > The bullets in section 4 would be better = as subsections with titles=20 >>> (taken from the first phrase of the bullet). [Qin]: Okay. > I = suggest this alternative for the first full sentence in the first=20 >>> bullet of section 4 : "A compound metrics block is designed to = contain a=20 >>> large number of parameters from different classes for a specific=20 >>> application in a single block." [Qin]: Okay. > Section 5's title = should be "Guidelines for reporting" instead of=20 >>> "Guideline for reporting" [Qin]: Okay. > In section 5.1 I suggest = "justify the overhead," instead of "justify the=20 >>> overheads," [Qin]: Okay. > Section 7 - the last sentence of the = first paragraph does not parse. The=20 >>> second paragraph (which is a single sentence) should be clarified - = an=20 >>> MCU is not a topology. [Qin]: Okay. How about revising them as = follows: OLD Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems do not behave according to the RTP protocol [RFC3550]. = Considering the MCU and translator are two typical topologies in the two = categories mentioned above, this document will take them as two typical = examples to explain how RTCP XR report works in different RFC5117 = topologies. " NEW Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems (e.g.,MCU) do not behave according to the RTP protocol = [RFC3550]. Considering the MCU and translator are two typical = intermediary systems in the two categories mentioned above, this = document will take them as two typical examples to explain how RTCP XR = report works in different RFC5117 topologies. " > The last two sentences = of the first >> paragraph of the security=20 >>> considerations section add nothing to the document. I suggest = deleting them. [Qin]: Okay. > = _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt at ietf.org >>> https://www.ietf.org/mailman/listinfo/avt > >> ________________________________ >>=20 >> * References:=20 >> * [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13=20 >> * From: Robert Sparks >> * Prev by Date: [AVTCORE] Protocol Action: 'Explicit Congestion = Notification (ECN) for RTP over=20 >> UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)=20 >> * Previous by thread: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13=20 >> * Next by thread: [AVTCORE] Protocol Action: 'Explicit Congestion = Notification (ECN) for RTP over=20 >> UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)=20 >> * Index(es):=20 >> * Date >> * Thread >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 --=20 Colin Perkins http://csperkins.org/ From albrechtschwarz@yahoo.de Wed May 23 18:13:00 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8E11E8088 for ; Wed, 23 May 2012 18:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6] 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 IIVzD1I+tHTq for ; Wed, 23 May 2012 18:13:00 -0700 (PDT) Received: from nm11-vm0.bullet.mail.ukl.yahoo.com (nm11-vm0.bullet.mail.ukl.yahoo.com [217.146.183.244]) by ietfa.amsl.com (Postfix) with SMTP id 6398211E8072 for ; Wed, 23 May 2012 18:12:59 -0700 (PDT) Received: from [217.146.183.213] by nm11.bullet.mail.ukl.yahoo.com with NNFMP; 24 May 2012 01:12:50 -0000 Received: from [217.146.183.170] by tm6.bullet.mail.ukl.yahoo.com with NNFMP; 24 May 2012 01:12:50 -0000 Received: from [127.0.0.1] by omp1011.mail.ukl.yahoo.com with NNFMP; 24 May 2012 01:12:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 943846.29852.bm@omp1011.mail.ukl.yahoo.com Received: (qmail 84000 invoked by uid 60001); 24 May 2012 01:12:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1337821970; bh=TKZsVig2bV1YZdGfVF3rGRe03euf870V691MQ7zIk7Q=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1iKsJ1ksx4SsuA+UbLsVpkirIEYf+DqOUf5UIeWZO8JAnRt8ro01WD37uObD3iigR4VovYBOKPp8pCir7NglVsHlM8zOwFkoaqzQ4GpkKPsJNpV3ZJcU/1OSI6zHpoeQoPg0GcVamtdSsjvz8u7xB6dpqt8f7FI9KfMJg19t8Fk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cD//vEoBNZ/HLSk7oVbXTsFsUZF+SMU+okKWoaaL/fM85/fOe8IB4aqH2LWhnu5pchL4GDfUT/DO0caGzZYa5/0Qmvh8B+oYEpgsdlPaBOCaJK4QyZgpCP9zFdpGKS7XcT0+/KtAsUNLHkUgkFEvadWWNOX3ZAAWc8PJ4gYqLmQ=; X-YMail-OSG: Al7_pLgVM1lck76hE9SUyEcBN8MjBtoSeJRXxlvadu5yU22 3UF4o_sgoTHUQUMIklLOsiVuiXAFK7SVJpbg.g5H2QOJ6RgGXFQjUbus0nHK 4X0sdYWI9n__kExwKXCFxTGEKwZN_p.ceOtidhgEIXWLF25Qm7I9be4CtNKO YDg_0Po8oDWDtIuLlLgXfSetlvP2Ls3kSj_EpFnAxT8OSCaBwW9e7._Ca2al pr9eXbXTbgLTiK8CnnBYfPBMWpyb3eM6QR_kqdog2G9CEAfMz1Xec0YLo7DJ R6XnS7Gfhnn.Zh0B.Yqs15mBhnYK73jsfJWeLyvmRBnWNrRoYvwlAkqhMp5O RbdQtBd63Y3LhOIkZBCndrKE8SlrRlwGYm4fAYKRA9VqKENNYG3thI27Ttqj 6J1aI0IXRT18o17bRpweDw_C__NGtMGzU5jttLJKotTs_mrTnIHjKrMHH2H. Ee88DgQWtKerc0DoHDsFr4uX1KJuGLWBVqvuPQUbmXq0OnVaJdnkA0RjHvfm JcaJmbHzUZBczowRThxTNxafTEYgD_VoZJ0a7cvFZOIcvH.VX0KEX4hmmZK9 6Gs1Ft2__.DrgGtu7OTgfm0pnRf9Chu8SfIcIrYQQKn64eWRvPQ-- Received: from [125.207.177.35] by web171005.mail.ukl.yahoo.com via HTTP; Thu, 24 May 2012 02:12:50 BST X-Mailer: YahooMailWebService/0.8.118.349524 References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> <565CA625413A4126AF25B21F2EC5F71F@china.huawei.com> Message-ID: <1337821970.83936.YahooMailNeo@web171005.mail.ukl.yahoo.com> Date: Thu, 24 May 2012 02:12:50 +0100 (BST) From: Albrecht Schwarz To: Colin Perkins , Qin Wu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-126313295-1805897683-1337821970=:83936" Cc: "avt@ietf.org" , "xrblock@ietf.org" Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Albrecht Schwarz List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:13:00 -0000 ---126313295-1805897683-1337821970=:83936 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would support that direction and structuring proposal.=0A=0ASide comment = to the notion of "end system metric":=0AWe should be carefully because it c= ould be interpretated in two directions:=0Aa) metric related to RTP topolog= y "RTP end system"=0Ab) metric related to user equipment=0A=0AThere's a sub= tle difference between both, the "RTP end system" FUNCTION could be located= in multiple different physical entities like user equipment, but also RTP-= to-X gateway equipment. The later ones are not located at the end of the ov= erall communication path.=0AConclusion for this example: e.g. QoE metrics (= as application level metrics) might be monitored in an "RTP end system" whe= n located in user equipment, but not if "RTP end system" would be located i= n network level equipment. Consequently, the association of QoE metrics as = "end system metrics" would be ambiguous.=0A=0AMy feeling:=0Awe don't need n= ecessarily the concept of an "end system metric", but we need a location co= ncept for RTP monitors with respect to the topology of the end-to-end commu= nication path ("which again might be completely e2e RTP based or some segme= nts might be non-RTP ...").=0A=0A-Albrecht=0A=0A=0A=0A=0A=0A>______________= __________________=0A> Von: Colin Perkins =0A>An: Qin Wu= =0A>CC: Albrecht Schwarz ; = avt@ietf.org; xrblock@ietf.org =0A>Gesendet: 23:21 Mittwoch, 23.Mai 2012=0A= >Betreff: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13= =0A> =0A>Qin,=0A>=0A>The text you propose is better, but I'm still not sure= it's clear. I wonder if it may be worth splitting that section into severa= l paragraphs, and giving a little more description. One paragraph could dis= cuss the possible locations for monitors: in end-systems, in middleboxes th= at are an active part of an RTP session (e.g., RTP mixers or translators), = or in third-party devices that passively monitor an RTP session. For each o= f these locations, you could then include a paragraph that briefly explains= the uses for monitors in that location, and the types of metrics they're s= uited to monitoring, perhaps with examples. =0A>=0A>Colin=0A>=0A>=0A>=0A>= =0A>On 23 May 2012, at 04:22, Qin Wu wrote:=0A>> Hi,=0A>> Take Robert,Colin= and Albrechet's comments into account, I propose to rewrite section 3.3 wi= th the following changes:=0A>> OLD TEXT:=0A>> "=0A>> 3.3.=A0 RTP Sender/Rec= eiver entities located in network nodes=0A>> =0A>>=A0 The location of the = RTP Sender/Receiver entities may impact a set of=0A>>=A0 meaningful metric= s.=A0 For instance, application level metrics for QoE=0A>>=A0 related perf= ormance parameters are under most conditions measured at=0A>>=A0 the user = device that receives RTP data packets.=A0 However in some=0A>>=A0 cases, g= iven the factors ( "measurement point location", "measurement=0A>>=A0 mode= l location", "awareness of content information", etc [P.NAMS])=0A>>=A0 tak= en into account, such metrics may be measured in a network node=0A>>=A0 in= stead of a user device.=0A>> =0A>> "=0A>> NEW TEXT:=0A>> "=0A>> 3.3. Measur= ement point of the RTP monitor within the network.=0A>> =0A>> The RTP monit= ors are spread across a single domain(e.g., network=A0 domain) or =0A>> mul= tiple domains (e.g., between network domain and service domain)in the netwo= rk.=0A>> The performance Metrics reported from the RTP monitor can be divid= ed into end system =0A>> metrics, application level metrics, transport leve= l metrics. Some of these metrics =0A>> may be specific to the measurement p= oint of the RTP monitor or depend on where =0A>> the RTP monitors are locat= ed in the network. For instance, end system metrics are only=0A>> available= or measured at the RTP end system or terminal device. Application level=0A= >> metrics that reflect end to end user experience at the application-level= are measured =0A>> more precise or less complicated at the RTP end system = than measured from intermediary =0A>> system (e.g., the RTP media translato= r) in the nework. For transport level metrics, takes=0A>> one way delay as = an example, in the asymmetric network, the one way delay measured =0A>> at = the RTP sender entity is different from one way delay measured at the RTP = =0A>> receiver entity. =0A>> "=0A>> =0A>> Regards!=0A>> -Qin=0A>> ----- Ori= ginal Message ----- =0A>> From: "Colin Perkins" =0A>> To= : "Qin Wu" =0A>> Cc: "Albrecht Schwarz" ; =0A>> Sent: Tuesday, May 22, 2012 7:04 PM=0A>> S= ubject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13= =0A>> =0A>> =0A>> I also don't agree with deleting Section 3.3 from the mon= arch draft. =0A>> =0A>> The architecture needs to be clear that there are v= alid scenarios for RTP monitoring within a network, either in some middlebo= x that comprises part of an RTP session, or in a third-party monitoring dev= ice used for network management purposes. Section 3.3 is a reasonable place= to discuss these, and to explain why the metrics that can be reported from= middleboxes are different to those that can be captured at end systems.=0A= >> =0A>> Colin=0A>> =0A>> =0A>> =0A>> On 22 May 2012, at 07:53, Qin Wu wrot= e:=0A>>> Hi,:=0A>>> ----- Original Message ----- =0A>>> From: "Albrecht Sch= warz" =0A>>> To: =0A>>> Cc: <= avt@ietf.org>; =0A>>> Sent: Tuesday, May 22, 2012 11:= 18 AM=0A>>> Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore= -monarch-13=0A>>> =0A>>> =0A>>> Dear All,=0A>>> =0A>>> concerning the resol= ution proposal for clause 3.3:=0A>>> I don't agree in just deleting again t= hat section!=0A>>> There was quite a long debate for incorporating such a c= lause.=0A>>> The original text proposal was much more detailed. Perhaps the= shortening to just a single paragraph is the main cause for unclarity.=0A>= >> Thus, instead of removing previous agreed text, we just rather extend it= again.=0A>>> =0A>>> =0A>>> [Qin]: =0A>>> The reason I propose to remove th= e section 3.3 is =0A>>> a. I think Robert is correct. The set of meaningful= metrics isn't changed at all=A0 wherever you collect them. It seems little= sense =0A>>>=A0 to say "the location of the RTP Sender/Receiver entities = may impact a set of meaningful metrics. " =0A>>> b. Where to gather or meas= ure metrics can be indicated by the definition of Transport metrics, End sy= stem metrics and application level metrics.=0A>>> c. Section 3.3 seems to d= iscuss where to gather what metrics. Recommendation ITU-T G.1081 have alrea= dy defined five monitoring points =0A>>>=A0 where the performance measurem= ents can be made.=0A>>> =0A>>>> I think the definition of application level= metrics has already clarified that=A0 application level metrics is normall= y gathered from user endpoint. =0A>>> =0A>>> No. We did discuss this alread= y extensively.=0A>>> An RTP media translator could provide application leve= l metrics because e.g. terminating the application protocol layer.=0A>>> Su= ch an RTP topology is NOT located in an user endpoint!=0A>>> =0A>>> [Qin]: = Sorry, I should correct me to say QoE metric is ususally measured at the us= er endpoint.=0A>>> =0A>>> Regards,=0A>>> Albrecht=0A>>> ___________________= _____________=0A>>> [Date Prev][Date Next][Thread Prev][Thread Next][Date I= ndex][Thread Index] =0A>>> Re: [AVTCORE] Subject: AD review of draft-ietf-a= vtcore-monarch-13=0A>>> ________________________________=0A>>> =0A>>> * To:= Robert Sparks , IETF AVTCore WG = , =0A>>> * Subject: Re: [AVTC= ORE] Subject: AD review of draft-ietf-avtcore-monarch-13=0A>>> * From: Qin = Wu =0A>>> * Date: Fri, 18 May 2012 18:37:56 +0800=0A= >>> * Delivered-to: avt at ietfa.amsl.com=0A>>> * List-archive: =0A>>> * List-help: =0A>>> * List-id: Audio/Video Transport Core Maintenanc= e =0A>>> * List-post: =0A>>> * List-subs= cribe: , =0A>>> * List-unsubscribe: , = =0A>>> * References: <4FB2E323.3090406 at nostrum.com>=0A>>> ______________= __________________=0A>>> =0A>>> Hi,Robert:=0A>>> Thank for your valuable re= view. please see my replies inline belows. Regards!=0A>>> -Qin=0A>>> ----- = Original Message ----- =0A>>> From: "Robert Sparks" =0A>>> To: "IETF AVTCore WG" ; =0A>>> Sent: Wednesday, May 16, 2012 7:13 AM=0A>>> Sub= ject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 > Summa= ry: There are issues to resolve with a revised ID before =0A>>>> progressin= g to IETF LC.=0A>>>> =0A>>>> It's a struggle to see the _architecture_ this= document is supposed to =0A>>>> describe. I suspect most of the working gr= oup energy went into Section 5 =0A>>>> (the guidelines for writing XR block= definitions) - the rest of the =0A>>>> document needs a similar level of a= ttention to detail.=0A>>>> =0A>>>> There are two major issues that I've tag= ged with a (*). I followed a =0A>>>> mostly document-order flow instead of = grouping the major issues at the top.=0A>>>> =0A>>>> (*) Given the document= 's title, it should be very easy to answer "What =0A>>>> is the monitoring = architecture?" for people who are reading this draft =0A>>>> for the first = time.=0A>>>> The key message is that the monitoring architecture consists o= f Monitors =0A>>>> that exchange information using RTCP Metric Blocks. [Qin= ]: Agree. >The text should say =0A>>>> that. [Qin]: Okay. > There is a lot = of prose in section 3 and visual detail in the =0A>>>> diagram in Figure 1 = that makes that extremely difficult to see. =0A>>>> Simplifying the figure = by removing the details about applications and =0A>>>> transports, or at le= ast moving them to a second figure, making the =0A>>>> Monitor boxes stand = out, and making the types of information flows (the =0A>>>> arrows) visuall= y distinctive would help. Simplify the prose (much of it =0A>>>> could be r= emoved) to focus on that key message. [Qin]: Agree, I propose to remove the= figure 1 and squeeze the section 3.1 as follows: " 3.1. Overview The RTP m= onitoring architecture comprises the following two key functional component= s shown below: o RTP Monitor o RTP Metric Block Structure RTP Monitor is th= e functional component defined in the Real-time Transport Protocol [RFC3550= ]. It acts as a source of information gathered for monitoring purposes and = exchanges information with the other RTP monitors using RTCP Metric Blocks.= According to the definition of monitor in the RTP Protocol [RFC3550], the = end system that runs an application program that sends or receives RTP data= packets, an intermediate- system that forwards RTP packets to End-devices = or a third party that observes the RTP and RTCP traffic but does not make i= tself visible to the RTP Session participants (i.e., the third party monito= r depicted in figure 1) can act as the=0A>>> RTP monitor. The third party m= onitor should be placed on the RTP/RTCP paths between the sender, intermedi= ate and the receiver. The RTP monitor also exposes real time Application Qo= S/QoE metric information in the appropriate report block format (e.g.,RTCP = XR or othe non-RTP means) to the management system. Such information can be= formulated as different metric types, e.g.,application level metric, trans= port level metric, end system metric, interval metric, cumulative metric, s= ampled metric, direct metric, composed metric,etc. Both the RTCP or RTCP XR= can be extended to convey these metrics. The details on transport protocol= s for these metric are described in Section 3.2. RTP may be used to multica= st groups, both Any Source Multicast (ASM) and Source Specific Multicast (S= SM). These groups can be monitored using RTCP. In the ASM case, the monitor= is a member of the multicast group and listens to RTCP XR reports from all= members of the ASM=0A>>> group. In the SSM case, there is a unicast feedba= ck target that receives RTCP feedback from receivers and distributes it to = other members of the SSM group (see figure 1 of RFC5760). The monitor will = need to be co-located with the feedback target to receive all feedback from= the receivers (this may also be an intermediate system). In both ASM and S= SM scenarios, receivers can send RTCP XR reports to enhance the reception q= uality reporting. " > In the definition of Composed metrics, the sentence "= An example is a =0A>>>> metric calculated based on derived metrics that hav= e been measured." =0A>>>> makes little sense. [Qin] The derived metrics in = the sentence should been corrected as "direct metric". >Did you mean someth= ing like "An example is a metric =0A>>>> derived by algorithmically combini= ng measured metrics."? [Qin]:I agree with your suggested text and like to a= dopt your suggestion. > The definitions of Interval, Cumulative, and Sample= d metrics are not clear. [Qin]: I agree the definition for these three metr= ics need to be more cleaer, I proposes to do the following changes: NEW Tex= t: " Interval metrics Metrics of which the reported values are measured in = the most recent measurement interval duration between successive metrics re= ports. Such measurement interval is equal to one RTCP report interval (RFC3= 550,Section 6.2). Cumulative metrics Metrics of which the reported values a= pply to the accumulation period characteristic of cumulative measurements. = The reported values are measured during the accumulation period. The accumu= lation period spans over more than one RTCP report intervals. Sampled metri= cs Metrics of which the reported values only apply to the value of a contin= uously measured or=0A>>> calculated metric that has been sampled at any giv= en instance of the RTCP report interval. One example of such metric is the = inter-arrival jitter described in the section 6.4.1 of RFC3550. " > If the = discussion at the end of section 3.1 is kept, the reference to =0A>>>> RFC5= 760 should be a real reference, and RFC5760 should appear in the =0A>>>> re= ference section. [Qin]: Okay. > The point of section 3.2 is not obvious. Ho= w does it contribute to the =0A>>>> description of the architecture. It mix= es talking about what report =0A>>>> blocks are with occasionally needing t= o send them more frequently. Those =0A>>>> points could be made separately = and more simply. [Qin]: Okay. I like to incorporate the key points in the s= ection 3.2 into section 3.1 > Section 3.3 is not clear - it starts off sayi= ng that the location of the =0A>>>> sender and receiver may change what met= rics are meaningful. It's not =0A>>>> clear what you mean by location. You = certainly don't mean geospatial =0A>>>> coordinates. Do you mean anything o= ther than whether the element is =0A>>>> trusted or untrusted by the operat= ions network? If so, say that. The =0A>>>> rest of the paragraph only speak= s to what element collects the metrics. [Qin] Section 3.3 is only used to d= escribe where or from which RTP entity to gather the metrics (i.e., measure= ment point) in the physical network and is not focus of this document. Seco= ndly, I think the definition of application level metrics has already clari= fied that application level metrics is normally gathered from user endpoint= . > It's not clear that the set of meaningful metrics is changed at all - = =0A>>>> just where you collect them. If the set of meaningful metrics does = in =0A>>>> fact change, there needs to be additional discussion here. [Qin]= : The metrics actually doesn't change.Since the definition of application l= evel metrics Have already conveyed the meaning of what section 3.3 wants to= describe, I propose to remove this section. > Section 4's first paragraph:= Is "probably" the best the working group =0A>>>> can say? [Qin]:No, will r= emove this word. > The last two sentences of the second bullet in section 4= do not parse. =0A>>>> Please simplify them. [Qin]: Okay, how about change = them as follows: NEW Text: " With these minimal number of RTCP statistics p= arameters mapped to non-RTCP measurements, it is hard to provide accurate m= easures of real time application quality,conduct detailed data analysis and= creates alerts timly to the users. Therefore correlation between RTCP XR a= nd non-RTP data should be provided. " > The first full sentence of the thir= d bullet in section 4 does not make =0A>>>> sense. The whole bullet could b= e clarified. [Qin]: Agree and will remove the first sentence. > The fourth = bullet in section 4 and section 5.5 should call out that =0A>>>> RFC3611 al= ready set Block Type 255 aside for future extensions, =0A>>>> anticipating = the potential need to extend the block type space. [Qin]: Okay, How about r= evising the section 4,bullet 4 as follows: " Consumption of XR block code p= oints. The RTCP XR block namespace is limited by the 8-bit block type field= in the RTCP XR header. Space exhaustion may be a concern in the future. An= ticipating the potential need to extend the block type space, it is noted i= n [RFC3611] that Block Type 255 is reserved for future extensions, " > In s= ection 5, consider naming the subsections with the actual guideline =0A>>>>= instead of the problem the guideline is trying to address.=0A>>>> 5.1. Met= ric blocks should contain a single metric [Qin]: I suggest to change it as = "Contain the single metrics in the metric block" > 5.2. Include the payload= type and format parameters in the metric block [Qin]: Okay. > 5.3. Use RTC= P SDES to correlate XR reports with non-RTP data [Qin]: Okay. > 5.4. Don't = repeat measurement information across metric blocks=0A>>>> =0A>>> [Qin]: It= is not possible completely to avoid measurement information repeatition. e= .g., for packet loss robustness if the report blocks for the same interval = span over more than one RTCP packet then each must have the same measuremen= t identity information So I suggest to change it as: "reduce measurement in= formation across metric blocks" > This points out a structural problem with= the section. Why is 5.5 here? =0A>>>> It's not a guideline. [Qin]: Agree a= nd also as discussed,Space exhaustion is not big issue. How about remove th= is section? > (*) And it raises a question about what the document is tryin= g to =0A>>>> achieve with section 5.4. That section claims the document is = proposing =0A>>>> a new XR block type to help avoid duplication, but it doe= sn't actually =0A>>>> define the new block type. Is the guideline saying si= mply don't repeat =0A>>>> measurements or its the guideline saying "use thi= s new XR block type we =0A>>>> haven't defined yet"? [Qin]: Just to clarify= , we have already defined one new XR Block type to help avoid or reduce dup= lication. It is measurement information block. The relevant draft is availa= ble at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-meas-identity= -06 >The section needs more clarity. If it really is =0A>>>> trying to defi= ne a new type, there's more work to be done. [Qin]: In order to avoid such = confusion, I proposed to do the following change to the section 5.4: OLD Te= xt: " This memo proposes to define a new XR Block that will be used to conv= ey the common time period and the number of packets sent during this period= . " New text: " This memo proposes to define a new XR Block (i.e., the Meas= urement information block[I.D-ietf-xrblock-rtcp-xr-meas-identity]) that wil= l be used to convey the common time period and the number of packets sent d= uring this period. " > The Security Considerations section, particularly th= e third paragraph, =0A>>>> needs to be clearer. What exactly do you mean by= "monitoring should be =0A>>>> prohibited", and how is the fact that third = party monitors don't send =0A>>>> RTCP relevant? Did you intend those to be= separate points? [Qin]: Yes, they are on the different port. Such monitor = may receive RTP packet but does not send RTCP packet. > Editorial Nits and = Suggestions:=0A>>>> =0A>>>> The first paragraph of the introduction is over= ly complex, and won't age =0A>>>> well. I suggest replacing it with: "Multi= media services using the =0A>>>> Real-Time Protocol (RTP) are seeing increa= sed use. Standard methods for =0A>>>> gathering RTP performance metrics fro= m these applications are needed to =0A>>>> manage uncertainties in the beha= vior and availability of their =0A>>>> services." Then replace "These rapid= ly emerging standards," with =0A>>>> "Standards". [Qin]: Okay. > Introducti= on paragraph 3 sentence 2 should start "The RTCP Guidelines =0A>>>> [RFC596= 8]". It would be even better to use the full title from 5968: =0A>>>> 'The = "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968]' [Qin]= : Okay. > This may become moot as section 3 is modified to make its main po= int =0A>>>> more obvious, but RFC3550 does not characterize Monitors as "a = source of =0A>>>> information". That could be misunderstood. Please choose = another word. =0A>>>> Perhaps "repository"? [Qin]: Okay, repository looks g= ood to me. > In bullet lists, starting an entry with "or" or "and" is unnec= essary. It =0A>>>> should be clear from the introduction to the list whethe= r the individual =0A>>>> entries should be combined or selected from. [Qin]= : Okay. > In section 3.1 where you say "RTP may be used to multicast groups= " did =0A>>>> you mean "RTP may be sent to multicast groups" or "RTP may be= used with =0A>>>> multicast groups"? [Qin]: I think it should be the latte= r case,i.e.," RTP may be used with =0A>>> multicast groups". > =0A>>>> In s= ection 3.2 "The following are four use cases but are not limited =0A>>>> to= :" does not parse. The bullets aren't really use cases as much as they =0A>= >>> are mechanisms. Would it make more sense to say "Here are four =0A>>>> = mechanisms that have been created to address the need for more frequent =0A= >>>> reporting. This list is not intended to be exhaustive." The third bull= et =0A>>>> in that list should say "RTCP and RTCP XR are" instead of "RTCP = or RTCP =0A>>>> XR is". [Qin]: Okay, but I have incorporated the keypoints = of section 3.2 into section 3.1. > The bullets in section 4 would be better= as subsections with titles =0A>>>> (taken from the first phrase of the bul= let). [Qin]: Okay. > I suggest this alternative for the first full sentence= in the first =0A>>>> bullet of section 4 : "A compound metrics block is de= signed to contain a =0A>>>> large number of parameters from different class= es for a specific =0A>>>> application in a single block." [Qin]: Okay. > Se= ction 5's title should be "Guidelines for reporting" instead of =0A>>>> "Gu= ideline for reporting" [Qin]: Okay. > In section 5.1 I suggest "justify the= overhead," instead of "justify the =0A>>>> overheads," [Qin]: Okay. > Sect= ion 7 - the last sentence of the first paragraph does not parse. The =0A>>>= > second paragraph (which is a single sentence) should be clarified - an = =0A>>>> MCU is not a topology. [Qin]: Okay. How about revising them as foll= ows: OLD Text: " The topologies in this category are Topo-Video-Switch-MCU = and Topo-RTCP-terminating-MCU. Such topologies based on systems do not beha= ve according to the RTP protocol [RFC3550]. Considering the MCU and transla= tor are two typical topologies in the two categories mentioned above, this = document will take them as two typical examples to explain how RTCP XR repo= rt works in different RFC5117 topologies. " NEW Text: " The topologies in t= his category are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such = topologies based on systems (e.g.,MCU) do not behave according to the RTP p= rotocol [RFC3550]. Considering the MCU and translator are two typical inter= mediary systems in the two categories mentioned above, this document will t= ake them as two typical examples to explain how RTCP XR report works in dif= ferent RFC5117 topologies. " > The last two sentences of the first=0A>>> pa= ragraph of the security =0A>>>> considerations section add nothing to the d= ocument. I suggest deleting them. [Qin]: Okay. > __________________________= _____________________=0A>>>> Audio/Video Transport Core Maintenance=0A>>>> = avt at ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/avt >=0A>>> __= ______________________________=0A>>> =0A>>> * References: =0A>>> * [AVTCORE= ] Subject: AD review of draft-ietf-avtcore-monarch-13 =0A>>> * From: Robert= Sparks=0A>>> * Prev by Date: [AVTCORE] Protocol Action: 'Explicit Congesti= on Notification (ECN) for RTP over =0A>>> UDP' to Proposed Standard (draft-= ietf-avtcore-ecn-for-rtp-08.txt) =0A>>> * Previous by thread: [AVTCORE] Sub= ject: AD review of draft-ietf-avtcore-monarch-13 =0A>>> * Next by thread: [= AVTCORE] Protocol Action: 'Explicit Congestion Notification (ECN) for RTP o= ver =0A>>> UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt= ) =0A>>> * Index(es): =0A>>> * Date=0A>>> * Thread=0A>>> __________________= _____________________________=0A>>> Audio/Video Transport Core Maintenance= =0A>>> avt@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/avt=0A>> = =0A>> =0A>> =0A>> -- =0A>> Colin Perkins=0A>> http://csperkins.org/=0A>> = =0A>> =0A>=0A>=0A>=0A>-- =0A>Colin Perkins=0A>http://csperkins.org/=0A>=0A>= =0A>=0A>=0A>=0A> ---126313295-1805897683-1337821970=:83936 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I would support that direction and structuring proposal.

Side comment to the notion of "end syste= m metric":
We should be carefully because it could be inte= rpretated in two directions:
a) metric related to RTP topology "R= TP end system"
b) metric related to user equipment

=
There's a subtle difference between both, the "RTP end system" F= UNCTION could be located in multiple different physical entities like user = equipment, but also RTP-to-X gateway equipment. The later ones are not loca= ted at the end of the overall communication path.
Conclusion for = this example: e.g. QoE metrics (as application level metrics) might be moni= tored in an "RTP end system" when located in user equipment, but not if "RTP end system" would be located in network level equipment. Consequen= tly, the association of QoE metrics as "end system metrics" would be ambigu= ous.

My feeling:
we don't need necessari= ly the concept of an "end system metric", but we need a location concept fo= r RTP monitors with respect to the topology of the end-to-end communication= path ("which again might be completely e2e RTP based or some segments migh= t be non-RTP ...").

-Albrecht


Von: Colin Perkins <csp@csperkin= s.org>
An: Qin Wu &= lt;bill.wu@huawei.com>
CC: Albrecht Schwarz <albrechtschwarz@yahoo.de>; avt@ietf.org; xr= block@ietf.org
Gesendet:<= /b> 23:21 Mittwoch, 23.Mai 2012
B= etreff: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-m= onarch-13

Qin,

The text you propose is better= , but I'm still not sure it's clear. I wonder if it may be worth splitting = that section into several paragraphs, and giving a little more description.= One paragraph could discuss the possible locations for monitors: in end-sy= stems, in middleboxes that are an active part of an RTP session (e.g., RTP = mixers or translators), or in third-party devices that passively monitor an RTP session. For each of these locations, you could then include a paragra= ph that briefly explains the uses for monitors in that location, and the ty= pes of metrics they're suited to monitoring, perhaps with examples.
Colin




On 23 May 2012, at 04:22, Qin Wu wrote:
> H= i,
> Take Robert,Colin and Albrechet's comments into account, I propo= se to rewrite section 3.3 with the following changes:
> OLD TEXT:
= > "
> 3.3.  RTP Sender/Receiver entities located in network n= odes
>
>  The location of the RTP Sender/Receiver entiti= es may impact a set of
>  meaningful metrics.  For instanc= e, application level metrics for QoE
>  related performance par= ameters are under most conditions measured at
>  the user devic= e that receives RTP data packets.  However in some
>  case= s, given the factors ( "measurement point location", "measurement
>  model location", "awareness of content informa= tion", etc [P.NAMS])
>  taken into account, such metrics may be= measured in a network node
>  instead of a user device.
>= ;
> "
> NEW TEXT:
> "
> 3.3. Measurement point of = the RTP monitor within the network.
>
> The RTP monitors are s= pread across a single domain(e.g., network  domain) or
> multip= le domains (e.g., between network domain and service domain)in the network.=
> The performance Metrics reported from the RTP monitor can be divid= ed into end system
> metrics, application level metrics, transport l= evel metrics. Some of these metrics
> may be specific to the measure= ment point of the RTP monitor or depend on where
> the RTP monitors = are located in the network. For instance, end system metrics are only
&g= t; available or measured at the RTP end system or terminal device. Application level
> metrics that reflect end to end user experience = at the application-level are measured
> more precise or less complic= ated at the RTP end system than measured from intermediary
> system = (e.g., the RTP media translator) in the nework. For transport level metrics= , takes
> one way delay as an example, in the asymmetric network, the= one way delay measured
> at the RTP sender entity is different from= one way delay measured at the RTP
> receiver entity.
> "
= >
> Regards!
> -Qin
> ----- Original Message ----- > From: "Colin Perkins" <csp@csperkins.org>
> To: "Qin = Wu" <bill.wu@huawei.com>
> Cc: "Albrecht Schwarz" <albrechtschwarz@yahoo.de>;= <avt@ie= tf.org>
> Sent: Tuesday, May 22, 2012 7:04 PM
> Subject:= Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13
> =
>
> I also don't agree with deleting Section 3.3 from the mon= arch draft.
>
> The architecture needs to be clear that there= are valid scenarios for RTP monitoring within a network, either in some mi= ddlebox that comprises part of an RTP session, or in a third-party monitori= ng device used for network management purposes. Section 3.3 is a reasonable= place to discuss these, and to explain why the metrics that can be reporte= d from middleboxes are different to those that can be captured at end syste= ms.
>
> Colin
>
>
>
> On 22 May 201= 2, at 07:53, Qin Wu wrote:
>> Hi,:
>> ----- Original Message -----
>> From: "Albrecht Schwarz" <albre= chtschwarz@yahoo.de>
>> To: <bill.wu@huawei.com>=
>> Cc: <avt@ietf.org>; <rjsparks@nostrum.com>
&g= t;> Sent: Tuesday, May 22, 2012 11:18 AM
>> Subject: Re: [AVTCO= RE] Subject: AD review of draft-ietf-avtcore-monarch-13
>>
>= ;>
>> Dear All,
>>
>> concerning the resolu= tion proposal for clause 3.3:
>> I don't agree in just deleting ag= ain that section!
>> There was quite a long debate for incorporati= ng such a clause.
>> The original text proposal was much more deta= iled. Perhaps the shortening to just a single paragraph is the main cause for un= clarity.
>> Thus, instead of removing previous agreed text, we jus= t rather extend it again.
>>
>>
>> [Qin]:
= >> The reason I propose to remove the section 3.3 is
>> a. = I think Robert is correct. The set of meaningful metrics isn't changed at a= ll  wherever you collect them. It seems little sense
>> = ; to say "the location of the RTP Sender/Receiver entities may impact a se= t of meaningful metrics. "
>> b. Where to gather or measure metri= cs can be indicated by the definition of Transport metrics, End system metr= ics and application level metrics.
>> c. Section 3.3 seems to disc= uss where to gather what metrics. Recommendation ITU-T G.1081 have already = defined five monitoring points
>>  where the performance me= asurements can be made.
>>
>>> I think the definition of application level metrics has already clarified that  a= pplication level metrics is normally gathered from user endpoint.
>&= gt;
>> No. We did discuss this already extensively.
>> A= n RTP media translator could provide application level metrics because e.g.= terminating the application protocol layer.
>> Such an RTP topolo= gy is NOT located in an user endpoint!
>>
>> [Qin]: Sorr= y, I should correct me to say QoE metric is ususally measured at the user e= ndpoint.
>>
>> Regards,
>> Albrecht
>>= ________________________________
>> [Date Prev][Date Next][Thread= Prev][Thread Next][Date Index][Thread Index]
>> Re: [AVTCORE] Su= bject: AD review of draft-ietf-avtcore-monarch-13
>> _____________= ___________________
>>
>> * To: Robert Sparks <rjspar= ks at nostrum.com>, IETF AVTCore WG <avt at ietf.org>, <draft-ietf-avtcore-monarch at tools.ietf.org>
>> * Subject= : Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13
>= > * From: Qin Wu <bill.wu at huawei.com>
>> * Date: Fri, = 18 May 2012 18:37:56 +0800
>> * Delivered-to: avt at ietfa.amsl.co= m
>> * List-archive: <http://www.ietf.org/mail-archive/web/avt&= gt;
>> * List-help: <mailto:avt-request@ietf.org?subje= ct=3Dhelp>
>> * List-id: Audio/Video Transport Core Maintenance= <avt.ietf.org>
>> * List-post: <mailto:avt@ietf.org>
>= > * List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=3Dsubscribe>
>&g= t; * List-unsubscribe: <https://www.ietf.org/mailman/options/avt>, &l= t;mailto:avt-request@ietf.org?subject=3Dunsubscribe>
>>= ; * References: <4FB2E323.3090406 at nostrum.com>
>> _______= _________________________
>>
>> Hi,Robert:
>> T= hank for your valuable review. please see my replies inline belows. Regards= !
>> -Qin
>> ----- Original Message -----
>> Fr= om: "Robert Sparks" <rjsparks at nostrum.com>
>> To: "IETF A= VTCore WG" <avt at ietf.org>; <draft-ietf-avtcore-monarch at tools= .ietf.org>
>> Sent: Wednesday, May 16, 2012 7:13 AM
>>= Subject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 > Summary= : There are issues to resolve with a revised ID before
>>> pro= gressing to IETF LC.
>>>
>>> It's a struggle to se= e the _architecture_ this document is supposed to
>>> describe= . I suspect most of the working group energy went into Section 5
>&g= t;> (the guidelines for writing XR block definitions) - the rest of the =
>>> document needs a similar level of attention to detail.
= >>>
>>> There are two major issues that I've tagged w= ith a (*). I followed a
>>> mostly document-order flow instead= of grouping the major issues at the top.
>>>
>>> = (*) Given the document's title, it should be very easy to answer "What
= >>> is the monitoring architecture?" for people who are reading th= is draft
>>> for the first time.
>>> The key message is that the monitoring architecture consists of Monitors
&= gt;>> that exchange information using RTCP Metric Blocks. [Qin]: Agre= e. >The text should say
>>> that. [Qin]: Okay. > There i= s a lot of prose in section 3 and visual detail in the
>>> dia= gram in Figure 1 that makes that extremely difficult to see.
>>&g= t; Simplifying the figure by removing the details about applications and >>> transports, or at least moving them to a second figure, maki= ng the
>>> Monitor boxes stand out, and making the types of in= formation flows (the
>>> arrows) visually distinctive would he= lp. Simplify the prose (much of it
>>> could be removed) to fo= cus on that key message. [Qin]: Agree, I propose to remove the figure 1 and= squeeze the section 3.1 as follows: " 3.1. Overview The RTP monitoring arc= hitecture comprises the following two key functional components shown below: o RTP Monitor o RTP Metric Block Structure RTP Monitor is the= functional component defined in the Real-time Transport Protocol [RFC3550]= . It acts as a source of information gathered for monitoring purposes and e= xchanges information with the other RTP monitors using RTCP Metric Blocks. = According to the definition of monitor in the RTP Protocol [RFC3550], the e= nd system that runs an application program that sends or receives RTP data = packets, an intermediate- system that forwards RTP packets to End-devices o= r a third party that observes the RTP and RTCP traffic but does not make it= self visible to the RTP Session participants (i.e., the third party monitor= depicted in figure 1) can act as the
>> RTP monitor. The third pa= rty monitor should be placed on the RTP/RTCP paths between the sender, inte= rmediate and the receiver. The RTP monitor also exposes real time Applicati= on QoS/QoE metric information in the appropriate report block format (e.g.,RTCP XR or othe non-RTP means) to the management system. Such inform= ation can be formulated as different metric types, e.g.,application level m= etric, transport level metric, end system metric, interval metric, cumulati= ve metric, sampled metric, direct metric, composed metric,etc. Both the RTC= P or RTCP XR can be extended to convey these metrics. The details on transp= ort protocols for these metric are described in Section 3.2. RTP may be use= d to multicast groups, both Any Source Multicast (ASM) and Source Specific = Multicast (SSM). These groups can be monitored using RTCP. In the ASM case,= the monitor is a member of the multicast group and listens to RTCP XR repo= rts from all members of the ASM
>> group. In the SSM case, there i= s a unicast feedback target that receives RTCP feedback from receivers and = distributes it to other members of the SSM group (see figure 1 of RFC5760).= The monitor will need to be co-located with the feedback target to receive all feedback from the receivers (this may also be an intermediate = system). In both ASM and SSM scenarios, receivers can send RTCP XR reports = to enhance the reception quality reporting. " > In the definition of Com= posed metrics, the sentence "An example is a
>>> metric calcul= ated based on derived metrics that have been measured."
>>> ma= kes little sense. [Qin] The derived metrics in the sentence should been cor= rected as "direct metric". >Did you mean something like "An example is a= metric
>>> derived by algorithmically combining measured metr= ics."? [Qin]:I agree with your suggested text and like to adopt your sugges= tion. > The definitions of Interval, Cumulative, and Sampled metrics are= not clear. [Qin]: I agree the definition for these three metrics need to b= e more cleaer, I proposes to do the following changes: NEW Text: " Interval= metrics Metrics of which the reported values are measured in the most recent measurement interval duration between successive metrics repor= ts. Such measurement interval is equal to one RTCP report interval (RFC3550= ,Section 6.2). Cumulative metrics Metrics of which the reported values appl= y to the accumulation period characteristic of cumulative measurements. The= reported values are measured during the accumulation period. The accumulat= ion period spans over more than one RTCP report intervals. Sampled metrics = Metrics of which the reported values only apply to the value of a continuou= sly measured or
>> calculated metric that has been sampled at any = given instance of the RTCP report interval. One example of such metric is t= he inter-arrival jitter described in the section 6.4.1 of RFC3550. " > I= f the discussion at the end of section 3.1 is kept, the reference to
&g= t;>> RFC5760 should be a real reference, and RFC5760 should appear in= the
>>> reference section. [Qin]: Okay. > The point of section 3.2 is not obvious. How does it contribute to the
>>&= gt; description of the architecture. It mixes talking about what report >>> blocks are with occasionally needing to send them more freque= ntly. Those
>>> points could be made separately and more simpl= y. [Qin]: Okay. I like to incorporate the key points in the section 3.2 int= o section 3.1 > Section 3.3 is not clear - it starts off saying that the= location of the
>>> sender and receiver may change what metri= cs are meaningful. It's not
>>> clear what you mean by locatio= n. You certainly don't mean geospatial
>>> coordinates. Do you= mean anything other than whether the element is
>>> trusted o= r untrusted by the operations network? If so, say that. The
>>>= ; rest of the paragraph only speaks to what element collects the metrics. [= Qin] Section 3.3 is only used to describe where or from which RTP entity to gather the metrics (i.e., measurement point) in the physical net= work and is not focus of this document. Secondly, I think the definition of= application level metrics has already clarified that application level met= rics is normally gathered from user endpoint. > It's not clear that the = set of meaningful metrics is changed at all -
>>> just where y= ou collect them. If the set of meaningful metrics does in
>>> = fact change, there needs to be additional discussion here. [Qin]: The metri= cs actually doesn't change.Since the definition of application level metric= s Have already conveyed the meaning of what section 3.3 wants to describe, = I propose to remove this section. > Section 4's first paragraph: Is "pro= bably" the best the working group
>>> can say? [Qin]:No, will = remove this word. > The last two sentences of the second bullet in secti= on 4 do not parse.
>>> Please simplify them. [Qin]: Okay, how about change them as follows: NEW Text: " With these minimal num= ber of RTCP statistics parameters mapped to non-RTCP measurements, it is ha= rd to provide accurate measures of real time application quality,conduct de= tailed data analysis and creates alerts timly to the users. Therefore corre= lation between RTCP XR and non-RTP data should be provided. " > The firs= t full sentence of the third bullet in section 4 does not make
>>= > sense. The whole bullet could be clarified. [Qin]: Agree and will remo= ve the first sentence. > The fourth bullet in section 4 and section 5.5 = should call out that
>>> RFC3611 already set Block Type 255 as= ide for future extensions,
>>> anticipating the potential need= to extend the block type space. [Qin]: Okay, How about revising the sectio= n 4,bullet 4 as follows: " Consumption of XR block code points. The RTCP XR= block namespace is limited by the 8-bit block type field in the RTCP XR header. Space exhaustion may be a concern in the future. Anticipat= ing the potential need to extend the block type space, it is noted in [RFC3= 611] that Block Type 255 is reserved for future extensions, " > In secti= on 5, consider naming the subsections with the actual guideline
>>= ;> instead of the problem the guideline is trying to address.
>>= ;> 5.1. Metric blocks should contain a single metric [Qin]: I suggest to= change it as "Contain the single metrics in the metric block" > 5.2. In= clude the payload type and format parameters in the metric block [Qin]: Oka= y. > 5.3. Use RTCP SDES to correlate XR reports with non-RTP data [Qin]:= Okay. > 5.4. Don't repeat measurement information across metric blocks<= br>>>>
>> [Qin]: It is not possible completely to avoid = measurement information repeatition. e.g., for packet loss robustness if th= e report blocks for the same interval span over more than one RTCP packet then each must have the same measurement identity information So I = suggest to change it as: "reduce measurement information across metric bloc= ks" > This points out a structural problem with the section. Why is 5.5 = here?
>>> It's not a guideline. [Qin]: Agree and also as discu= ssed,Space exhaustion is not big issue. How about remove this section? >= (*) And it raises a question about what the document is trying to
>= >> achieve with section 5.4. That section claims the document is prop= osing
>>> a new XR block type to help avoid duplication, but i= t doesn't actually
>>> define the new block type. Is the guide= line saying simply don't repeat
>>> measurements or its the gu= ideline saying "use this new XR block type we
>>> haven't defi= ned yet"? [Qin]: Just to clarify, we have already defined one new XR Block = type to help avoid or reduce duplication. It is measurement information block. The relevant draft is available at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-meas-identity-= 06 >The section needs more clarity. If it really is
>>>= trying to define a new type, there's more work to be done. [Qin]: In order= to avoid such confusion, I proposed to do the following change to the sect= ion 5.4: OLD Text: " This memo proposes to define a new XR Block that will = be used to convey the common time period and the number of packets sent dur= ing this period. " New text: " This memo proposes to define a new XR Block = (i.e., the Measurement information block[I.D-ietf-xrblock-rtcp-xr-meas-iden= tity]) that will be used to convey the common time period and the number of= packets sent during this period. " > The Security Considerations sectio= n, particularly the third paragraph,
>>> needs to be clearer. What exactly do you mean by "monitoring should be
>>>= ; prohibited", and how is the fact that third party monitors don't send >>> RTCP relevant? Did you intend those to be separate points? [Q= in]: Yes, they are on the different port. Such monitor may receive RTP pack= et but does not send RTCP packet. > Editorial Nits and Suggestions:
&= gt;>>
>>> The first paragraph of the introduction is ove= rly complex, and won't age
>>> well. I suggest replacing it wi= th: "Multimedia services using the
>>> Real-Time Protocol (RTP= ) are seeing increased use. Standard methods for
>>> gathering= RTP performance metrics from these applications are needed to
>>= > manage uncertainties in the behavior and availability of their
>= ;>> services." Then replace "These rapidly emerging standards," with =
>>> "Standards". [Qin]: Okay. > Introduction paragraph 3 sentence 2 should start "The RTCP Guidelines
>>> = [RFC5968]". It would be even better to use the full title from 5968:
&g= t;>> 'The "Guidelines for Extending the RTP Control Protocol (RTCP)" = [RFC5968]' [Qin]: Okay. > This may become moot as section 3 is modified = to make its main point
>>> more obvious, but RFC3550 does not = characterize Monitors as "a source of
>>> information". That c= ould be misunderstood. Please choose another word.
>>> Perhaps= "repository"? [Qin]: Okay, repository looks good to me. > In bullet lis= ts, starting an entry with "or" or "and" is unnecessary. It
>>>= ; should be clear from the introduction to the list whether the individual =
>>> entries should be combined or selected from. [Qin]: Okay. = > In section 3.1 where you say "RTP may be used to multicast groups" did=
>>> you mean "RTP may be sent to multicast groups" or "RTP may be used with
>>> multicast groups"? [Qin]: I think i= t should be the latter case,i.e.," RTP may be used with
>> multic= ast groups". >
>>> In section 3.2 "The following are four u= se cases but are not limited
>>> to:" does not parse. The bull= ets aren't really use cases as much as they
>>> are mechanisms= . Would it make more sense to say "Here are four
>>> mechanism= s that have been created to address the need for more frequent
>>= > reporting. This list is not intended to be exhaustive." The third bull= et
>>> in that list should say "RTCP and RTCP XR are" instead = of "RTCP or RTCP
>>> XR is". [Qin]: Okay, but I have incorpora= ted the keypoints of section 3.2 into section 3.1. > The bullets in sect= ion 4 would be better as subsections with titles
>>> (taken fr= om the first phrase of the bullet). [Qin]: Okay. > I suggest this alternative for the first full sentence in the first
>>> bull= et of section 4 : "A compound metrics block is designed to contain a
&g= t;>> large number of parameters from different classes for a specific=
>>> application in a single block." [Qin]: Okay. > Section= 5's title should be "Guidelines for reporting" instead of
>>>= "Guideline for reporting" [Qin]: Okay. > In section 5.1 I suggest "just= ify the overhead," instead of "justify the
>>> overheads," [Qi= n]: Okay. > Section 7 - the last sentence of the first paragraph does no= t parse. The
>>> second paragraph (which is a single sentence)= should be clarified - an
>>> MCU is not a topology. [Qin]: Ok= ay. How about revising them as follows: OLD Text: " The topologies in this = category are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topo= logies based on systems do not behave according to the RTP protocol [RFC3550]. Considering the MCU and translator are two typical topologies i= n the two categories mentioned above, this document will take them as two t= ypical examples to explain how RTCP XR report works in different RFC5117 to= pologies. " NEW Text: " The topologies in this category are Topo-Video-Swit= ch-MCU and Topo-RTCP-terminating-MCU. Such topologies based on systems (e.g= .,MCU) do not behave according to the RTP protocol [RFC3550]. Considering t= he MCU and translator are two typical intermediary systems in the two categ= ories mentioned above, this document will take them as two typical examples= to explain how RTCP XR report works in different RFC5117 topologies. " >= ; The last two sentences of the first
>> paragraph of the security=
>>> considerations section add nothing to the document. I sug= gest deleting them. [Qin]: Okay. > _____________________________________= __________
>>> Audio/Video Transport Core Maintenance
>>> avt at ietf.org
>>> https://www.ietf.= org/mailman/listinfo/avt >
>> _____________________________= ___
>>
>> * References:
>> * [AVTCORE] Subject= : AD review of draft-ietf-avtcore-monarch-13
>> * From: Robert Sp= arks
>> * Prev by Date: [AVTCORE] Protocol Action: 'Explicit Conge= stion Notification (ECN) for RTP over
>> UDP' to Proposed Standar= d (draft-ietf-avtcore-ecn-for-rtp-08.txt)
>> * Previous by thread= : [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13
>>= ; * Next by thread: [AVTCORE] Protocol Action: 'Explicit Congestion Notific= ation (ECN) for RTP over
>> UDP' to Proposed Standard (draft-ietf= -avtcore-ecn-for-rtp-08.txt)
>> * Index(es):
>> * Date<= br>>> * Thread
>> _______________________________________________
>> Audio/Video Tr= ansport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/ma= ilman/listinfo/avt
>
>
>
> --
> Colin= Perkins
> http:/= /csperkins.org/
>
>



--
Colin Perkinshttp://csperkins.org/=





---126313295-1805897683-1337821970=:83936-- From csp@csperkins.org Thu May 24 09:39:24 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806721F867A; Thu, 24 May 2012 09:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, 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 PrG9-1ncZ70C; Thu, 24 May 2012 09:39:21 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7921F8675; Thu, 24 May 2012 09:39:20 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SXb4J-0007Ba-YK; Thu, 24 May 2012 16:39:19 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A102C3F-ABC2-4132-A004-506D7096699F" From: Colin Perkins In-Reply-To: <1337821970.83936.YahooMailNeo@web171005.mail.ukl.yahoo.com> Date: Thu, 24 May 2012 17:39:18 +0100 Message-Id: <1007B220-18A0-49E1-B293-FDA4B82E3698@csperkins.org> References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com> <8550925CD2F24829AC4483B12606F03A@china.huawei.com> <565CA625413A4126AF25B21F2EC5F71F@china.huawei.com> <1337821970.83936.YahooMailNeo@web171005.mail.ukl.yahoo.com> To: Albrecht Schwarz X-Mailer: Apple Mail (2.1278) Cc: "xrblock@ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 16:39:24 -0000 --Apple-Mail=_4A102C3F-ABC2-4132-A004-506D7096699F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Albrecht, Agreed - that seems like a useful distinction. Colin On 24 May 2012, at 02:12, Albrecht Schwarz wrote: > I would support that direction and structuring proposal. >=20 > Side comment to the notion of "end system metric": > We should be carefully because it could be interpretated in two = directions: > a) metric related to RTP topology "RTP end system" > b) metric related to user equipment >=20 > There's a subtle difference between both, the "RTP end system" = FUNCTION could be located in multiple different physical entities like = user equipment, but also RTP-to-X gateway equipment. The later ones are = not located at the end of the overall communication path. > Conclusion for this example: e.g. QoE metrics (as application level = metrics) might be monitored in an "RTP end system" when located in user = equipment, but not if "RTP end system" would be located in network level = equipment. Consequently, the association of QoE metrics as "end system = metrics" would be ambiguous. >=20 > My feeling: > we don't need necessarily the concept of an "end system metric", but = we need a location concept for RTP monitors with respect to the topology = of the end-to-end communication path ("which again might be completely = e2e RTP based or some segments might be non-RTP ..."). >=20 > -Albrecht >=20 >=20 > Von: Colin Perkins > An: Qin Wu =20 > CC: Albrecht Schwarz ; avt@ietf.org; = xrblock@ietf.org=20 > Gesendet: 23:21 Mittwoch, 23.Mai 2012 > Betreff: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 >=20 > Qin, >=20 > The text you propose is better, but I'm still not sure it's clear. I = wonder if it may be worth splitting that section into several = paragraphs, and giving a little more description. One paragraph could = discuss the possible locations for monitors: in end-systems, in = middleboxes that are an active part of an RTP session (e.g., RTP mixers = or translators), or in third-party devices that passively monitor an RTP = session. For each of these locations, you could then include a paragraph = that briefly explains the uses for monitors in that location, and the = types of metrics they're suited to monitoring, perhaps with examples.=20 >=20 > Colin >=20 >=20 >=20 >=20 > On 23 May 2012, at 04:22, Qin Wu wrote: > > Hi, > > Take Robert,Colin and Albrechet's comments into account, I propose = to rewrite section 3.3 with the following changes: > > OLD TEXT: > > " > > 3.3. RTP Sender/Receiver entities located in network nodes > >=20 > > The location of the RTP Sender/Receiver entities may impact a set = of > > meaningful metrics. For instance, application level metrics for = QoE > > related performance parameters are under most conditions measured = at > > the user device that receives RTP data packets. However in some > > cases, given the factors ( "measurement point location", = "measurement > > model location", "awareness of content information", etc [P.NAMS]) > > taken into account, such metrics may be measured in a network node > > instead of a user device. > >=20 > > " > > NEW TEXT: > > " > > 3.3. Measurement point of the RTP monitor within the network. > >=20 > > The RTP monitors are spread across a single domain(e.g., network = domain) or=20 > > multiple domains (e.g., between network domain and service domain)in = the network. > > The performance Metrics reported from the RTP monitor can be divided = into end system=20 > > metrics, application level metrics, transport level metrics. Some of = these metrics=20 > > may be specific to the measurement point of the RTP monitor or = depend on where=20 > > the RTP monitors are located in the network. For instance, end = system metrics are only > > available or measured at the RTP end system or terminal device. = Application level > > metrics that reflect end to end user experience at the = application-level are measured=20 > > more precise or less complicated at the RTP end system than measured = from intermediary=20 > > system (e.g., the RTP media translator) in the nework. For transport = level metrics, takes > > one way delay as an example, in the asymmetric network, the one way = delay measured=20 > > at the RTP sender entity is different from one way delay measured at = the RTP=20 > > receiver entity.=20 > > " > >=20 > > Regards! > > -Qin > > ----- Original Message -----=20 > > From: "Colin Perkins" > > To: "Qin Wu" > > Cc: "Albrecht Schwarz" ; > > Sent: Tuesday, May 22, 2012 7:04 PM > > Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 > >=20 > >=20 > > I also don't agree with deleting Section 3.3 from the monarch draft.=20= > >=20 > > The architecture needs to be clear that there are valid scenarios = for RTP monitoring within a network, either in some middlebox that = comprises part of an RTP session, or in a third-party monitoring device = used for network management purposes. Section 3.3 is a reasonable place = to discuss these, and to explain why the metrics that can be reported = from middleboxes are different to those that can be captured at end = systems. > >=20 > > Colin > >=20 > >=20 > >=20 > > On 22 May 2012, at 07:53, Qin Wu wrote: > >> Hi,: > >> ----- Original Message -----=20 > >> From: "Albrecht Schwarz" > >> To: > >> Cc: ; > >> Sent: Tuesday, May 22, 2012 11:18 AM > >> Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 > >>=20 > >>=20 > >> Dear All, > >>=20 > >> concerning the resolution proposal for clause 3.3: > >> I don't agree in just deleting again that section! > >> There was quite a long debate for incorporating such a clause. > >> The original text proposal was much more detailed. Perhaps the = shortening to just a single paragraph is the main cause for unclarity. > >> Thus, instead of removing previous agreed text, we just rather = extend it again. > >>=20 > >>=20 > >> [Qin]:=20 > >> The reason I propose to remove the section 3.3 is=20 > >> a. I think Robert is correct. The set of meaningful metrics isn't = changed at all wherever you collect them. It seems little sense=20 > >> to say "the location of the RTP Sender/Receiver entities may = impact a set of meaningful metrics. "=20 > >> b. Where to gather or measure metrics can be indicated by the = definition of Transport metrics, End system metrics and application = level metrics. > >> c. Section 3.3 seems to discuss where to gather what metrics. = Recommendation ITU-T G.1081 have already defined five monitoring points=20= > >> where the performance measurements can be made. > >>=20 > >>> I think the definition of application level metrics has already = clarified that application level metrics is normally gathered from user = endpoint.=20 > >>=20 > >> No. We did discuss this already extensively. > >> An RTP media translator could provide application level metrics = because e.g. terminating the application protocol layer. > >> Such an RTP topology is NOT located in an user endpoint! > >>=20 > >> [Qin]: Sorry, I should correct me to say QoE metric is ususally = measured at the user endpoint. > >>=20 > >> Regards, > >> Albrecht > >> ________________________________ > >> [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread = Index]=20 > >> Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 > >> ________________________________ > >>=20 > >> * To: Robert Sparks , IETF AVTCore WG , > >> * Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 > >> * From: Qin Wu > >> * Date: Fri, 18 May 2012 18:37:56 +0800 > >> * Delivered-to: avt at ietfa.amsl.com > >> * List-archive: > >> * List-help: > >> * List-id: Audio/Video Transport Core Maintenance > >> * List-post: > >> * List-subscribe: , = > >> * List-unsubscribe: , = > >> * References: <4FB2E323.3090406 at nostrum.com> > >> ________________________________ > >>=20 > >> Hi,Robert: > >> Thank for your valuable review. please see my replies inline = belows. Regards! > >> -Qin > >> ----- Original Message -----=20 > >> From: "Robert Sparks" > >> To: "IETF AVTCore WG" ; = > >> Sent: Wednesday, May 16, 2012 7:13 AM > >> Subject: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13 > Summary: There are issues to resolve = with a revised ID before=20 > >>> progressing to IETF LC. > >>>=20 > >>> It's a struggle to see the _architecture_ this document is = supposed to=20 > >>> describe. I suspect most of the working group energy went into = Section 5=20 > >>> (the guidelines for writing XR block definitions) - the rest of = the=20 > >>> document needs a similar level of attention to detail. > >>>=20 > >>> There are two major issues that I've tagged with a (*). I followed = a=20 > >>> mostly document-order flow instead of grouping the major issues at = the top. > >>>=20 > >>> (*) Given the document's title, it should be very easy to answer = "What=20 > >>> is the monitoring architecture?" for people who are reading this = draft=20 > >>> for the first time. > >>> The key message is that the monitoring architecture consists of = Monitors=20 > >>> that exchange information using RTCP Metric Blocks. [Qin]: Agree. = >The text should say=20 > >>> that. [Qin]: Okay. > There is a lot of prose in section 3 and = visual detail in the=20 > >>> diagram in Figure 1 that makes that extremely difficult to see.=20 > >>> Simplifying the figure by removing the details about applications = and=20 > >>> transports, or at least moving them to a second figure, making the=20= > >>> Monitor boxes stand out, and making the types of information flows = (the=20 > >>> arrows) visually distinctive would help. Simplify the prose (much = of it=20 > >>> could be removed) to focus on that key message. [Qin]: Agree, I = propose to remove the figure 1 and squeeze the section 3.1 as follows: " = 3.1. Overview The RTP monitoring architecture comprises the following = two key functional components shown below: o RTP Monitor o RTP Metric = Block Structure RTP Monitor is the functional component defined in the = Real-time Transport Protocol [RFC3550]. It acts as a source of = information gathered for monitoring purposes and exchanges information = with the other RTP monitors using RTCP Metric Blocks. According to the = definition of monitor in the RTP Protocol [RFC3550], the end system that = runs an application program that sends or receives RTP data packets, an = intermediate- system that forwards RTP packets to End-devices or a third = party that observes the RTP and RTCP traffic but does not make itself = visible to the RTP Session participants (i.e., the third party monitor = depicted in figure 1) can act as the > >> RTP monitor. The third party monitor should be placed on the = RTP/RTCP paths between the sender, intermediate and the receiver. The = RTP monitor also exposes real time Application QoS/QoE metric = information in the appropriate report block format (e.g.,RTCP XR or othe = non-RTP means) to the management system. Such information can be = formulated as different metric types, e.g.,application level metric, = transport level metric, end system metric, interval metric, cumulative = metric, sampled metric, direct metric, composed metric,etc. Both the = RTCP or RTCP XR can be extended to convey these metrics. The details on = transport protocols for these metric are described in Section 3.2. RTP = may be used to multicast groups, both Any Source Multicast (ASM) and = Source Specific Multicast (SSM). These groups can be monitored using = RTCP. In the ASM case, the monitor is a member of the multicast group = and listens to RTCP XR reports from all members of the ASM > >> group. In the SSM case, there is a unicast feedback target that = receives RTCP feedback from receivers and distributes it to other = members of the SSM group (see figure 1 of RFC5760). The monitor will = need to be co-located with the feedback target to receive all feedback = from the receivers (this may also be an intermediate system). In both = ASM and SSM scenarios, receivers can send RTCP XR reports to enhance the = reception quality reporting. " > In the definition of Composed metrics, = the sentence "An example is a=20 > >>> metric calculated based on derived metrics that have been = measured."=20 > >>> makes little sense. [Qin] The derived metrics in the sentence = should been corrected as "direct metric". >Did you mean something like = "An example is a metric=20 > >>> derived by algorithmically combining measured metrics."? [Qin]:I = agree with your suggested text and like to adopt your suggestion. > The = definitions of Interval, Cumulative, and Sampled metrics are not clear. = [Qin]: I agree the definition for these three metrics need to be more = cleaer, I proposes to do the following changes: NEW Text: " Interval = metrics Metrics of which the reported values are measured in the most = recent measurement interval duration between successive metrics reports. = Such measurement interval is equal to one RTCP report interval = (RFC3550,Section 6.2). Cumulative metrics Metrics of which the reported = values apply to the accumulation period characteristic of cumulative = measurements. The reported values are measured during the accumulation = period. The accumulation period spans over more than one RTCP report = intervals. Sampled metrics Metrics of which the reported values only = apply to the value of a continuously measured or > >> calculated metric that has been sampled at any given instance of = the RTCP report interval. One example of such metric is the = inter-arrival jitter described in the section 6.4.1 of RFC3550. " > If = the discussion at the end of section 3.1 is kept, the reference to=20 > >>> RFC5760 should be a real reference, and RFC5760 should appear in = the=20 > >>> reference section. [Qin]: Okay. > The point of section 3.2 is not = obvious. How does it contribute to the=20 > >>> description of the architecture. It mixes talking about what = report=20 > >>> blocks are with occasionally needing to send them more frequently. = Those=20 > >>> points could be made separately and more simply. [Qin]: Okay. I = like to incorporate the key points in the section 3.2 into section 3.1 > = Section 3.3 is not clear - it starts off saying that the location of the=20= > >>> sender and receiver may change what metrics are meaningful. It's = not=20 > >>> clear what you mean by location. You certainly don't mean = geospatial=20 > >>> coordinates. Do you mean anything other than whether the element = is=20 > >>> trusted or untrusted by the operations network? If so, say that. = The=20 > >>> rest of the paragraph only speaks to what element collects the = metrics. [Qin] Section 3.3 is only used to describe where or from which = RTP entity to gather the metrics (i.e., measurement point) in the = physical network and is not focus of this document. Secondly, I think = the definition of application level metrics has already clarified that = application level metrics is normally gathered from user endpoint. > = It's not clear that the set of meaningful metrics is changed at all -=20 > >>> just where you collect them. If the set of meaningful metrics does = in=20 > >>> fact change, there needs to be additional discussion here. [Qin]: = The metrics actually doesn't change.Since the definition of application = level metrics Have already conveyed the meaning of what section 3.3 = wants to describe, I propose to remove this section. > Section 4's first = paragraph: Is "probably" the best the working group=20 > >>> can say? [Qin]:No, will remove this word. > The last two sentences = of the second bullet in section 4 do not parse.=20 > >>> Please simplify them. [Qin]: Okay, how about change them as = follows: NEW Text: " With these minimal number of RTCP statistics = parameters mapped to non-RTCP measurements, it is hard to provide = accurate measures of real time application quality,conduct detailed data = analysis and creates alerts timly to the users. Therefore correlation = between RTCP XR and non-RTP data should be provided. " > The first full = sentence of the third bullet in section 4 does not make=20 > >>> sense. The whole bullet could be clarified. [Qin]: Agree and will = remove the first sentence. > The fourth bullet in section 4 and section = 5.5 should call out that=20 > >>> RFC3611 already set Block Type 255 aside for future extensions,=20 > >>> anticipating the potential need to extend the block type space. = [Qin]: Okay, How about revising the section 4,bullet 4 as follows: " = Consumption of XR block code points. The RTCP XR block namespace is = limited by the 8-bit block type field in the RTCP XR header. Space = exhaustion may be a concern in the future. Anticipating the potential = need to extend the block type space, it is noted in [RFC3611] that Block = Type 255 is reserved for future extensions, " > In section 5, consider = naming the subsections with the actual guideline=20 > >>> instead of the problem the guideline is trying to address. > >>> 5.1. Metric blocks should contain a single metric [Qin]: I suggest = to change it as "Contain the single metrics in the metric block" > 5.2. = Include the payload type and format parameters in the metric block = [Qin]: Okay. > 5.3. Use RTCP SDES to correlate XR reports with non-RTP = data [Qin]: Okay. > 5.4. Don't repeat measurement information across = metric blocks > >>>=20 > >> [Qin]: It is not possible completely to avoid measurement = information repeatition. e.g., for packet loss robustness if the report = blocks for the same interval span over more than one RTCP packet then = each must have the same measurement identity information So I suggest to = change it as: "reduce measurement information across metric blocks" > = This points out a structural problem with the section. Why is 5.5 here?=20= > >>> It's not a guideline. [Qin]: Agree and also as discussed,Space = exhaustion is not big issue. How about remove this section? > (*) And it = raises a question about what the document is trying to=20 > >>> achieve with section 5.4. That section claims the document is = proposing=20 > >>> a new XR block type to help avoid duplication, but it doesn't = actually=20 > >>> define the new block type. Is the guideline saying simply don't = repeat=20 > >>> measurements or its the guideline saying "use this new XR block = type we=20 > >>> haven't defined yet"? [Qin]: Just to clarify, we have already = defined one new XR Block type to help avoid or reduce duplication. It is = measurement information block. The relevant draft is available at: = http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-meas-identity-06 = >The section needs more clarity. If it really is=20 > >>> trying to define a new type, there's more work to be done. [Qin]: = In order to avoid such confusion, I proposed to do the following change = to the section 5.4: OLD Text: " This memo proposes to define a new XR = Block that will be used to convey the common time period and the number = of packets sent during this period. " New text: " This memo proposes to = define a new XR Block (i.e., the Measurement information = block[I.D-ietf-xrblock-rtcp-xr-meas-identity]) that will be used to = convey the common time period and the number of packets sent during this = period. " > The Security Considerations section, particularly the third = paragraph,=20 > >>> needs to be clearer. What exactly do you mean by "monitoring = should be=20 > >>> prohibited", and how is the fact that third party monitors don't = send=20 > >>> RTCP relevant? Did you intend those to be separate points? [Qin]: = Yes, they are on the different port. Such monitor may receive RTP packet = but does not send RTCP packet. > Editorial Nits and Suggestions: > >>>=20 > >>> The first paragraph of the introduction is overly complex, and = won't age=20 > >>> well. I suggest replacing it with: "Multimedia services using the=20= > >>> Real-Time Protocol (RTP) are seeing increased use. Standard = methods for=20 > >>> gathering RTP performance metrics from these applications are = needed to=20 > >>> manage uncertainties in the behavior and availability of their=20 > >>> services." Then replace "These rapidly emerging standards," with=20= > >>> "Standards". [Qin]: Okay. > Introduction paragraph 3 sentence 2 = should start "The RTCP Guidelines=20 > >>> [RFC5968]". It would be even better to use the full title from = 5968:=20 > >>> 'The "Guidelines for Extending the RTP Control Protocol (RTCP)" = [RFC5968]' [Qin]: Okay. > This may become moot as section 3 is modified = to make its main point=20 > >>> more obvious, but RFC3550 does not characterize Monitors as "a = source of=20 > >>> information". That could be misunderstood. Please choose another = word.=20 > >>> Perhaps "repository"? [Qin]: Okay, repository looks good to me. > = In bullet lists, starting an entry with "or" or "and" is unnecessary. It=20= > >>> should be clear from the introduction to the list whether the = individual=20 > >>> entries should be combined or selected from. [Qin]: Okay. > In = section 3.1 where you say "RTP may be used to multicast groups" did=20 > >>> you mean "RTP may be sent to multicast groups" or "RTP may be used = with=20 > >>> multicast groups"? [Qin]: I think it should be the latter = case,i.e.," RTP may be used with=20 > >> multicast groups". >=20 > >>> In section 3.2 "The following are four use cases but are not = limited=20 > >>> to:" does not parse. The bullets aren't really use cases as much = as they=20 > >>> are mechanisms. Would it make more sense to say "Here are four=20 > >>> mechanisms that have been created to address the need for more = frequent=20 > >>> reporting. This list is not intended to be exhaustive." The third = bullet=20 > >>> in that list should say "RTCP and RTCP XR are" instead of "RTCP or = RTCP=20 > >>> XR is". [Qin]: Okay, but I have incorporated the keypoints of = section 3.2 into section 3.1. > The bullets in section 4 would be better = as subsections with titles=20 > >>> (taken from the first phrase of the bullet). [Qin]: Okay. > I = suggest this alternative for the first full sentence in the first=20 > >>> bullet of section 4 : "A compound metrics block is designed to = contain a=20 > >>> large number of parameters from different classes for a specific=20= > >>> application in a single block." [Qin]: Okay. > Section 5's title = should be "Guidelines for reporting" instead of=20 > >>> "Guideline for reporting" [Qin]: Okay. > In section 5.1 I suggest = "justify the overhead," instead of "justify the=20 > >>> overheads," [Qin]: Okay. > Section 7 - the last sentence of the = first paragraph does not parse. The=20 > >>> second paragraph (which is a single sentence) should be clarified = - an=20 > >>> MCU is not a topology. [Qin]: Okay. How about revising them as = follows: OLD Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems do not behave according to the RTP protocol [RFC3550]. = Considering the MCU and translator are two typical topologies in the two = categories mentioned above, this document will take them as two typical = examples to explain how RTCP XR report works in different RFC5117 = topologies. " NEW Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems (e.g.,MCU) do not behave according to the RTP protocol = [RFC3550]. Considering the MCU and translator are two typical = intermediary systems in the two categories mentioned above, this = document will take them as two typical examples to explain how RTCP XR = report works in different RFC5117 topologies. " > The last two sentences = of the first > >> paragraph of the security=20 > >>> considerations section add nothing to the document. I suggest = deleting them. [Qin]: Okay. > = _______________________________________________ > >>> Audio/Video Transport Core Maintenance > >>> avt at ietf.org > >>> https://www.ietf.org/mailman/listinfo/avt > > >> ________________________________ > >>=20 > >> * References:=20 > >> * [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13=20 > >> * From: Robert Sparks > >> * Prev by Date: [AVTCORE] Protocol Action: 'Explicit Congestion = Notification (ECN) for RTP over=20 > >> UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)=20= > >> * Previous by thread: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13=20 > >> * Next by thread: [AVTCORE] Protocol Action: 'Explicit Congestion = Notification (ECN) for RTP over=20 > >> UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)=20= > >> * Index(es):=20 > >> * Date > >> * Thread > >> _______________________________________________ > >> Audio/Video Transport Core Maintenance > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > >=20 > >=20 > >=20 > > --=20 > > Colin Perkins > > http://csperkins.org/ > >=20 > >=20 >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 >=20 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_4A102C3F-ABC2-4132-A004-506D7096699F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I = would support that direction and structuring = proposal.

Side = comment to the notion of "end system metric":
We should = be carefully because it could be interpretated in two = directions:
a) metric related to RTP topology "RTP end = system"
b) metric related to user = equipment

There's a subtle difference between = both, the "RTP end system" FUNCTION could be located in multiple = different physical entities like user equipment, but also RTP-to-X = gateway equipment. The later ones are not located at the end of the = overall communication path.
Conclusion for this example: e.g. = QoE metrics (as application level metrics) might be monitored in an "RTP = end system" when located in user equipment, but not if "RTP end system" would be located in network level equipment. = Consequently, the association of QoE metrics as "end system metrics" = would be ambiguous.

My feeling:
we = don't need necessarily the concept of an "end system metric", but we = need a location concept for RTP monitors with respect to the topology of = the end-to-end communication path ("which again might be completely e2e = RTP based or some segments might be non-RTP = ...").

-Albrecht


Von: Colin Perkins <csp@csperkins.org>
An: Qin Wu <bill.wu@huawei.com> =
CC: Albrecht = Schwarz <albrechtschwarz@yahoo.de>;= avt@ietf.org; xrblock@ietf.org
Gesendet: 23:21 Mittwoch, 23.Mai = 2012
Betreff: Re: = [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13
=

Qin,

The text you propose is better, but I'm = still not sure it's clear. I wonder if it may be worth splitting that = section into several paragraphs, and giving a little more description. = One paragraph could discuss the possible locations for monitors: in = end-systems, in middleboxes that are an active part of an RTP session = (e.g., RTP mixers or translators), or in third-party devices that = passively monitor an RTP session. For each of these locations, you could then include a = paragraph that briefly explains the uses for monitors in that location, = and the types of metrics they're suited to monitoring, perhaps with = examples.

Colin




On 23 May 2012, at 04:22, Qin = Wu wrote:
> Hi,
> Take Robert,Colin and Albrechet's comments = into account, I propose to rewrite section 3.3 with the following = changes:
> OLD TEXT:
> "
> 3.3.  RTP = Sender/Receiver entities located in network nodes
>
>  = The location of the RTP Sender/Receiver entities may impact a set = of
>  meaningful metrics.  For instance, application = level metrics for QoE
>  related performance parameters are = under most conditions measured at
>  the user device that = receives RTP data packets.  However in some
>  cases, = given the factors ( "measurement point location", "measurement
>  model location", "awareness of content = information", etc [P.NAMS])
>  taken into account, such = metrics may be measured in a network node
>  instead of a = user device.
>
> "
> NEW TEXT:
> "
> 3.3. = Measurement point of the RTP monitor within the network.
> =
> The RTP monitors are spread across a single domain(e.g., = network  domain) or
> multiple domains (e.g., between = network domain and service domain)in the network.
> The = performance Metrics reported from the RTP monitor can be divided into = end system
> metrics, application level metrics, transport level = metrics. Some of these metrics
> may be specific to the = measurement point of the RTP monitor or depend on where
> the RTP = monitors are located in the network. For instance, end system metrics = are only
> available or measured at the RTP end system or terminal = device. Application level
> metrics that reflect end to end user = experience at the application-level are measured
> more precise = or less complicated at the RTP end system than measured from = intermediary
> system (e.g., the RTP media translator) in the = nework. For transport level metrics, takes
> one way delay as an = example, in the asymmetric network, the one way delay measured
> = at the RTP sender entity is different from one way delay measured at the = RTP
> receiver entity.
> "
>
> = Regards!
> -Qin
> ----- Original Message -----
> = From: "Colin Perkins" <csp@csperkins.org>
> To: = "Qin Wu" <bill.wu@huawei.com>
> = Cc: "Albrecht Schwarz" <albrechtschwarz@yahoo.de>;= <avt@ietf.org>
> Sent: Tuesday, = May 22, 2012 7:04 PM
> Subject: Re: [AVTCORE] Subject: AD review = of draft-ietf-avtcore-monarch-13
>
>
> I also don't = agree with deleting Section 3.3 from the monarch draft.
> =
> The architecture needs to be clear that there are valid = scenarios for RTP monitoring within a network, either in some middlebox = that comprises part of an RTP session, or in a third-party monitoring = device used for network management purposes. Section 3.3 is a reasonable = place to discuss these, and to explain why the metrics that can be = reported from middleboxes are different to those that can be captured at = end systems.
>
> Colin
>
>
>
> = On 22 May 2012, at 07:53, Qin Wu wrote:
>> Hi,:
>> = ----- Original Message -----
>> From: "Albrecht Schwarz" <albrechtschwarz@yahoo.de><= br>>> To: <bill.wu@huawei.com>
>> = Cc: <avt@ietf.org>; <rjsparks@nostrum.com>
>&= gt; Sent: Tuesday, May 22, 2012 11:18 AM
>> Subject: Re: = [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13
>>
>>
>> Dear = All,
>>
>> concerning the resolution proposal for = clause 3.3:
>> I don't agree in just deleting again that = section!
>> There was quite a long debate for incorporating = such a clause.
>> The original text proposal was much more = detailed. Perhaps the shortening to just a single paragraph is the main cause for = unclarity.
>> Thus, instead of removing previous agreed text, = we just rather extend it again.
>>
>>
>> = [Qin]:
>> The reason I propose to remove the section 3.3 is =
>> a. I think Robert is correct. The set of meaningful metrics = isn't changed at all  wherever you collect them. It seems little = sense
>>  to say "the location of the RTP = Sender/Receiver entities may impact a set of meaningful metrics. " =
>> b. Where to gather or measure metrics can be indicated by = the definition of Transport metrics, End system metrics and application = level metrics.
>> c. Section 3.3 seems to discuss where to = gather what metrics. Recommendation ITU-T G.1081 have already defined = five monitoring points
>>  where the performance = measurements can be made.
>>
>>> I think the definition of application level metrics has already clarified = that  application level metrics is normally gathered from user = endpoint.
>>
>> No. We did discuss this already = extensively.
>> An RTP media translator could provide = application level metrics because e.g. terminating the application = protocol layer.
>> Such an RTP topology is NOT located in an = user endpoint!
>>
>> [Qin]: Sorry, I should correct = me to say QoE metric is ususally measured at the user = endpoint.
>>
>> Regards,
>> = Albrecht
>> ________________________________
>> [Date = Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] =
>> Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13
>> = ________________________________
>>
>> * To: Robert = Sparks <rjsparks at nostrum.com>,= IETF AVTCore WG <avt at ietf.org>, <draft-ietf-avtcore-monarch at tools.ietf.org>
>> * = Subject: Re: [AVTCORE] Subject: AD review of = draft-ietf-avtcore-monarch-13
>> * From: Qin Wu <bill.wu at = huawei.com>
>> * Date: = Fri, 18 May 2012 18:37:56 +0800
>> * Delivered-to: avt at ietfa.amsl.com
>> * = List-archive: <http://www.ietf.org/mail-archive/web/avt>
>= > * List-help: <mailto:avt-request@ietf.org?subject=3Dhe= lp>
>> * List-id: Audio/Video Transport Core Maintenance = <avt.ietf.org>
>> * = List-post: <mailto:avt@ietf.org>
>> * = List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=3Dsu= bscribe>
>> * List-unsubscribe: <https://www.ietf.org/mailman/options/avt>, = <mailto:avt-request@ietf.org?subject=3Dun= subscribe>
>> * References: <4FB2E323.3090406 at nostrum.com>
>> = ________________________________
>>
>> = Hi,Robert:
>> Thank for your valuable review. please see my = replies inline belows. Regards!
>> -Qin
>> ----- = Original Message -----
>> From: "Robert Sparks" <rjsparks = at nostrum.com>
>> To: = "IETF AVTCore WG" <avt at ietf.org>;= <draft-ietf-avtcore-monarch at tools.ietf.org>
>> Sent: = Wednesday, May 16, 2012 7:13 AM
>> Subject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 > = Summary: There are issues to resolve with a revised ID before =
>>> progressing to IETF LC.
>>> =
>>> It's a struggle to see the _architecture_ this document = is supposed to
>>> describe. I suspect most of the working = group energy went into Section 5
>>> (the guidelines for = writing XR block definitions) - the rest of the
>>> = document needs a similar level of attention to detail.
>>> =
>>> There are two major issues that I've tagged with a (*). = I followed a
>>> mostly document-order flow instead of = grouping the major issues at the top.
>>>
>>> = (*) Given the document's title, it should be very easy to answer "What =
>>> is the monitoring architecture?" for people who are = reading this draft
>>> for the first time.
>>> = The key message is that the monitoring architecture consists of Monitors =
>>> that exchange information using RTCP Metric Blocks. = [Qin]: Agree. >The text should say
>>> that. [Qin]: = Okay. > There is a lot of prose in section 3 and visual detail in the =
>>> diagram in Figure 1 that makes that extremely difficult = to see.
>>> Simplifying the figure by removing the details = about applications and
>>> transports, or at least moving = them to a second figure, making the
>>> Monitor boxes stand = out, and making the types of information flows (the
>>> = arrows) visually distinctive would help. Simplify the prose (much of it =
>>> could be removed) to focus on that key message. [Qin]: = Agree, I propose to remove the figure 1 and squeeze the section 3.1 as = follows: " 3.1. Overview The RTP monitoring architecture comprises the = following two key functional components shown below: o RTP Monitor o RTP Metric Block Structure RTP Monitor is = the functional component defined in the Real-time Transport Protocol = [RFC3550]. It acts as a source of information gathered for monitoring = purposes and exchanges information with the other RTP monitors using = RTCP Metric Blocks. According to the definition of monitor in the RTP = Protocol [RFC3550], the end system that runs an application program that = sends or receives RTP data packets, an intermediate- system that = forwards RTP packets to End-devices or a third party that observes the = RTP and RTCP traffic but does not make itself visible to the RTP Session = participants (i.e., the third party monitor depicted in figure 1) can = act as the
>> RTP monitor. The third party monitor should be = placed on the RTP/RTCP paths between the sender, intermediate and the = receiver. The RTP monitor also exposes real time Application QoS/QoE = metric information in the appropriate report block format (e.g.,RTCP XR or othe non-RTP means) to the management system. Such = information can be formulated as different metric types, = e.g.,application level metric, transport level metric, end system = metric, interval metric, cumulative metric, sampled metric, direct = metric, composed metric,etc. Both the RTCP or RTCP XR can be extended to = convey these metrics. The details on transport protocols for these = metric are described in Section 3.2. RTP may be used to multicast = groups, both Any Source Multicast (ASM) and Source Specific Multicast = (SSM). These groups can be monitored using RTCP. In the ASM case, the = monitor is a member of the multicast group and listens to RTCP XR = reports from all members of the ASM
>> group. In the SSM case, = there is a unicast feedback target that receives RTCP feedback from = receivers and distributes it to other members of the SSM group (see = figure 1 of RFC5760). The monitor will need to be co-located with the = feedback target to receive all feedback from the receivers (this may also be an = intermediate system). In both ASM and SSM scenarios, receivers can send = RTCP XR reports to enhance the reception quality reporting. " > In = the definition of Composed metrics, the sentence "An example is a =
>>> metric calculated based on derived metrics that have = been measured."
>>> makes little sense. [Qin] The derived = metrics in the sentence should been corrected as "direct metric". = >Did you mean something like "An example is a metric
>>> = derived by algorithmically combining measured metrics."? [Qin]:I agree = with your suggested text and like to adopt your suggestion. > The = definitions of Interval, Cumulative, and Sampled metrics are not clear. = [Qin]: I agree the definition for these three metrics need to be more = cleaer, I proposes to do the following changes: NEW Text: " Interval = metrics Metrics of which the reported values are measured in the most recent measurement interval duration between successive metrics = reports. Such measurement interval is equal to one RTCP report interval = (RFC3550,Section 6.2). Cumulative metrics Metrics of which the reported = values apply to the accumulation period characteristic of cumulative = measurements. The reported values are measured during the accumulation = period. The accumulation period spans over more than one RTCP report = intervals. Sampled metrics Metrics of which the reported values only = apply to the value of a continuously measured or
>> calculated = metric that has been sampled at any given instance of the RTCP report = interval. One example of such metric is the inter-arrival jitter = described in the section 6.4.1 of RFC3550. " > If the discussion at = the end of section 3.1 is kept, the reference to
>>> = RFC5760 should be a real reference, and RFC5760 should appear in the =
>>> reference section. [Qin]: Okay. > The point of section 3.2 is not obvious. How does it contribute to the =
>>> description of the architecture. It mixes talking about = what report
>>> blocks are with occasionally needing to = send them more frequently. Those
>>> points could be made = separately and more simply. [Qin]: Okay. I like to incorporate the key = points in the section 3.2 into section 3.1 > Section 3.3 is not clear = - it starts off saying that the location of the
>>> sender = and receiver may change what metrics are meaningful. It's not =
>>> clear what you mean by location. You certainly don't = mean geospatial
>>> coordinates. Do you mean anything other = than whether the element is
>>> trusted or untrusted by the = operations network? If so, say that. The
>>> rest of the = paragraph only speaks to what element collects the metrics. [Qin] = Section 3.3 is only used to describe where or from which RTP entity to gather the metrics (i.e., measurement point) in the physical = network and is not focus of this document. Secondly, I think the = definition of application level metrics has already clarified that = application level metrics is normally gathered from user endpoint. > = It's not clear that the set of meaningful metrics is changed at all - =
>>> just where you collect them. If the set of meaningful = metrics does in
>>> fact change, there needs to be = additional discussion here. [Qin]: The metrics actually doesn't = change.Since the definition of application level metrics Have already = conveyed the meaning of what section 3.3 wants to describe, I propose to = remove this section. > Section 4's first paragraph: Is "probably" the = best the working group
>>> can say? [Qin]:No, will remove = this word. > The last two sentences of the second bullet in section 4 = do not parse.
>>> Please simplify them. [Qin]: Okay, how about change them as follows: NEW Text: " With these minimal = number of RTCP statistics parameters mapped to non-RTCP measurements, it = is hard to provide accurate measures of real time application = quality,conduct detailed data analysis and creates alerts timly to the = users. Therefore correlation between RTCP XR and non-RTP data should be = provided. " > The first full sentence of the third bullet in section = 4 does not make
>>> sense. The whole bullet could be = clarified. [Qin]: Agree and will remove the first sentence. > The = fourth bullet in section 4 and section 5.5 should call out that =
>>> RFC3611 already set Block Type 255 aside for future = extensions,
>>> anticipating the potential need to extend = the block type space. [Qin]: Okay, How about revising the section = 4,bullet 4 as follows: " Consumption of XR block code points. The RTCP = XR block namespace is limited by the 8-bit block type field in the RTCP XR header. Space exhaustion may be a concern in the future. = Anticipating the potential need to extend the block type space, it is = noted in [RFC3611] that Block Type 255 is reserved for future = extensions, " > In section 5, consider naming the subsections with = the actual guideline
>>> instead of the problem the = guideline is trying to address.
>>> 5.1. Metric blocks = should contain a single metric [Qin]: I suggest to change it as "Contain = the single metrics in the metric block" > 5.2. Include the payload = type and format parameters in the metric block [Qin]: Okay. > 5.3. = Use RTCP SDES to correlate XR reports with non-RTP data [Qin]: Okay. = > 5.4. Don't repeat measurement information across metric = blocks
>>>
>> [Qin]: It is not possible completely = to avoid measurement information repeatition. e.g., for packet loss = robustness if the report blocks for the same interval span over more = than one RTCP packet then each must have the same measurement identity information So = I suggest to change it as: "reduce measurement information across metric = blocks" > This points out a structural problem with the section. Why = is 5.5 here?
>>> It's not a guideline. [Qin]: Agree and = also as discussed,Space exhaustion is not big issue. How about remove = this section? > (*) And it raises a question about what the document = is trying to
>>> achieve with section 5.4. That section = claims the document is proposing
>>> a new XR block type to = help avoid duplication, but it doesn't actually
>>> define = the new block type. Is the guideline saying simply don't repeat =
>>> measurements or its the guideline saying "use this new = XR block type we
>>> haven't defined yet"? [Qin]: Just to = clarify, we have already defined one new XR Block type to help avoid or = reduce duplication. It is measurement information block. The relevant draft is available at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-me= as-identity-06 >The section needs more clarity. If it really is =
>>> trying to define a new type, there's more work to be = done. [Qin]: In order to avoid such confusion, I proposed to do the = following change to the section 5.4: OLD Text: " This memo proposes to = define a new XR Block that will be used to convey the common time period = and the number of packets sent during this period. " New text: " This = memo proposes to define a new XR Block (i.e., the Measurement = information block[I.D-ietf-xrblock-rtcp-xr-meas-identity]) that will be = used to convey the common time period and the number of packets sent = during this period. " > The Security Considerations section, = particularly the third paragraph,
>>> needs to be clearer. What exactly do you mean by "monitoring should be =
>>> prohibited", and how is the fact that third party = monitors don't send
>>> RTCP relevant? Did you intend those = to be separate points? [Qin]: Yes, they are on the different port. Such = monitor may receive RTP packet but does not send RTCP packet. > = Editorial Nits and Suggestions:
>>>
>>> The = first paragraph of the introduction is overly complex, and won't age =
>>> well. I suggest replacing it with: "Multimedia services = using the
>>> Real-Time Protocol (RTP) are seeing increased = use. Standard methods for
>>> gathering RTP performance = metrics from these applications are needed to
>>> manage = uncertainties in the behavior and availability of their
>>> = services." Then replace "These rapidly emerging standards," with =
>>> "Standards". [Qin]: Okay. > Introduction paragraph 3 sentence 2 should start "The RTCP Guidelines =
>>> [RFC5968]". It would be even better to use the full = title from 5968:
>>> 'The "Guidelines for Extending the RTP = Control Protocol (RTCP)" [RFC5968]' [Qin]: Okay. > This may become = moot as section 3 is modified to make its main point
>>> = more obvious, but RFC3550 does not characterize Monitors as "a source of =
>>> information". That could be misunderstood. Please = choose another word.
>>> Perhaps "repository"? [Qin]: Okay, = repository looks good to me. > In bullet lists, starting an entry = with "or" or "and" is unnecessary. It
>>> should be clear = from the introduction to the list whether the individual =
>>> entries should be combined or selected from. [Qin]: = Okay. > In section 3.1 where you say "RTP may be used to multicast = groups" did
>>> you mean "RTP may be sent to multicast = groups" or "RTP may be used with
>>> multicast groups"? [Qin]: I = think it should be the latter case,i.e.," RTP may be used with =
>> multicast groups". >
>>> In section 3.2 = "The following are four use cases but are not limited
>>> = to:" does not parse. The bullets aren't really use cases as much as they =
>>> are mechanisms. Would it make more sense to say "Here = are four
>>> mechanisms that have been created to address = the need for more frequent
>>> reporting. This list is not = intended to be exhaustive." The third bullet
>>> in that = list should say "RTCP and RTCP XR are" instead of "RTCP or RTCP =
>>> XR is". [Qin]: Okay, but I have incorporated the = keypoints of section 3.2 into section 3.1. > The bullets in section 4 = would be better as subsections with titles
>>> (taken from = the first phrase of the bullet). [Qin]: Okay. > I suggest this alternative for the first full sentence in the first
>>> = bullet of section 4 : "A compound metrics block is designed to contain a =
>>> large number of parameters from different classes for a = specific
>>> application in a single block." [Qin]: Okay. = > Section 5's title should be "Guidelines for reporting" instead of =
>>> "Guideline for reporting" [Qin]: Okay. > In section = 5.1 I suggest "justify the overhead," instead of "justify the =
>>> overheads," [Qin]: Okay. > Section 7 - the last = sentence of the first paragraph does not parse. The
>>> = second paragraph (which is a single sentence) should be clarified - an =
>>> MCU is not a topology. [Qin]: Okay. How about revising = them as follows: OLD Text: " The topologies in this category are = Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such topologies = based on systems do not behave according to the RTP protocol [RFC3550]. Considering the MCU and translator are two typical = topologies in the two categories mentioned above, this document will = take them as two typical examples to explain how RTCP XR report works in = different RFC5117 topologies. " NEW Text: " The topologies in this = category are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such = topologies based on systems (e.g.,MCU) do not behave according to the = RTP protocol [RFC3550]. Considering the MCU and translator are two = typical intermediary systems in the two categories mentioned above, this = document will take them as two typical examples to explain how RTCP XR = report works in different RFC5117 topologies. " > The last two = sentences of the first
>> paragraph of the security =
>>> considerations section add nothing to the document. I = suggest deleting them. [Qin]: Okay. > = _______________________________________________
>>> = Audio/Video Transport Core Maintenance
>>> avt at ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt = >
>> ________________________________
>> =
>> * References:
>> * [AVTCORE] Subject: AD review = of draft-ietf-avtcore-monarch-13
>> * From: Robert = Sparks
>> * Prev by Date: [AVTCORE] Protocol Action: 'Explicit = Congestion Notification (ECN) for RTP over
>> UDP' to Proposed = Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)
>> * Previous = by thread: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 =
>> * Next by thread: [AVTCORE] Protocol Action: 'Explicit = Congestion Notification (ECN) for RTP over
>> UDP' to Proposed = Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)
>> * = Index(es):
>> * Date
>> * Thread
>> _______________________________________________
>> Audio/Video = Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
> =
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
> =



--
Colin Perkins
http://csperkins.org/





=
=



-- 
Colin Perkins



= --Apple-Mail=_4A102C3F-ABC2-4132-A004-506D7096699F-- From ron.even.tlv@gmail.com Thu May 24 15:58:16 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F89011E80BB for ; Thu, 24 May 2012 15:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 qOtTv0j6Mil4 for ; Thu, 24 May 2012 15:58:15 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4516C11E80B5 for ; Thu, 24 May 2012 15:58:15 -0700 (PDT) Received: by werb13 with SMTP id b13so229991wer.31 for ; Thu, 24 May 2012 15:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=CY4Y4oxxpWo2ki6w1vdSobg/iDwa5P/WaKAIX5D9UNM=; b=WcoJn8eeqqBAUHfsZJTtD8h/xzwKqfFhuOEDpJCOwCiLAgZ2ngHpm7bsIiHryo7C3G T1mxhGmc66NjjyfGD40+cj0EsYtIQu0w9Bk9ujpnpJf/D0nXQvVWfpFpoZ2U3QXaw47C t8MQ+BovkhTkmeo9ogzs9Y5+GVtPQhpPvd7YfQ32S6r81huvRz6UI1SXbJqgcVyR8mVJ 6PkKxY3HYP30TYqNTt5+eMw05bolSGvrfOK8SiIRtKSOgbuZGcIPQl0mm9Qf/85GTnwV m98KcbH9tKNqbY1rKKuMcf7XLsQXhcwDUQOOeatdSsjSkZ3eHVHGkUoN4+t8hP/y120a X57Q== Received: by 10.216.215.221 with SMTP id e71mr589032wep.132.1337900294352; Thu, 24 May 2012 15:58:14 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id z8sm13170897wiy.1.2012.05.24.15.58.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 15:58:13 -0700 (PDT) From: "Roni Even" To: Date: Fri, 25 May 2012 01:55:52 +0300 Message-ID: <4fbebd05.8854b40a.6284.ffff9d1e@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CD3A19.862EF470" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac06AF5PKfMfCU49TDCoStzqXbfshA== Content-Language: en-us Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:58:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CD3A19.862EF470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed the draft and have some comments 1. In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS? 2. In section 6 when defining Packet Presented NTP timestamp it says "This timestamp reflects the wall clock time at the moment the data contained in the first octet of the associated RTP packet is presented to the user " I am not sure how to know this since the displayed information is not the RTP information but the decoded information so it is not clear what is the first byte. I think that maybe it will good to state in the definition here and in the packet received that it is the first byte of the first packet in the frame or the first byte in the rendered frame. I think that in section 7 you have a better definition. 3. About the SDP parameters in section 9 and 10. Are these negotiated between the MCs and the MSAS or just announced by the MSAS. It will be good to clarify the usage 4. I understand that you list the two SDP parameter but the SC need one of them depending if it supports the ETSI version or this one. Based on the previous question response it will be good to list the proposed SDP sent from the MSAS. 5. I am also not sure how the MSAS will know if to send the RTCP message or the RTCP-XR message. It is mentioned in section 11 what it should do but not how the MSAS know which one to send. 6. In section 13 it will be good to say that the security consideration of RFC 3611 apply here also. 7. The IANA section is not clear explain one by one what to do with the four entities. As for the ETSI ones (the RTCP-XR and SFP) do you want to change them or have a reference to this document, if not they are not needed as IANA consideration since there is no IANA action there. 8. You can remove section 16. Roni Even as Individual _____ ------=_NextPart_000_000A_01CD3A19.862EF470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

I reviewed the draft and have some = comments

 

1.       = In section 6 you have the = sentence "If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS = (SPST=3D2)" but above the value 2 is not defined for this document. = Do you expect systems that support this document to also support the = ETSI XR report from the MSAS?

2.       = In section 6 when = defining Packet Presented NTP timestamp it says "This timestamp = reflects the wall clock time at the moment the data contained in the = first octet  of the associated RTP packet is presented to the user = " I am not sure how to know this since the displayed information is = not the RTP information but the decoded information so it is not clear = what is the first byte. I think that maybe it will good to state in the = definition here and in the packet received that it is the first byte of = the first packet in the frame or the first byte in the rendered frame. I = think that in section 7 you have a better definition.

3.       = About the SDP parameters = in section 9 and 10. Are these negotiated between the MCs and the MSAS = or just announced by the MSAS.  It will be good to clarify the = usage

4.       = I understand that you = list the two SDP parameter but the SC need one of them depending if it = supports the ETSI version or this one. Based on the previous question = response it will be good to list the proposed SDP sent from the = MSAS.

5.       =  I am also not sure = how the MSAS will know if to send the RTCP message or the RTCP-XR = message. It is mentioned in section 11 what it should do but not how the = MSAS know which one to send.

6.       = In section 13 it will be = good to say that the security consideration of RFC 3611 apply here = also.

7.       = The IANA section is not = clear explain one by one what to do with the four entities. As for the = ETSI  ones (the RTCP-XR and SFP) do you want to change them or have = a reference to this document, if not they are not needed as IANA = consideration since there is no IANA action there.

8.       = You can remove section = 16.

 

Roni Even as Individual

 

 

 

------=_NextPart_000_000A_01CD3A19.862EF470-- From JA.Berryman@us.bosch.com Thu May 24 16:28:33 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0817011E8099 for ; Thu, 24 May 2012 16:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.292 X-Spam-Level: X-Spam-Status: No, score=-7.292 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] 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 2dXuMQxne1QE for ; Thu, 24 May 2012 16:28:32 -0700 (PDT) Received: from smtp2-v.fe.bosch.de (smtp2-v.fe.bosch.de [139.15.237.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB28F11E8081 for ; Thu, 24 May 2012 16:28:31 -0700 (PDT) Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.30]) by imta24.fe.bosch.de (Postfix) with ESMTP id 7DAB5B00002 for ; Fri, 25 May 2012 01:19:39 +0200 (CEST) Received: from localhost (vsgw4.fe.internet.bosch.com [10.4.98.12]) by vsmta12.fe.internet.bosch.com (Postfix) with SMTP id DFC5C1AC0208 for ; Fri, 25 May 2012 01:28:29 +0200 (CEST) Received: from SI-MBX82.de.bosch.com ([10.3.153.131]) by si-hub03.de.bosch.com ([10.3.144.92]) with mapi; Fri, 25 May 2012 01:28:22 +0200 From: "Berryman Jeff (ST-CO/ENS-CA)" To: "avt@ietf.org" Date: Fri, 25 May 2012 01:27:26 +0200 Thread-Topic: draft-williams-avtcore-clksrc-00 : SUPPORT ADOPTION Thread-Index: Ac06BMeRUFPC4SgCS3WqAhPqIbPeyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ADEC3923341B7F4AA99AFE50084F61993A7B74B189SIMBX82debosc_" MIME-Version: 1.0 Subject: [AVTCORE] draft-williams-avtcore-clksrc-00 : SUPPORT ADOPTION X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 23:28:33 -0000 --_000_ADEC3923341B7F4AA99AFE50084F61993A7B74B189SIMBX82debosc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of http://tools.ietf.org/html/draft-williams-avtcore= -clksrc-00 as a WG document. Jeff Berryman Senior Scientist Bosch Security Systems Inc. Communications Systems Division 12000 Portland Avenue South Burnsville, Minnesota USA 55337 http://www.boschsecurity.us/ Tel +1 519 924 0105 Mobile +1 952 457 5445 Time zone GMT-5 (winter), GMT-4 (summer) ja.berryman@us.bosch.com --_000_ADEC3923341B7F4AA99AFE50084F61993A7B74B189SIMBX82debosc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption of http://tools.ietf.org/html/= draft-williams-avtcore-clksrc-00  as a WG document.

Jeff Berryman

Senior Scientist
Bosch Security Systems Inc.
Communications Systems Division
12000 Portland Avenue South
Burnsville, Minnesota
USA 55337
http://www.boschsecurity.us/=

Tel          &nb= sp;    +1 519 924 0105
Mobile          +1 952 457 5445
Time zone     GMT-5 (winter), GMT-4 (summer)
ja.berryman@us.bosch.com=

&nb= sp;

--_000_ADEC3923341B7F4AA99AFE50084F61993A7B74B189SIMBX82debosc_-- From bill.wu@huawei.com Thu May 24 18:18:00 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25E11E8085 for ; Thu, 24 May 2012 18:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, 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 HpRbOPn4Po5j for ; Thu, 24 May 2012 18:17:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7B94F11E8080 for ; Thu, 24 May 2012 18:17:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM92854; Thu, 24 May 2012 21:17:59 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 18:14:44 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 18:14:50 -0700 Received: from w53375 (10.138.41.149) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 May 2012 09:14:45 +0800 Message-ID: <244701A3B31A44F9B9A9524E65668228@china.huawei.com> From: Qin Wu To: "Charles Eckel (eckelcu)" , Robert Sparks , IETF AVTCore WG , References: <4FB2E323.3090406@nostrum.com> <4E75E88AD2C84AC6A3824697C4126DB2@china.huawei.com> Date: Fri, 25 May 2012 09:14:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:18:00 -0000 SGksIENoYXJsZXM6DQpJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBjb21tZW50cyB0byBkaXN0aW5j dCBvbmUgY29uY2VwdCBmcm9tIGFub3RoZXIuIA0KUGxlYXNlIHNlZSBteSBwcm9wb3NlZCBjaGFu Z2UgYmVsb3cuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogIkNoYXJsZXMgRWNrZWwgKGVja2VsY3UpIiA8ZWNrZWxjdUBjaXNjby5jb20+DQpU bzogIlFpbiBXdSIgPGJpbGwud3VAaHVhd2VpLmNvbT47ICJSb2JlcnQgU3BhcmtzIiA8cmpzcGFy a3NAbm9zdHJ1bS5jb20+OyAiSUVURiBBVlRDb3JlIFdHIiA8YXZ0QGlldGYub3JnPjsgPGRyYWZ0 LWlldGYtYXZ0Y29yZS1tb25hcmNoQHRvb2xzLmlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIE1h eSAyNCwgMjAxMiAzOjI5IEFNDQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xMw0KDQoNCkhpIFFpbiwNCg0KVGhl IGRlZmluaXRpb25zIHNlY3Rpb24gb2YgdGhlIG1vbmFyY2ggZHJhZnQgbmVlZHMgdG8gY2xlYXJs eSBkZWZpbmUgdHdvDQppbXBvcnRhbnQgY29uY2VwdHM6DQoxKSBkaXJlY3QgdnMuIGNvbXBvc2Vk IG1ldHJpY3MNCjIpIGludGVydmFsIHZzLiBjdW11bGF0aXZlIHZzLiBzYW1wbGVkIG1ldHJpY3MN ClRoZXNlIGFyZSBpbmRlcGVuZGVudCBjb25jZXB0cywgYW5kIHRoZSBkZWZpbml0aW9ucyBuZWVk IHRvIGJlDQppbmRlcGVuZGVudCBhcyB3ZWxsLiBGb3IgdGhhdCByZWFzb24sIEkgdGhpbmsgaXQg aXMgaW1wb3J0YW50IHRvIGF2b2lkDQphbnkgbWl4aW5nIG9mIHRoZSB0d28uIFBsZWFzZSBzZWUg Y29uY2VybnMgcmVnYXJkaW5nIHRoaXMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBRaW4gV3UNCj4gU2VudDogVHVlc2RheSwgTWF5IDIy LCAyMDEyIDY6MzEgUE0NCj4gVG86IFJvYmVydCBTcGFya3M7IElFVEYgQVZUQ29yZSBXRzsgZHJh ZnQtaWV0Zi1hdnRjb3JlLQ0KPiBtb25hcmNoQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS0NCj4g bW9uYXJjaC0xMw0KPiANCj4gPj4gVGhlIGRlZmluaXRpb25zIG9mIEludGVydmFsLCBDdW11bGF0 aXZlLCBhbmQgU2FtcGxlZCBtZXRyaWNzIGFyZQ0Kbm90DQo+IGNsZWFyLg0KPiA+DQo+ID4gW1Fp bl06IEkgYWdyZWUgdGhlIGRlZmluaXRpb24gZm9yIHRoZXNlIHRocmVlIG1ldHJpY3MgbmVlZCB0 byBiZQ0KbW9yZQ0KPiBjbGVhZXIsIEkgcHJvcG9zZXMgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFu Z2VzOg0KPiA+DQo+ID4gTkVXIFRleHQ6DQo+ID4NCj4gPiAiDQo+ID4NCj4gPiAgIEludGVydmFs IG1ldHJpY3MNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJl cG9ydGVkIHZhbHVlcw0KPiA+DQo+ID4gICAgICBhcmUgbWVhc3VyZWQgaW4gdGhlIG1vc3QgcmVj ZW50IG1lYXN1cmVtZW50IGludGVydmFsIGR1cmF0aW9uDQo+IGJldHdlZW4NCj4gPg0KPiA+ICAg ICAgc3VjY2Vzc2l2ZSBtZXRyaWNzIHJlcG9ydHMuIFN1Y2ggbWVhc3VyZW1lbnQgaW50ZXJ2YWwg aXMgZXF1YWwNCj4gdG8gb25lDQo+ID4NCj4gPiAgICAgUlRDUCByZXBvcnQgaW50ZXJ2YWwgKFJG QzM1NTAsU2VjdGlvbiA2LjIpLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgIEN1bXVs YXRpdmUgbWV0cmljcw0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAgTWV0cmljcyBvZiB3aGljaCB0 aGUgcmVwb3J0ZWQgdmFsdWVzDQo+ID4NCj4gPiAgICAgIGFwcGx5IHRvIHRoZSBhY2N1bXVsYXRp b24gcGVyaW9kIGNoYXJhY3RlcmlzdGljIG9mIGN1bXVsYXRpdmUNCj4gPg0KPiA+ICAgICAgbWVh c3VyZW1lbnRzLiBUaGUgcmVwb3J0ZWQgdmFsdWVzIGFyZSBtZWFzdXJlZCBkdXJpbmcgdGhlDQo+ IGFjY3VtdWxhdGlvbiBwZXJpb2QuDQo+ID4NCj4gPiAgIFRoZSBhY2N1bXVsYXRpb24gcGVyaW9k IHNwYW5zIG92ZXIgbW9yZSB0aGFuIG9uZSBSVENQIHJlcG9ydA0KPiBpbnRlcnZhbHMuDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgU2FtcGxlZCBtZXRyaWNzDQo+ID4NCj4gPg0KPiA+ DQo+ID4gICAgICBNZXRyaWNzIG9mIHdoaWNoIHRoZSByZXBvcnRlZCB2YWx1ZXMgb25seQ0KPiA+ DQo+ID4gICAgICBhcHBseSB0byB0aGUgdmFsdWUgb2YgYSBjb250aW51b3VzbHkgbWVhc3VyZWQg b3IgY2FsY3VsYXRlZA0KPiBtZXRyaWMNCj4gPg0KPiA+ICAgICAgdGhhdCBoYXMgYmVlbiBzYW1w bGVkIGF0IGFueSBnaXZlbiBpbnN0YW5jZSBvZiB0aGUgUlRDUCByZXBvcnQNCj4gaW50ZXJ2YWwu DQo+ID4NCj4gPiAgICAgT25lIGV4YW1wbGUgb2Ygc3VjaCBtZXRyaWMgaXMgdGhlIGludGVyLWFy cml2YWwgaml0dGVyIGRlc2NyaWJlZA0KPiBpbiB0aGUgc2VjdGlvbiA2LjQuMSBvZiBSRkMzNTUw Lg0KPiA+DQo+ID4gIg0KPiBbUWluXTogT25lIGltcHJvdmVtZW50IHRvIGRlZmluaXRpb25zIG9m IEludGVydmFsIE1ldHJpY3MsIEN1bXVsYXRpdmUNCj4gTWV0cmljcyBhbmQgU2FtcGxlZCBNZXRy aWNzIHRvIGdldCBhbGlnbm1lbnQgd2l0aCBkcmFmdC1pZXRmLXhyYmxvY2stDQo+IHJ0Y3AteHIt bWVhcy1pZGVudGl0eQ0KPiBzaW5jZSBiYXNlZCBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14 ci1tZWFzLWlkZW50aXR5LCBpbiBzb21lDQo+IGNhc2UsdGhlIG1lYXN1cmVtZW50IGludGVydmFs IGZvciBhIG1ldHJpYyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgUlRDUA0KPiByZXBvcnRpbmcgaW50 ZXJ2YWwsIGluIHN1Y2ggY2FzZSwgTWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gYmxvY2sgaW4gdGhl DQo+IGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLW1lYXMtaWRlbnRpdHkgY2FuIGJlIHVzZWQg dG8gc3BlY2lmeSBzdWNoDQo+IG1lYXN1cmVtZW50IGludGVydmFsLg0KPiANCj4gVGhlIHByb3Bv c2VkIGltcHJvdmVtZW50IGlzIGRlc2NyaWJlZCBhcyBmb2xsb3dzOg0KDQpBbGwgdGhyZWUgZGVm aW5pdGlvbnMgdGhhdCBmb2xsb3cgbmVlZCB0byB1c2UgZXF1aXZhbGVudCBsYW5ndWFnZSBzdWNo DQp0aGF0IGFsbCB0aHJlZSBhcmUgY2xlYXJseSBhcHBsaWNhYmxlIHRvIGJvdGggZGlyZWN0IGFu ZCBjb21wb3NlZA0KbWV0cmljcy4NCg0KW1Fpbl06T2theS4gVGhhdCdzIGEgZ29vZCBzdWdnZXN0 aW9uLg0KDQo+ICINCj4gSW50ZXJ2YWwgbWV0cmljczoNCj4gDQo+IE1ldHJpY3MgY2FsY3VsYXRl ZCBiYXNlZCBvbiB2YWx1ZXMgbWVhc3VyZWQgb3ZlciB0aGUgY291cnNlIG9mIGENCnNpbmdsZQ0K PiByZXBvcnRpbmcgaW50ZXJ2YWwuIFRoaXMgbWF5IGJlIHRoZSBtb3N0IHJlY2VudCBSVENQIHJl cG9ydGluZw0KaW50ZXJ2YWwNCj4gKFtSRkMzNTUwXSwgc2VjdGlvbiA2LjIpIG9yIHNvbWUgb3Ro ZXIgaW50ZXJ2YWwgc2lnbmFsbGVkIHVzaW5nIGFuDQpSVENQDQo+IE1lYXN1cmVtZW50IEluZm9y bWF0aW9uIFhSIEJsb2NrIFtkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLQ0KPiBpZGVu dGl0eV0uIEFuIGV4YW1wbGUgaW50ZXJ2YWwgbWV0cmljIGlzIHRoZSBjb3VudCBvZiB0aGUgbnVt YmVyIG9mDQpSVFANCj4gcGFja2V0cyBsb3N0IG92ZXIgdGhlIGNvdXJzZSBvZiB0aGUgbGFzdCBS VENQIHJlcG9ydGluZyBpbnRlcnZhbC4NCg0KSG93IGFib3V0IHJlcGxhY2luZyAiTWV0cmljcyBj YWxjdWxhdGVkIGJhc2VkIG9uIHZhbHVlcyBtZWFzdXJlZCBvdmVyDQp0aGUgY291cnNlIC4uLiIg d2l0aCAiTWV0cmljcyBtZWFzdXJlZCBvdmVyIHRoZSBjb3Vyc2UgLi4uIj8NCg0KW1Fpbl06IE9r YXksIHRoZSBwcm9wb3NlZCBjaGFuZ2UgdG8gdGhlIGRlZmluaXRpb24gb2YgSW50ZXJ2YWwgbWV0 cmljcyBpcyBkZXNjcmliZWQgYXMgZm9sbG93czoNCk5FVyBURVhUDQoiDQpNZXRyaWNzIG1lYXN1 cmVkIG92ZXIgdGhlIGNvdXJzZSBvZiBhIHNpbmdsZSByZXBvcnRpbmcgaW50ZXJ2YWwgYmV0d2Vl biB0d28gc3VjY2Vzc2l2ZQ0KcmVwb3J0IGJsb2Nrcy4gVGhpcyBtYXkgYmUgdGhlIG1vc3QgcmVj ZW50IFJUQ1AgcmVwb3J0aW5nIGludGVydmFsIChbUkZDMzU1MF0sIHNlY3Rpb24gNi4yKSANCm9y IHNvbWUgb3RoZXIgaW50ZXJ2YWwgc2lnbmFsbGVkIHVzaW5nIGFuIFJUQ1AgTWVhc3VyZW1lbnQg SW5mb3JtYXRpb24gWFIgQmxvY2sgW01JXS4gDQpBbiBleGFtcGxlIGludGVydmFsIG1ldHJpYyBp cyB0aGUgY291bnQgb2YgdGhlIG51bWJlciBvZiBSVFAgcGFja2V0cyBsb3N0IG92ZXIgdGhlIGNv dXJzZSANCm9mIHRoZSBsYXN0IFJUQ1AgcmVwb3J0aW5nIGludGVydmFsLg0KDQoiDQogDQo+IEN1 bXVsYXRpdmUgbWV0cmljczoNCj4gDQo+IE1ldHJpY3MgZGVyaXZlZCBmcm9tIGN1bXVsYXRpdmUg bWVhc3VyZW1lbnRzIHRha2VuIG92ZXIgc2V2ZXJhbA0KPiByZXBvcnRpbmcgaW50ZXJ2YWxzLiBU aGUgdGltZSBwZXJpb2Qgb3ZlciB3aGljaCBtZWFzdXJlbWVudHMgYXJlDQo+IGFjY3VtdWxhdGVk IGNhbiBiZSB0aGUgY29tcGxldGUgUlRQIHNlc3Npb24sIG9yIHNvbWUgb3RoZXIgaW50ZXJ2YWwN Cj4gc2lnbmFsbGVkIHVzaW5nIGFuIFJUQ1AgTWVhc3VyZW1lbnQgSW5mb3JtYXRpb24gWFIgQmxv Y2sgW2RyYWZ0LWlldGYtDQo+IHhyYmxvY2stcnRjcC14ci1tZWFzLWlkZW50aXR5XS4gIEFuIGV4 YW1wbGUgY3VtdWxhdGl2ZSBtZXRyaWMgaXMgdGhlDQo+IHRvdGFsIG51bWJlciBvZiBSVFAgcGFj a2V0cyBsb3N0IHNpbmNlIHRoZSBzdGFydCBvZiB0aGUgUlRQIHNlc3Npb24uDQo+IA0KDQpIb3cg YWJvdXQgcmVwbGFjaW5nICJNZXRyaWNzIGRlcml2ZWQgZnJvbSBjdW11bGF0aXZlIG1lYXN1cmVt ZW50cyB0YWtlbg0Kb3ZlciBzZXZlcmFsIC4uLiIgd2l0aCAiTWV0cmljcyBtZWFzdXJlZCBvdmVy IHNldmVyYWwgLi4uIj8NCg0KW1Fpbl06IE9rYXksIHRoZSBwcm9wb3NlZCBjaGFuZ2UgdG8gdGhl IGRlZmluaXRpb24gb2YgSW50ZXJ2YWwgbWV0cmljcyANCndvdWxkIGJlOg0KTkVXIFRFWFQNCiIN Ck1ldHJpY3MgbWVhc3VyZWQgb3ZlciBzZXZlcmFsIHJlcG9ydGluZyBpbnRlcnZhbHMgZm9yIGFj Y3VtdWxhdGluZyBzdGF0aXN0aWNzLiANClRoZSB0aW1lIHBlcmlvZCBvdmVyIHdoaWNoIG1lYXN1 cmVtZW50cyBhcmUgYWNjdW11bGF0ZWQgY2FuIGJlIHRoZQ0KIGNvbXBsZXRlIFJUUCBzZXNzaW9u LCBvciBzb21lIG90aGVyIGludGVydmFsIHNpZ25hbGxlZCB1c2luZyBhbiBSVENQIA0KTWVhc3Vy ZW1lbnQgSW5mb3JtYXRpb24gWFIgQmxvY2sgW01JXS4gIEFuIGV4YW1wbGUgY3VtdWxhdGl2ZSBt ZXRyaWMgDQppcyB0aGUgdG90YWwgbnVtYmVyIG9mIFJUUCBwYWNrZXRzIGxvc3Qgc2luY2UgdGhl IHN0YXJ0IG9mIHRoZSBSVFAgc2Vzc2lvbi4NCg0KIg0KDQoNCj4gU2FtcGxlZCBtZXRyaWNzOg0K PiANCj4gTWV0cmljcyB0aGF0IGFyZSBzYW1wbGVkIGF0IGEgcGFydGljdWxhciB0aW1lIGluc3Rh bnQgd2l0aGluIGENCj4gcmVwb3J0aW5nIGludGVydmFsIChnZW5lcmFsbHkgdGhlIHZhbHVlIG9m IHNvbWUgbWVhc3VyZW1lbnQgYXMgdGFrZW4NCmF0DQo+IHRoZSBlbmQgb2YgdGhlIHJlcG9ydGlu ZyBpbnRlcnZhbCkuIEFuIGV4YW1wbGUgaXMgdGhlIGludGVyLWFycml2YWwNCj4gaml0dGVyIHJl cG9ydGVkIGluIFJUQ1AgU1IgYW5kIFJSIHBhY2tldHMsIHdoaWNoIGlzIGNvbnRpbnVhbGx5DQp1 cGRhdGVkDQo+IGFzIGVhY2ggUlRQIGRhdGEgcGFja2V0IGFycml2ZXMsIGJ1dCBvbmx5IHJlcG9y dGVkIGJhc2VkIG9uIGEgc25hcHNob3QNCj4gb2YgdGhlIHZhbHVlIHdoaWNoIGlzIHNhbXBsZWQg YXQgdGhlIGluc3RhbnQgdGhlIHJlcG9ydGluZyBpbnRlcnZhbA0KPiBlbmRzLg0KPiANCj4gIg0K DQpIb3cgYWJvdXQgcmVwbGFjaW5nICJNZXRyaWNzIHRoYXQgYXJlIHNhbXBsZWQgYXQgYSBwYXJ0 aWN1bGFyIHRpbWUNCmluc3RhbnQgLi4uIiB3aXRoICJNZXRyaWNzIG1lYXN1cmVkIGF0IGEgcGFy dGljdWxhciB0aW1lIGluc3RhbnQuLi4iPw0KDQpbUWluXTogT2theSwgdGhlIHByb3Bvc2VkIGNo YW5nZSB0byB0aGUgZGVmaW5pdGlvbiBvZiBJbnRlcnZhbCBtZXRyaWNzIA0Kd291bGQgYmU6DQpO RVcgVEVYVA0KIg0KTWV0cmljcyBtZWFzdXJlZCBhdCBhIHBhcnRpY3VsYXIgdGltZSBpbnN0YW50 IGFuZCBzYW1wbGVkIGZyb20gdGhlIHZhbHVlcyBvZg0KYSBjb250aW51b3VzbHkgbWVhc3VyZWQg b3IgY2FsY3VsYXRlZCBtZXRyaWMgd2l0aGluIGEgcmVwb3J0aW5nIGludGVydmFsIA0KKGdlbmVy YWxseSB0aGUgdmFsdWUgb2Ygc29tZSBtZWFzdXJlbWVudCBhcyB0YWtlbiBhdCB0aGUgZW5kIG9m IHRoZSByZXBvcnRpbmcgaW50ZXJ2YWwpLiAgDQpBbiBleGFtcGxlIGlzIHRoZSBpbnRlci1hcnJp dmFsIGppdHRlciByZXBvcnRlZCBpbiBSVENQIFNSIGFuZCBSUiBwYWNrZXRzLCANCndoaWNoIGlz IGNvbnRpbnVhbGx5IHVwZGF0ZWQgYXMgZWFjaCBSVFAgZGF0YSBwYWNrZXQgYXJyaXZlcywgYnV0 IG9ubHkgcmVwb3J0ZWQgYmFzZWQNCm9uIGEgc25hcHNob3Qgb2YgdGhlIHZhbHVlIHdoaWNoIGlz IHNhbXBsZWQgYXQgdGhlIGluc3RhbnQgdGhlIHJlcG9ydGluZyBpbnRlcnZhbCBlbmRzLg0KIg0K DQpUaGlzIHdheSB0aGUgd29yZGluZyByZW1haW5zIGNvbnNpc3RlbnQgYWNyb3NzIGFsbCB0aHJl ZSBkZWZpbml0aW9ucw0Kd2l0aG91dCBtaXhpbmcgaW4gYW55IHRlcm1zIHRoYXQgbWF5IGJlIGNv bmZ1c2VkIHRvIGFkZGluZyB0aWVzIHNwZWNpZmljDQp0byBkaXJlY3Qgb3IgY29tcG9zZWQgbWV0 cmljcy4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFp bnRlbmFuY2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXZ0 From Pieter.Demuytere@barco.com Fri May 25 00:35:23 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39521F8567 for ; Fri, 25 May 2012 00:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, SARE_SUB_6CONS_WORD=0.356] 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 3J3LH2ctgkU1 for ; Fri, 25 May 2012 00:35:22 -0700 (PDT) Received: from mail46.messagelabs.com (mail46.messagelabs.com [216.82.241.196]) by ietfa.amsl.com (Postfix) with SMTP id 8111D21F855F for ; Fri, 25 May 2012 00:35:22 -0700 (PDT) X-Env-Sender: Pieter.Demuytere@barco.com X-Msg-Ref: server-16.tower-46.messagelabs.com!1337931311!30828174!15 X-Originating-IP: [91.183.172.68] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21333 invoked from network); 25 May 2012 07:35:20 -0000 Received: from 68.172-183-91.adsl-static.isp.belgacom.be (HELO KUUFEX01.barco.com) (91.183.172.68) by server-16.tower-46.messagelabs.com with SMTP; 25 May 2012 07:35:20 -0000 Received: from KNDMEX01.barco.com ([150.158.212.51]) by KUUFEX01.barco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 09:30:33 +0200 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Importance: normal Priority: normal Received: from 150.158.231.24 ([150.158.231.24]) by kndmex01.barco.com ([150.158.212.51]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 May 2012 07:30:32 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3A48.44CE7B7A" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 Content-class: urn:content-classes:message Date: Fri, 25 May 2012 09:30:29 +0200 Message-ID: <028AE8A7C04EE14889BE99E5450BE32D0B0CE18E@kndmex01.barco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] adopting draft-williams-avtcore-clksrc-00 as a WG document Thread-Index: Ac06SETOV9VFzAB+Q/2zLYJZDZyziw== From: "Demuytere, Pieter" To: X-OriginalArrivalTime: 25 May 2012 07:30:33.0425 (UTC) FILETIME=[450E8C10:01CD3A48] Subject: Re: [AVTCORE] adopting draft-williams-avtcore-clksrc-00 as a WG document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 07:35:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3A48.44CE7B7A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I support the adoption of = http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as a WG = document Best Regards,=20 Pieter Demuytere Research Engineer=20 Network Multimedia Group Barco nv President Kennedypark 35, 8500 Kortrijk, Belgium Tel. +32 56 26 2034 Fax +32 56 26 2262 www.barco.com =20 pieter.demuytere@barco.com DISCLAIMER: Unless indicated otherwise, the information contained in this message is = privileged and confidential, and is intended only for the use of the = addressee(s) named above and others who have been specifically = authorized to receive it. If you are not the intended recipient, you are = hereby notified that any dissemination, distribution or copying of this = message and/or attachments is strictly prohibited. The company accepts = no liability for any damage caused by any virus transmitted by this = email. Furthermore, the company does not warrant a proper and complete = transmission of this information, nor does it accept liability for any = delays. If you have received this message in error, please contact the = sender and delete the message. Thank you. ------_=_NextPart_001_01CD3A48.44CE7B7A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi,

I support the adoption of  http= ://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as a WG document

Best Regards,

Pieter Demuytere
Research Engineer
Network Multimedia Group

Barco nv
President Kennedypark 35, 8500 Kortrijk, Belgium
Tel. +32 56 26 2034  Fax +32 56 26 2262
www.barco.com
pieter.demuytere@barco.com=

DISCLAIMER:
Unless indicated otherwise, the information = contained in this message is privileged and confidential, and is = intended only for the use of the addressee(s) named above and others who = have been specifically authorized to receive it. If you are not the = intended recipient, you are hereby notified that any dissemination, = distribution or copying of this message and/or attachments is strictly = prohibited. The company accepts no liability for any damage caused by = any virus transmitted by this email. Furthermore, the company does not = warrant a proper and complete transmission of this information, nor does = it accept liability for any delays. If you have received this message in = error, please contact the sender and delete the message. Thank = you. ------_=_NextPart_001_01CD3A48.44CE7B7A-- From fboronat@dcom.upv.es Fri May 25 02:24:49 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DCF21F857F for ; Fri, 25 May 2012 02:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, SARE_SUB_6CONS_WORD=0.356] 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 T-HKkrCr77uv for ; Fri, 25 May 2012 02:24:49 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6021F84A5 for ; Fri, 25 May 2012 02:24:48 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id q4P9Ol1s004445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 May 2012 11:24:47 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id q4P9OkG2029272 for ; Fri, 25 May 2012 11:24:47 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id q4P9OYDE031762 for ; Fri, 25 May 2012 11:24:44 +0200 Message-ID: <4FBF4FD1.5010607@dcom.upv.es> Date: Fri, 25 May 2012 11:24:33 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [AVTCORE] Support for draft-williams-avtcore-clksrc-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:24:49 -0000 Hi, I have read the drafthttp://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 and I also support its adoption as a WG document. Regards ======================================================================== Dr. Fernando Boronat Seguí Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== From mamontor@upvnet.upv.es Fri May 25 00:47:56 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4542521F85C6 for ; Fri, 25 May 2012 00:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] 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 PpbT1oGcmPR8 for ; Fri, 25 May 2012 00:47:55 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id B794521F85C9 for ; Fri, 25 May 2012 00:47:49 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id q4P7lknD016475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 May 2012 09:47:46 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id q4P7lkLK029266 for ; Fri, 25 May 2012 09:47:46 +0200 Received: from localhost (regulus.cc.upv.es [158.42.249.34]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id q4P7leFB017975 for ; Fri, 25 May 2012 09:47:45 +0200 Received: from gnd2g38-83.wi-fi.upv.es (gnd2g38-83.wi-fi.upv.es [158.42.38.83]) by wm.upv.es (Horde Framework) with HTTP; Fri, 25 May 2012 09:47:40 +0200 Message-ID: <20120525094740.16276mtyr9bkb0v0@wm.upv.es> Date: Fri, 25 May 2012 09:47:40 +0200 From: Mario Montagud Climent To: avt@ietf.org References: <4fbc94b3.c460b40a.6179.40b8@mx.google.com> In-Reply-To: <4fbc94b3.c460b40a.6179.40b8@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-Mailman-Approved-At: Fri, 25 May 2012 09:05:05 -0700 Subject: Re: [AVTCORE] adopting draft-williams-avtcore-clksrc-00 as a WG document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 07:51:13 -0000 Hi, I support the adoption of http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as a WG document Best Regards, Mario Montagud Roni Even escribió: > Hi, > > AVTcore have the following milestone: > Nov 2012 - Submit RTP Clock Source Signaling as Proposed Standard > > The chairs propose to adopt > http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the initial > document to address this milestone. > > The document will also be reviewed by the SDP directorate. > > There are no other documents addressing this milestone so please let the > chairs know if you support this action by June 6th > > Thanks > Roni Even > > > > From eckelcu@cisco.com Fri May 25 13:09:05 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1E21F87CC for ; Fri, 25 May 2012 13:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] 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 grsFyB0L32SY for ; Fri, 25 May 2012 13:09:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 486D121F87CB for ; Fri, 25 May 2012 13:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7965; q=dns/txt; s=iport; t=1337976544; x=1339186144; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YfUzVNeLEJ2lpLoQkF7r3o553KCgZzFWBZzDHHO96pI=; b=QQWnYOp2gEvBcIPGgZtSgJJLJVOoCNRC0i8+HerE3RjjE3EiNbwAxQHx 66IO/+R0Qt8/pVdfx49S1oAgQg/wOpcXQfIfbkgxAmBZP8dLQ2OqtztvK CgD78zLTYF8k1GKDbNnRRF+Av4H5uCZ8GoVl6nBnJN/alt+7LGsRJtLXA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALLmv0+rRDoJ/2dsb2JhbAA7CbUWgQeCFQEBAQQBAQEPAR0KSwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggah2oBC5h1n00EiwERhFVgA4g/iH6RZ4FkgwA X-IronPort-AV: E=Sophos;i="4.75,658,1330905600"; d="scan'208";a="43862736" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 25 May 2012 20:08:46 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4PK8jP4011914; Fri, 25 May 2012 20:08:45 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 13:08:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 May 2012 13:08:45 -0700 Message-ID: In-Reply-To: <244701A3B31A44F9B9A9524E65668228@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 Thread-Index: Ac06FCsSrvvKggxgRe63E3tSGpb/GAAndlSg References: <4FB2E323.3090406@nostrum.com> <4E75E88AD2C84AC6A3824697C4126DB2@china.huawei.com> <244701A3B31A44F9B9A9524E65668228@china.huawei.com> From: "Charles Eckel (eckelcu)" To: "Qin Wu" , "Robert Sparks" , "IETF AVTCore WG" , X-OriginalArrivalTime: 25 May 2012 20:08:45.0646 (UTC) FILETIME=[308896E0:01CD3AB2] Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:09:05 -0000 Hi Qin, This looks good to me. Thanks, Charles > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Thursday, May 24, 2012 6:15 PM > To: Charles Eckel (eckelcu); Robert Sparks; IETF AVTCore WG; draft- > ietf-avtcore-monarch@tools.ietf.org > Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore- > monarch-13 >=20 > Hi, Charles: > I fully agree with your comments to distinct one concept from another. > Please see my proposed change below. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Charles Eckel (eckelcu)" > To: "Qin Wu" ; "Robert Sparks" > ; "IETF AVTCore WG" ; avtcore-monarch@tools.ietf.org> > Sent: Thursday, May 24, 2012 3:29 AM > Subject: RE: [AVTCORE] Subject: AD review of draft-ietf-avtcore- > monarch-13 >=20 >=20 > Hi Qin, >=20 > The definitions section of the monarch draft needs to clearly define > two > important concepts: > 1) direct vs. composed metrics > 2) interval vs. cumulative vs. sampled metrics > These are independent concepts, and the definitions need to be > independent as well. For that reason, I think it is important to avoid > any mixing of the two. Please see concerns regarding this inline. >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > Qin Wu > > Sent: Tuesday, May 22, 2012 6:31 PM > > To: Robert Sparks; IETF AVTCore WG; draft-ietf-avtcore- > > monarch@tools.ietf.org > > Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore- > > monarch-13 > > > > >> The definitions of Interval, Cumulative, and Sampled metrics are > not > > clear. > > > > > > [Qin]: I agree the definition for these three metrics need to be > more > > cleaer, I proposes to do the following changes: > > > > > > NEW Text: > > > > > > " > > > > > > Interval metrics > > > > > > > > > > > > Metrics of which the reported values > > > > > > are measured in the most recent measurement interval duration > > between > > > > > > successive metrics reports. Such measurement interval is equal > > to one > > > > > > RTCP report interval (RFC3550,Section 6.2). > > > > > > > > > > > > > > > > > > Cumulative metrics > > > > > > > > > > > > Metrics of which the reported values > > > > > > apply to the accumulation period characteristic of cumulative > > > > > > measurements. The reported values are measured during the > > accumulation period. > > > > > > The accumulation period spans over more than one RTCP report > > intervals. > > > > > > > > > > > > > > > > > > Sampled metrics > > > > > > > > > > > > Metrics of which the reported values only > > > > > > apply to the value of a continuously measured or calculated > > metric > > > > > > that has been sampled at any given instance of the RTCP report > > interval. > > > > > > One example of such metric is the inter-arrival jitter > described > > in the section 6.4.1 of RFC3550. > > > > > > " > > [Qin]: One improvement to definitions of Interval Metrics, Cumulative > > Metrics and Sampled Metrics to get alignment with draft-ietf-xrblock- > > rtcp-xr-meas-identity > > since based on draft-ietf-xrblock-rtcp-xr-meas-identity, in some > > case,the measurement interval for a metric is different from the RTCP > > reporting interval, in such case, Measurement information block in > the > > draft-ietf-xrblock-rtcp-xr-meas-identity can be used to specify such > > measurement interval. > > > > The proposed improvement is described as follows: >=20 > All three definitions that follow need to use equivalent language such > that all three are clearly applicable to both direct and composed > metrics. >=20 > [Qin]:Okay. That's a good suggestion. >=20 > > " > > Interval metrics: > > > > Metrics calculated based on values measured over the course of a > single > > reporting interval. This may be the most recent RTCP reporting > interval > > ([RFC3550], section 6.2) or some other interval signalled using an > RTCP > > Measurement Information XR Block [draft-ietf-xrblock-rtcp-xr-meas- > > identity]. An example interval metric is the count of the number of > RTP > > packets lost over the course of the last RTCP reporting interval. >=20 > How about replacing "Metrics calculated based on values measured over > the course ..." with "Metrics measured over the course ..."? >=20 > [Qin]: Okay, the proposed change to the definition of Interval metrics > is described as follows: > NEW TEXT > " > Metrics measured over the course of a single reporting interval between > two successive > report blocks. This may be the most recent RTCP reporting interval > ([RFC3550], section 6.2) > or some other interval signalled using an RTCP Measurement Information > XR Block [MI]. > An example interval metric is the count of the number of RTP packets > lost over the course > of the last RTCP reporting interval. >=20 > " >=20 > > Cumulative metrics: > > > > Metrics derived from cumulative measurements taken over several > > reporting intervals. The time period over which measurements are > > accumulated can be the complete RTP session, or some other interval > > signalled using an RTCP Measurement Information XR Block [draft-ietf- > > xrblock-rtcp-xr-meas-identity]. An example cumulative metric is the > > total number of RTP packets lost since the start of the RTP session. > > >=20 > How about replacing "Metrics derived from cumulative measurements taken > over several ..." with "Metrics measured over several ..."? >=20 > [Qin]: Okay, the proposed change to the definition of Interval metrics > would be: > NEW TEXT > " > Metrics measured over several reporting intervals for accumulating > statistics. > The time period over which measurements are accumulated can be the > complete RTP session, or some other interval signalled using an RTCP > Measurement Information XR Block [MI]. An example cumulative metric > is the total number of RTP packets lost since the start of the RTP > session. >=20 > " >=20 >=20 > > Sampled metrics: > > > > Metrics that are sampled at a particular time instant within a > > reporting interval (generally the value of some measurement as taken > at > > the end of the reporting interval). An example is the inter-arrival > > jitter reported in RTCP SR and RR packets, which is continually > updated > > as each RTP data packet arrives, but only reported based on a > snapshot > > of the value which is sampled at the instant the reporting interval > > ends. > > > > " >=20 > How about replacing "Metrics that are sampled at a particular time > instant ..." with "Metrics measured at a particular time instant..."? >=20 > [Qin]: Okay, the proposed change to the definition of Interval metrics > would be: > NEW TEXT > " > Metrics measured at a particular time instant and sampled from the > values of > a continuously measured or calculated metric within a reporting > interval > (generally the value of some measurement as taken at the end of the > reporting interval). > An example is the inter-arrival jitter reported in RTCP SR and RR > packets, > which is continually updated as each RTP data packet arrives, but only > reported based > on a snapshot of the value which is sampled at the instant the > reporting interval ends. > " >=20 > This way the wording remains consistent across all three definitions > without mixing in any terms that may be confused to adding ties > specific > to direct or composed metrics. >=20 > Cheers, > Charles >=20 >=20 > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt From bill.wu@huawei.com Fri May 25 18:06:09 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C311421F87E0; Fri, 25 May 2012 18:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, MIME_BASE64_TEXT=1.753, 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 8qIrN7SI9Eb5; Fri, 25 May 2012 18:06:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C195321F87DD; Fri, 25 May 2012 18:06:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGG76292; Fri, 25 May 2012 21:06:04 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 May 2012 18:04:41 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 May 2012 18:04:47 -0700 Received: from w53375 (10.138.41.149) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 26 May 2012 09:04:45 +0800 Message-ID: <610ADD80E7FF45E78768A48B0466CC7D@china.huawei.com> From: Qin Wu To: Colin Perkins , Albrecht Schwarz References: <1337656707.85576.YahooMailNeo@web171005.mail.ukl.yahoo.com><8550925CD2F24829AC4483B12606F03A@china.huawei.com><565CA625413A4126AF25B21F2EC5F71F@china.huawei.com><1337821970.83936.YahooMailNeo@web171005.mail.ukl.yahoo.com> <1007B220-18A0-49E1-B293-FDA4B82E3698@csperkins.org> Date: Sat, 26 May 2012 09:04:43 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CD3B1E.9777A230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Subject: AD review ofdraft-ietf-avtcore-monarch-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 01:06:11 -0000 ------=_NextPart_000_006D_01CD3B1E.9777A230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T2theSxDb21iaW5pbmcgQWxicmVjaHQgYW5kIHlvdXIgbmV3IHN1Z2dlc3Rpb25zLCBub3cgSSBw cm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byB0aGUgc2VjdGlvbiAzLjM6DQoNCk5FVyBU RVhUOg0KIg0KMy4zLiBMb2NhdGlvbiBvZiBSVFAgTW9uaXRvcnMuDQoNClRoZXJlIGFyZSBzZXZl cmFsIHBvc3NpYmxlIGxvY2F0aW9ucyBmcm9tIHdoZXJlIFJUUCBzZXNzaW9ucyBjYW4gYmUgbW9u aXRvcmVkLiBUaGVzZSBpbmNsdWRlIGVuZC1zeXN0ZW1zIHRoYXQgdGVybWluYXRlIFJUUCBzZXNz aW9ucywgbWlkZGxlYm94ZXMgdGhhdCBhcmUgYW4gYWN0aXZlIHBhcnQgb2YgYW4gUlRQIHNlc3Np b24sIGFuZCB0aGlyZC1wYXJ0eSBkZXZpY2VzIHRoYXQgcGFzc2l2ZWx5IG1vbml0b3IgYW4gUlRQ IHNlc3Npb24uIE5vdCBldmVyeSBSVFAgc2Vzc2lvbnMgd2lsbCBpbmNsdWRlIG1vbml0b3Jpbmcs IGFuZCB0aG9zZSBzZXNzaW9ucyB0aGF0IGFyZSBtb25pdG9yZWQgd2lsbCBub3QgYWxsIGluY2x1 ZGUgZWFjaCB0eXBlIG9mIG1vbml0b3IuIFRoZSBwZXJmb3JtYW5jZSBtZXRyaWNzIGNvbGxlY3Rl ZCBieSBSVFAgbW9uaXRvcnMgY2FuIGJlIGRpdmlkZWQgaW50byBlbmQgc3lzdGVtIG1ldHJpY3Ms IGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MsIGFuZCB0cmFuc3BvcnQgbGV2ZWwgbWV0cmljcy4g U29tZSBvZiB0aGVzZSBtZXRyaWNzIG1heSBiZSBzcGVjaWZpYyB0byB0aGUgbWVhc3VyZW1lbnQg cG9pbnQgb2YgdGhlIFJUUCBtb25pdG9yLCBvciBkZXBlbmQgb24gd2hlcmUgdGhlIFJUUCBtb25p dG9ycyBhcmUgbG9jYXRlZCBpbiB0aGUgbmV0d29yaywgd2hpbGUgb3RoZXJzIGFyZSBtb3JlIGdl bmVyYWwgYW5kIGNhbiBiZSBjb2xsZWN0ZWQgaW4gYW55IG1vbml0b3JpbmcgbG9jYXRpb24uIA0K DQpFbmQtc3lzdGVtIG1vbml0b3JpbmcgaXMgbW9uaXRvcmluZyB0aGF0IGlzIGRlcGxveWVkIG9u IGRldmljZXMgdGhhdCB0ZXJtaW5hdGUgUlRQIGZsb3dzLiBGbG93cyBjYW4gYmUgdGVybWluYXRl ZCBpbiB1c2VyIGVxdWlwbWVudCwgc3VjaCBhcyBwaG9uZXMsIHZpZGVvIGNvbmZlcmVuY2luZyBz eXN0ZW1zLCBvciBJUFRWIHNldC10b3AgYm94ZXMuIEFsdGVybmF0aXZlbHksIHRoZXkgY2FuIGJl IHRlcm1pbmF0ZWQgaW4gZGV2aWNlcyB0aGF0IGdhdGV3YXkgYmV0d2VlbiBSVFAgYW5kIG90aGVy IHRyYW5zcG9ydCBwcm90b2NvbHMuIFRyYW5zcG9ydCBhbmQgZW5kIHN5c3RlbSBtZXRyaWNzLCBh cHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIHRoYXQgZG9uJ3QgcmVmbGVjdCBlbmQgdG8gZW5kIHVz ZXIgZXhwZXJpZW5jZSBtYXkgYmUgY29sbGVjdGVkIGF0IGFsbCB0eXBlcyBvZiBlbmQgc3lzdGVt LCBidXQgc29tZSBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIChpLmUuLHF1YWxpdHkgb2YgZXhw ZXJpZW5jZSBtZXRyaWNzKSBtYXkgb25seSBiZSBhcHBsaWNhYmxlIGZvciB1c2VyLWZhY2luZyBl bmQgc3lzdGVtcy4NCg0KUlRQIHNlc3Npb25zIGNhbiBpbmNsdWRlIG1pZGRsZWJveGVzIHRoYXQg YXJlIGFuIGFjdGl2ZSBwYXJ0IG9mIHRoZSBzeXN0ZW0uIFRoZXNlIG1pZGRsZWJveGVzIGluY2x1 ZGUgUlRQIG1peGVycyBhbmQgdHJhbnNsYXRvcnMsIE1DVXMsIHJldHJhbnNtaXNzaW9uIHNlcnZl cnMsIGV0Yy4gSWYgdGhlIG1pZGRsZWJveCBlc3RhYmxpc2hlcyBzZXBhcmF0ZSBSVFAgc2Vzc2lv bnMgdG8gdGhlIG90aGVyIHBhcnRpY2lwYW50cywgdGhlbiBpdCBtdXN0IGFjdCBhcyBhbiBlbmQg c3lzdGVtIGluIGVhY2ggb2YgdGhvc2Ugc2VwYXJhdGUgUlRQIHNlc3Npb25zIGZvciB0aGUgcHVy cG9zZXMgb2YgbW9uaXRvcmluZy4gSWYgYSBzaW5nbGUgUlRQIHNlc3Npb24gdHJhdmVyc2VzIHRo ZSBtaWRkbGVib3gsIHRoZW4gdGhlIG1pZGRsZWJveCBjYW4gYmUgYXNzaWduZWQgYW4gU1NSQyBp biB0aGF0IHNlc3Npb24gd2hpY2ggaXQgY2FuIHVzZSBmb3IgaXQncyByZXBvcnRzLiBUcmFuc3Bv cnQgbGV2ZWwgbWV0cmljcyBtYXkgYmUgY29sbGVjdGVkIGF0IHN1Y2ggbWlkZGxlYm94Lg0KDQpU aGlyZC1wYXJ0eSBtb25pdG9ycyBtYXkgYmUgZGVwbG95ZWQgdGhhdCBwYXNzaXZlbHkgbW9uaXRv ciBSVFAgc2Vzc2lvbnMgZm9yIG5ldHdvcmsgbWFuYWdlbWVudCBwdXJwb3Nlcy4gVGhpcmQtcGFy dHkgbW9uaXRvcnMgb2Z0ZW4gZG8gbm90IHNlbmQgcmVwb3J0cyBpbnRvIHRoZSBSVFAgc2Vzc2lv biBiZWluZyBtb25pdG9yZWQsIGJ1dCBpbnN0ZWFkIGNvbGxlY3QgdHJhbnNwb3J0IGFuZCBlbmQg c3lzdGVtIG1ldHJpY3MsIGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgdGhhdCBhcmUgcmVwb3J0 ZWQgdmlhIHNvbWUgbmV0d29yayBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uLiBJbiBzb21lIGNhc2Vz LCBob3dldmVyLCB0aGlyZC1wYXJ0eSBtb25pdG9ycyBjYW4gc2VuZCByZXBvcnRzIHRvIHNvbWUg b3IgYWxsIHBhcnRpY2lwYW50cyBpbiB0aGUgc2Vzc2lvbiBiZWluZyBtb25pdG9yZWQuIEZvciBl eGFtcGxlLCBpbiBhIG1lZGlhIHN0cmVhbWluZyBzY2VuYXJpbywgdGhpcmQtcGFydHkgbW9uaXRv cnMgbWF5IGJlIGRlcGxveWVkIHRoYXQgcGFzc2l2ZWx5IG1vbml0b3IgdGhlIHNlc3Npb24gYW5k IHNlbmQgcmVjZXB0aW9uIHF1YWxpdHkgcmVwb3J0cyB0byB0aGUgbWVkaWEgc291cmNlLCBidXQg bm90IHRvIHRoZSByZWNlaXZlcnMuDQoNCiINCg0KUmVnYXJkcyENCi1RaW4NCiAgLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogQ29saW4gUGVya2lucyANCiAgVG86IEFsYnJl Y2h0IFNjaHdhcnogDQogIENjOiB4cmJsb2NrQGlldGYub3JnIDsgYXZ0QGlldGYub3JnIA0KICBT ZW50OiBGcmlkYXksIE1heSAyNSwgMjAxMiAxMjozOSBBTQ0KICBTdWJqZWN0OiBSZTogW3hyYmxv Y2tdIFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2ZkcmFmdC1pZXRmLWF2dGNvcmUtbW9u YXJjaC0xMw0KDQoNCiAgQWxicmVjaHQsDQoNCg0KICBBZ3JlZWQgLSB0aGF0IHNlZW1zIGxpa2Ug YSB1c2VmdWwgZGlzdGluY3Rpb24uDQogIENvbGluDQoNCg0KDQoNCiAgT24gMjQgTWF5IDIwMTIs IGF0IDAyOjEyLCBBbGJyZWNodCBTY2h3YXJ6IHdyb3RlOg0KDQoNCiAgICBJIHdvdWxkIHN1cHBv cnQgdGhhdCBkaXJlY3Rpb24gYW5kIHN0cnVjdHVyaW5nIHByb3Bvc2FsLg0KDQoNCiAgICBTaWRl IGNvbW1lbnQgdG8gdGhlIG5vdGlvbiBvZiAiZW5kIHN5c3RlbSBtZXRyaWMiOg0KICAgIFdlIHNo b3VsZCBiZSBjYXJlZnVsbHkgYmVjYXVzZSBpdCBjb3VsZCBiZSBpbnRlcnByZXRhdGVkIGluIHR3 byBkaXJlY3Rpb25zOg0KICAgIGEpIG1ldHJpYyByZWxhdGVkIHRvIFJUUCB0b3BvbG9neSAiUlRQ IGVuZCBzeXN0ZW0iDQogICAgYikgbWV0cmljIHJlbGF0ZWQgdG8gdXNlciBlcXVpcG1lbnQNCg0K DQogICAgVGhlcmUncyBhIHN1YnRsZSBkaWZmZXJlbmNlIGJldHdlZW4gYm90aCwgdGhlICJSVFAg ZW5kIHN5c3RlbSIgRlVOQ1RJT04gY291bGQgYmUgbG9jYXRlZCBpbiBtdWx0aXBsZSBkaWZmZXJl bnQgcGh5c2ljYWwgZW50aXRpZXMgbGlrZSB1c2VyIGVxdWlwbWVudCwgYnV0IGFsc28gUlRQLXRv LVggZ2F0ZXdheSBlcXVpcG1lbnQuIFRoZSBsYXRlciBvbmVzIGFyZSBub3QgbG9jYXRlZCBhdCB0 aGUgZW5kIG9mIHRoZSBvdmVyYWxsIGNvbW11bmljYXRpb24gcGF0aC4NCiAgICBDb25jbHVzaW9u IGZvciB0aGlzIGV4YW1wbGU6IGUuZy4gUW9FIG1ldHJpY3MgKGFzIGFwcGxpY2F0aW9uIGxldmVs IG1ldHJpY3MpIG1pZ2h0IGJlIG1vbml0b3JlZCBpbiBhbiAiUlRQIGVuZCBzeXN0ZW0iIHdoZW4g bG9jYXRlZCBpbiB1c2VyIGVxdWlwbWVudCwgYnV0IG5vdCBpZiAiUlRQIGVuZCBzeXN0ZW0iIHdv dWxkIGJlIGxvY2F0ZWQgaW4gbmV0d29yayBsZXZlbCBlcXVpcG1lbnQuIENvbnNlcXVlbnRseSwg dGhlIGFzc29jaWF0aW9uIG9mIFFvRSBtZXRyaWNzIGFzICJlbmQgc3lzdGVtIG1ldHJpY3MiIHdv dWxkIGJlIGFtYmlndW91cy4NCg0KDQogICAgTXkgZmVlbGluZzoNCiAgICB3ZSBkb24ndCBuZWVk IG5lY2Vzc2FyaWx5IHRoZSBjb25jZXB0IG9mIGFuICJlbmQgc3lzdGVtIG1ldHJpYyIsIGJ1dCB3 ZSBuZWVkIGEgbG9jYXRpb24gY29uY2VwdCBmb3IgUlRQIG1vbml0b3JzIHdpdGggcmVzcGVjdCB0 byB0aGUgdG9wb2xvZ3kgb2YgdGhlIGVuZC10by1lbmQgY29tbXVuaWNhdGlvbiBwYXRoICgid2hp Y2ggYWdhaW4gbWlnaHQgYmUgY29tcGxldGVseSBlMmUgUlRQIGJhc2VkIG9yIHNvbWUgc2VnbWVu dHMgbWlnaHQgYmUgbm9uLVJUUCAuLi4iKS4NCg0KDQogICAgLUFsYnJlY2h0DQoNCg0KDQoNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgVm9uOiBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJr aW5zLm9yZz4NCiAgICAgIEFuOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4gDQogICAgICBD QzogQWxicmVjaHQgU2Nod2FyeiA8YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPjsgYXZ0QGlldGYu b3JnOyB4cmJsb2NrQGlldGYub3JnIA0KICAgICAgR2VzZW5kZXQ6IDIzOjIxIE1pdHR3b2NoLCAy My5NYWkgMjAxMg0KICAgICAgQmV0cmVmZjogUmU6IFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMNCg0KDQogICAgICBRaW4sDQoNCiAg ICAgIFRoZSB0ZXh0IHlvdSBwcm9wb3NlIGlzIGJldHRlciwgYnV0IEknbSBzdGlsbCBub3Qgc3Vy ZSBpdCdzIGNsZWFyLiBJIHdvbmRlciBpZiBpdCBtYXkgYmUgd29ydGggc3BsaXR0aW5nIHRoYXQg c2VjdGlvbiBpbnRvIHNldmVyYWwgcGFyYWdyYXBocywgYW5kIGdpdmluZyBhIGxpdHRsZSBtb3Jl IGRlc2NyaXB0aW9uLiBPbmUgcGFyYWdyYXBoIGNvdWxkIGRpc2N1c3MgdGhlIHBvc3NpYmxlIGxv Y2F0aW9ucyBmb3IgbW9uaXRvcnM6IGluIGVuZC1zeXN0ZW1zLCBpbiBtaWRkbGVib3hlcyB0aGF0 IGFyZSBhbiBhY3RpdmUgcGFydCBvZiBhbiBSVFAgc2Vzc2lvbiAoZS5nLiwgUlRQIG1peGVycyBv ciB0cmFuc2xhdG9ycyksIG9yIGluIHRoaXJkLXBhcnR5IGRldmljZXMgdGhhdCBwYXNzaXZlbHkg bW9uaXRvciBhbiBSVFAgc2Vzc2lvbi4gRm9yIGVhY2ggb2YgdGhlc2UgbG9jYXRpb25zLCB5b3Ug Y291bGQgdGhlbiBpbmNsdWRlIGEgcGFyYWdyYXBoIHRoYXQgYnJpZWZseSBleHBsYWlucyB0aGUg dXNlcyBmb3IgbW9uaXRvcnMgaW4gdGhhdCBsb2NhdGlvbiwgYW5kIHRoZSB0eXBlcyBvZiBtZXRy aWNzIHRoZXkncmUgc3VpdGVkIHRvIG1vbml0b3JpbmcsIHBlcmhhcHMgd2l0aCBleGFtcGxlcy4g DQoNCiAgICAgIENvbGluDQoNCg0KDQoNCiAgICAgIE9uIDIzIE1heSAyMDEyLCBhdCAwNDoyMiwg UWluIFd1IHdyb3RlOg0KICAgICAgPiBIaSwNCiAgICAgID4gVGFrZSBSb2JlcnQsQ29saW4gYW5k IEFsYnJlY2hldCdzIGNvbW1lbnRzIGludG8gYWNjb3VudCwgSSBwcm9wb3NlIHRvIHJld3JpdGUg c2VjdGlvbiAzLjMgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQogICAgICA+IE9MRCBURVhU Og0KICAgICAgPiAiDQogICAgICA+IDMuMy4gIFJUUCBTZW5kZXIvUmVjZWl2ZXIgZW50aXRpZXMg bG9jYXRlZCBpbiBuZXR3b3JrIG5vZGVzDQogICAgICA+IA0KICAgICAgPiAgVGhlIGxvY2F0aW9u IG9mIHRoZSBSVFAgU2VuZGVyL1JlY2VpdmVyIGVudGl0aWVzIG1heSBpbXBhY3QgYSBzZXQgb2YN CiAgICAgID4gIG1lYW5pbmdmdWwgbWV0cmljcy4gIEZvciBpbnN0YW5jZSwgYXBwbGljYXRpb24g bGV2ZWwgbWV0cmljcyBmb3IgUW9FDQogICAgICA+ICByZWxhdGVkIHBlcmZvcm1hbmNlIHBhcmFt ZXRlcnMgYXJlIHVuZGVyIG1vc3QgY29uZGl0aW9ucyBtZWFzdXJlZCBhdA0KICAgICAgPiAgdGhl IHVzZXIgZGV2aWNlIHRoYXQgcmVjZWl2ZXMgUlRQIGRhdGEgcGFja2V0cy4gIEhvd2V2ZXIgaW4g c29tZQ0KICAgICAgPiAgY2FzZXMsIGdpdmVuIHRoZSBmYWN0b3JzICggIm1lYXN1cmVtZW50IHBv aW50IGxvY2F0aW9uIiwgIm1lYXN1cmVtZW50DQogICAgICA+ICBtb2RlbCBsb2NhdGlvbiIsICJh d2FyZW5lc3Mgb2YgY29udGVudCBpbmZvcm1hdGlvbiIsIGV0YyBbUC5OQU1TXSkNCiAgICAgID4g IHRha2VuIGludG8gYWNjb3VudCwgc3VjaCBtZXRyaWNzIG1heSBiZSBtZWFzdXJlZCBpbiBhIG5l dHdvcmsgbm9kZQ0KICAgICAgPiAgaW5zdGVhZCBvZiBhIHVzZXIgZGV2aWNlLg0KICAgICAgPiAN CiAgICAgID4gIg0KICAgICAgPiBORVcgVEVYVDoNCiAgICAgID4gIg0KICAgICAgPiAzLjMuIE1l YXN1cmVtZW50IHBvaW50IG9mIHRoZSBSVFAgbW9uaXRvciB3aXRoaW4gdGhlIG5ldHdvcmsuDQog ICAgICA+IA0KICAgICAgPiBUaGUgUlRQIG1vbml0b3JzIGFyZSBzcHJlYWQgYWNyb3NzIGEgc2lu Z2xlIGRvbWFpbihlLmcuLCBuZXR3b3JrICBkb21haW4pIG9yIA0KICAgICAgPiBtdWx0aXBsZSBk b21haW5zIChlLmcuLCBiZXR3ZWVuIG5ldHdvcmsgZG9tYWluIGFuZCBzZXJ2aWNlIGRvbWFpbilp biB0aGUgbmV0d29yay4NCiAgICAgID4gVGhlIHBlcmZvcm1hbmNlIE1ldHJpY3MgcmVwb3J0ZWQg ZnJvbSB0aGUgUlRQIG1vbml0b3IgY2FuIGJlIGRpdmlkZWQgaW50byBlbmQgc3lzdGVtIA0KICAg ICAgPiBtZXRyaWNzLCBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzLCB0cmFuc3BvcnQgbGV2ZWwg bWV0cmljcy4gU29tZSBvZiB0aGVzZSBtZXRyaWNzIA0KICAgICAgPiBtYXkgYmUgc3BlY2lmaWMg dG8gdGhlIG1lYXN1cmVtZW50IHBvaW50IG9mIHRoZSBSVFAgbW9uaXRvciBvciBkZXBlbmQgb24g d2hlcmUgDQogICAgICA+IHRoZSBSVFAgbW9uaXRvcnMgYXJlIGxvY2F0ZWQgaW4gdGhlIG5ldHdv cmsuIEZvciBpbnN0YW5jZSwgZW5kIHN5c3RlbSBtZXRyaWNzIGFyZSBvbmx5DQogICAgICA+IGF2 YWlsYWJsZSBvciBtZWFzdXJlZCBhdCB0aGUgUlRQIGVuZCBzeXN0ZW0gb3IgdGVybWluYWwgZGV2 aWNlLiBBcHBsaWNhdGlvbiBsZXZlbA0KICAgICAgPiBtZXRyaWNzIHRoYXQgcmVmbGVjdCBlbmQg dG8gZW5kIHVzZXIgZXhwZXJpZW5jZSBhdCB0aGUgYXBwbGljYXRpb24tbGV2ZWwgYXJlIG1lYXN1 cmVkIA0KICAgICAgPiBtb3JlIHByZWNpc2Ugb3IgbGVzcyBjb21wbGljYXRlZCBhdCB0aGUgUlRQ IGVuZCBzeXN0ZW0gdGhhbiBtZWFzdXJlZCBmcm9tIGludGVybWVkaWFyeSANCiAgICAgID4gc3lz dGVtIChlLmcuLCB0aGUgUlRQIG1lZGlhIHRyYW5zbGF0b3IpIGluIHRoZSBuZXdvcmsuIEZvciB0 cmFuc3BvcnQgbGV2ZWwgbWV0cmljcywgdGFrZXMNCiAgICAgID4gb25lIHdheSBkZWxheSBhcyBh biBleGFtcGxlLCBpbiB0aGUgYXN5bW1ldHJpYyBuZXR3b3JrLCB0aGUgb25lIHdheSBkZWxheSBt ZWFzdXJlZCANCiAgICAgID4gYXQgdGhlIFJUUCBzZW5kZXIgZW50aXR5IGlzIGRpZmZlcmVudCBm cm9tIG9uZSB3YXkgZGVsYXkgbWVhc3VyZWQgYXQgdGhlIFJUUCANCiAgICAgID4gcmVjZWl2ZXIg ZW50aXR5LiANCiAgICAgID4gIg0KICAgICAgPiANCiAgICAgID4gUmVnYXJkcyENCiAgICAgID4g LVFpbg0KICAgICAgPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICAgICAgPiBGcm9t OiAiQ29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPg0KICAgICAgPiBUbzogIlFpbiBX dSIgPGJpbGwud3VAaHVhd2VpLmNvbT4NCiAgICAgID4gQ2M6ICJBbGJyZWNodCBTY2h3YXJ6IiA8 YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPjsgPGF2dEBpZXRmLm9yZz4NCiAgICAgID4gU2VudDog VHVlc2RheSwgTWF5IDIyLCAyMDEyIDc6MDQgUE0NCiAgICAgID4gU3ViamVjdDogUmU6IFtBVlRD T1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMN CiAgICAgID4gDQogICAgICA+IA0KICAgICAgPiBJIGFsc28gZG9uJ3QgYWdyZWUgd2l0aCBkZWxl dGluZyBTZWN0aW9uIDMuMyBmcm9tIHRoZSBtb25hcmNoIGRyYWZ0LiANCiAgICAgID4gDQogICAg ICA+IFRoZSBhcmNoaXRlY3R1cmUgbmVlZHMgdG8gYmUgY2xlYXIgdGhhdCB0aGVyZSBhcmUgdmFs aWQgc2NlbmFyaW9zIGZvciBSVFAgbW9uaXRvcmluZyB3aXRoaW4gYSBuZXR3b3JrLCBlaXRoZXIg aW4gc29tZSBtaWRkbGVib3ggdGhhdCBjb21wcmlzZXMgcGFydCBvZiBhbiBSVFAgc2Vzc2lvbiwg b3IgaW4gYSB0aGlyZC1wYXJ0eSBtb25pdG9yaW5nIGRldmljZSB1c2VkIGZvciBuZXR3b3JrIG1h bmFnZW1lbnQgcHVycG9zZXMuIFNlY3Rpb24gMy4zIGlzIGEgcmVhc29uYWJsZSBwbGFjZSB0byBk aXNjdXNzIHRoZXNlLCBhbmQgdG8gZXhwbGFpbiB3aHkgdGhlIG1ldHJpY3MgdGhhdCBjYW4gYmUg cmVwb3J0ZWQgZnJvbSBtaWRkbGVib3hlcyBhcmUgZGlmZmVyZW50IHRvIHRob3NlIHRoYXQgY2Fu IGJlIGNhcHR1cmVkIGF0IGVuZCBzeXN0ZW1zLg0KICAgICAgPiANCiAgICAgID4gQ29saW4NCiAg ICAgID4gDQogICAgICA+IA0KICAgICAgPiANCiAgICAgID4gT24gMjIgTWF5IDIwMTIsIGF0IDA3 OjUzLCBRaW4gV3Ugd3JvdGU6DQogICAgICA+PiBIaSw6DQogICAgICA+PiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KICAgICAgPj4gRnJvbTogIkFsYnJlY2h0IFNjaHdhcnoiIDxhbGJy ZWNodHNjaHdhcnpAeWFob28uZGU+DQogICAgICA+PiBUbzogPGJpbGwud3VAaHVhd2VpLmNvbT4N CiAgICAgID4+IENjOiA8YXZ0QGlldGYub3JnPjsgPHJqc3BhcmtzQG5vc3RydW0uY29tPg0KICAg ICAgPj4gU2VudDogVHVlc2RheSwgTWF5IDIyLCAyMDEyIDExOjE4IEFNDQogICAgICA+PiBTdWJq ZWN0OiBSZTogW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNv cmUtbW9uYXJjaC0xMw0KICAgICAgPj4gDQogICAgICA+PiANCiAgICAgID4+IERlYXIgQWxsLA0K ICAgICAgPj4gDQogICAgICA+PiBjb25jZXJuaW5nIHRoZSByZXNvbHV0aW9uIHByb3Bvc2FsIGZv ciBjbGF1c2UgMy4zOg0KICAgICAgPj4gSSBkb24ndCBhZ3JlZSBpbiBqdXN0IGRlbGV0aW5nIGFn YWluIHRoYXQgc2VjdGlvbiENCiAgICAgID4+IFRoZXJlIHdhcyBxdWl0ZSBhIGxvbmcgZGViYXRl IGZvciBpbmNvcnBvcmF0aW5nIHN1Y2ggYSBjbGF1c2UuDQogICAgICA+PiBUaGUgb3JpZ2luYWwg dGV4dCBwcm9wb3NhbCB3YXMgbXVjaCBtb3JlIGRldGFpbGVkLiBQZXJoYXBzIHRoZSBzaG9ydGVu aW5nIHRvIGp1c3QgYSBzaW5nbGUgcGFyYWdyYXBoIGlzIHRoZSBtYWluIGNhdXNlIGZvciB1bmNs YXJpdHkuDQogICAgICA+PiBUaHVzLCBpbnN0ZWFkIG9mIHJlbW92aW5nIHByZXZpb3VzIGFncmVl ZCB0ZXh0LCB3ZSBqdXN0IHJhdGhlciBleHRlbmQgaXQgYWdhaW4uDQogICAgICA+PiANCiAgICAg ID4+IA0KICAgICAgPj4gW1Fpbl06IA0KICAgICAgPj4gVGhlIHJlYXNvbiBJIHByb3Bvc2UgdG8g cmVtb3ZlIHRoZSBzZWN0aW9uIDMuMyBpcyANCiAgICAgID4+IGEuIEkgdGhpbmsgUm9iZXJ0IGlz IGNvcnJlY3QuIFRoZSBzZXQgb2YgbWVhbmluZ2Z1bCBtZXRyaWNzIGlzbid0IGNoYW5nZWQgYXQg YWxsICB3aGVyZXZlciB5b3UgY29sbGVjdCB0aGVtLiBJdCBzZWVtcyBsaXR0bGUgc2Vuc2UgDQog ICAgICA+PiAgdG8gc2F5ICJ0aGUgbG9jYXRpb24gb2YgdGhlIFJUUCBTZW5kZXIvUmVjZWl2ZXIg ZW50aXRpZXMgbWF5IGltcGFjdCBhIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MuICIgDQogICAg ICA+PiBiLiBXaGVyZSB0byBnYXRoZXIgb3IgbWVhc3VyZSBtZXRyaWNzIGNhbiBiZSBpbmRpY2F0 ZWQgYnkgdGhlIGRlZmluaXRpb24gb2YgVHJhbnNwb3J0IG1ldHJpY3MsIEVuZCBzeXN0ZW0gbWV0 cmljcyBhbmQgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcy4NCiAgICAgID4+IGMuIFNlY3Rpb24g My4zIHNlZW1zIHRvIGRpc2N1c3Mgd2hlcmUgdG8gZ2F0aGVyIHdoYXQgbWV0cmljcy4gUmVjb21t ZW5kYXRpb24gSVRVLVQgRy4xMDgxIGhhdmUgYWxyZWFkeSBkZWZpbmVkIGZpdmUgbW9uaXRvcmlu ZyBwb2ludHMgDQogICAgICA+PiAgd2hlcmUgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50cyBj YW4gYmUgbWFkZS4NCiAgICAgID4+IA0KICAgICAgPj4+IEkgdGhpbmsgdGhlIGRlZmluaXRpb24g b2YgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcyBoYXMgYWxyZWFkeSBjbGFyaWZpZWQgdGhhdCAg YXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcyBpcyBub3JtYWxseSBnYXRoZXJlZCBmcm9tIHVzZXIg ZW5kcG9pbnQuIA0KICAgICAgPj4gDQogICAgICA+PiBOby4gV2UgZGlkIGRpc2N1c3MgdGhpcyBh bHJlYWR5IGV4dGVuc2l2ZWx5Lg0KICAgICAgPj4gQW4gUlRQIG1lZGlhIHRyYW5zbGF0b3IgY291 bGQgcHJvdmlkZSBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGJlY2F1c2UgZS5nLiB0ZXJtaW5h dGluZyB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wgbGF5ZXIuDQogICAgICA+PiBTdWNoIGFuIFJU UCB0b3BvbG9neSBpcyBOT1QgbG9jYXRlZCBpbiBhbiB1c2VyIGVuZHBvaW50IQ0KICAgICAgPj4g DQogICAgICA+PiBbUWluXTogU29ycnksIEkgc2hvdWxkIGNvcnJlY3QgbWUgdG8gc2F5IFFvRSBt ZXRyaWMgaXMgdXN1c2FsbHkgbWVhc3VyZWQgYXQgdGhlIHVzZXIgZW5kcG9pbnQuDQogICAgICA+ PiANCiAgICAgID4+IFJlZ2FyZHMsDQogICAgICA+PiBBbGJyZWNodA0KICAgICAgPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgID4+IFtEYXRlIFByZXZdW0RhdGUgTmV4 dF1bVGhyZWFkIFByZXZdW1RocmVhZCBOZXh0XVtEYXRlIEluZGV4XVtUaHJlYWQgSW5kZXhdIA0K ICAgICAgPj4gUmU6IFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1h dnRjb3JlLW1vbmFyY2gtMTMNCiAgICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgICA+PiANCiAgICAgID4+ICogVG86IFJvYmVydCBTcGFya3MgPHJqc3BhcmtzIGF0 IG5vc3RydW0uY29tPiwgSUVURiBBVlRDb3JlIFdHIDxhdnQgYXQgaWV0Zi5vcmc+LCA8ZHJhZnQt aWV0Zi1hdnRjb3JlLW1vbmFyY2ggYXQgdG9vbHMuaWV0Zi5vcmc+DQogICAgICA+PiAqIFN1Ympl Y3Q6IFJlOiBbQVZUQ09SRV0gU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29y ZS1tb25hcmNoLTEzDQogICAgICA+PiAqIEZyb206IFFpbiBXdSA8YmlsbC53dSBhdCBodWF3ZWku Y29tPg0KICAgICAgPj4gKiBEYXRlOiBGcmksIDE4IE1heSAyMDEyIDE4OjM3OjU2ICswODAwDQog ICAgICA+PiAqIERlbGl2ZXJlZC10bzogYXZ0IGF0IGlldGZhLmFtc2wuY29tDQogICAgICA+PiAq IExpc3QtYXJjaGl2ZTogPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hdnQ+ DQogICAgICA+PiAqIExpc3QtaGVscDogPG1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZz9zdWJq ZWN0PWhlbHA+DQogICAgICA+PiAqIExpc3QtaWQ6IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3Jl IE1haW50ZW5hbmNlIDxhdnQuaWV0Zi5vcmc+DQogICAgICA+PiAqIExpc3QtcG9zdDogPG1haWx0 bzphdnRAaWV0Zi5vcmc+DQogICAgICA+PiAqIExpc3Qtc3Vic2NyaWJlOiA8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ+LCA8bWFpbHRvOmF2dC1yZXF1ZXN0QGlldGYu b3JnP3N1YmplY3Q9c3Vic2NyaWJlPg0KICAgICAgPj4gKiBMaXN0LXVuc3Vic2NyaWJlOiA8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9vcHRpb25zL2F2dD4sIDxtYWlsdG86YXZ0LXJlcXVl c3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZT4NCiAgICAgID4+ICogUmVmZXJlbmNlczog PDRGQjJFMzIzLjMwOTA0MDYgYXQgbm9zdHJ1bS5jb20+DQogICAgICA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgICAgPj4gDQogICAgICA+PiBIaSxSb2JlcnQ6DQogICAg ICA+PiBUaGFuayBmb3IgeW91ciB2YWx1YWJsZSByZXZpZXcuIHBsZWFzZSBzZWUgbXkgcmVwbGll cyBpbmxpbmUgYmVsb3dzLiBSZWdhcmRzIQ0KICAgICAgPj4gLVFpbg0KICAgICAgPj4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICAgID4+IEZyb206ICJSb2JlcnQgU3BhcmtzIiA8 cmpzcGFya3MgYXQgbm9zdHJ1bS5jb20+DQogICAgICA+PiBUbzogIklFVEYgQVZUQ29yZSBXRyIg PGF2dCBhdCBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhdCB0b29scy5p ZXRmLm9yZz4NCiAgICAgID4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDEyIDc6MTMgQU0N CiAgICAgID4+IFN1YmplY3Q6IFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMgPiBTdW1tYXJ5OiBUaGVyZSBhcmUgaXNzdWVzIHRvIHJl c29sdmUgd2l0aCBhIHJldmlzZWQgSUQgYmVmb3JlIA0KICAgICAgPj4+IHByb2dyZXNzaW5nIHRv IElFVEYgTEMuDQogICAgICA+Pj4gDQogICAgICA+Pj4gSXQncyBhIHN0cnVnZ2xlIHRvIHNlZSB0 aGUgX2FyY2hpdGVjdHVyZV8gdGhpcyBkb2N1bWVudCBpcyBzdXBwb3NlZCB0byANCiAgICAgID4+ PiBkZXNjcmliZS4gSSBzdXNwZWN0IG1vc3Qgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgZW5lcmd5IHdl bnQgaW50byBTZWN0aW9uIDUgDQogICAgICA+Pj4gKHRoZSBndWlkZWxpbmVzIGZvciB3cml0aW5n IFhSIGJsb2NrIGRlZmluaXRpb25zKSAtIHRoZSByZXN0IG9mIHRoZSANCiAgICAgID4+PiBkb2N1 bWVudCBuZWVkcyBhIHNpbWlsYXIgbGV2ZWwgb2YgYXR0ZW50aW9uIHRvIGRldGFpbC4NCiAgICAg ID4+PiANCiAgICAgID4+PiBUaGVyZSBhcmUgdHdvIG1ham9yIGlzc3VlcyB0aGF0IEkndmUgdGFn Z2VkIHdpdGggYSAoKikuIEkgZm9sbG93ZWQgYSANCiAgICAgID4+PiBtb3N0bHkgZG9jdW1lbnQt b3JkZXIgZmxvdyBpbnN0ZWFkIG9mIGdyb3VwaW5nIHRoZSBtYWpvciBpc3N1ZXMgYXQgdGhlIHRv cC4NCiAgICAgID4+PiANCiAgICAgID4+PiAoKikgR2l2ZW4gdGhlIGRvY3VtZW50J3MgdGl0bGUs IGl0IHNob3VsZCBiZSB2ZXJ5IGVhc3kgdG8gYW5zd2VyICJXaGF0IA0KICAgICAgPj4+IGlzIHRo ZSBtb25pdG9yaW5nIGFyY2hpdGVjdHVyZT8iIGZvciBwZW9wbGUgd2hvIGFyZSByZWFkaW5nIHRo aXMgZHJhZnQgDQogICAgICA+Pj4gZm9yIHRoZSBmaXJzdCB0aW1lLg0KICAgICAgPj4+IFRoZSBr ZXkgbWVzc2FnZSBpcyB0aGF0IHRoZSBtb25pdG9yaW5nIGFyY2hpdGVjdHVyZSBjb25zaXN0cyBv ZiBNb25pdG9ycyANCiAgICAgID4+PiB0aGF0IGV4Y2hhbmdlIGluZm9ybWF0aW9uIHVzaW5nIFJU Q1AgTWV0cmljIEJsb2Nrcy4gW1Fpbl06IEFncmVlLiA+VGhlIHRleHQgc2hvdWxkIHNheSANCiAg ICAgID4+PiB0aGF0LiBbUWluXTogT2theS4gPiBUaGVyZSBpcyBhIGxvdCBvZiBwcm9zZSBpbiBz ZWN0aW9uIDMgYW5kIHZpc3VhbCBkZXRhaWwgaW4gdGhlIA0KICAgICAgPj4+IGRpYWdyYW0gaW4g RmlndXJlIDEgdGhhdCBtYWtlcyB0aGF0IGV4dHJlbWVseSBkaWZmaWN1bHQgdG8gc2VlLiANCiAg ICAgID4+PiBTaW1wbGlmeWluZyB0aGUgZmlndXJlIGJ5IHJlbW92aW5nIHRoZSBkZXRhaWxzIGFi b3V0IGFwcGxpY2F0aW9ucyBhbmQgDQogICAgICA+Pj4gdHJhbnNwb3J0cywgb3IgYXQgbGVhc3Qg bW92aW5nIHRoZW0gdG8gYSBzZWNvbmQgZmlndXJlLCBtYWtpbmcgdGhlIA0KICAgICAgPj4+IE1v bml0b3IgYm94ZXMgc3RhbmQgb3V0LCBhbmQgbWFraW5nIHRoZSB0eXBlcyBvZiBpbmZvcm1hdGlv biBmbG93cyAodGhlIA0KICAgICAgPj4+IGFycm93cykgdmlzdWFsbHkgZGlzdGluY3RpdmUgd291 bGQgaGVscC4gU2ltcGxpZnkgdGhlIHByb3NlIChtdWNoIG9mIGl0IA0KICAgICAgPj4+IGNvdWxk IGJlIHJlbW92ZWQpIHRvIGZvY3VzIG9uIHRoYXQga2V5IG1lc3NhZ2UuIFtRaW5dOiBBZ3JlZSwg SSBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgZmlndXJlIDEgYW5kIHNxdWVlemUgdGhlIHNlY3Rpb24g My4xIGFzIGZvbGxvd3M6ICIgMy4xLiBPdmVydmlldyBUaGUgUlRQIG1vbml0b3JpbmcgYXJjaGl0 ZWN0dXJlIGNvbXByaXNlcyB0aGUgZm9sbG93aW5nIHR3byBrZXkgZnVuY3Rpb25hbCBjb21wb25l bnRzIHNob3duIGJlbG93OiBvIFJUUCBNb25pdG9yIG8gUlRQIE1ldHJpYyBCbG9jayBTdHJ1Y3R1 cmUgUlRQIE1vbml0b3IgaXMgdGhlIGZ1bmN0aW9uYWwgY29tcG9uZW50IGRlZmluZWQgaW4gdGhl IFJlYWwtdGltZSBUcmFuc3BvcnQgUHJvdG9jb2wgW1JGQzM1NTBdLiBJdCBhY3RzIGFzIGEgc291 cmNlIG9mIGluZm9ybWF0aW9uIGdhdGhlcmVkIGZvciBtb25pdG9yaW5nIHB1cnBvc2VzIGFuZCBl eGNoYW5nZXMgaW5mb3JtYXRpb24gd2l0aCB0aGUgb3RoZXIgUlRQIG1vbml0b3JzIHVzaW5nIFJU Q1AgTWV0cmljIEJsb2Nrcy4gQWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0aW9uIG9mIG1vbml0b3Ig aW4gdGhlIFJUUCBQcm90b2NvbCBbUkZDMzU1MF0sIHRoZSBlbmQgc3lzdGVtIHRoYXQgcnVucyBh biBhcHBsaWNhdGlvbiBwcm9ncmFtIHRoYXQgc2VuZHMgb3IgcmVjZWl2ZXMgUlRQIGRhdGEgcGFj a2V0cywgYW4gaW50ZXJtZWRpYXRlLSBzeXN0ZW0gdGhhdCBmb3J3YXJkcyBSVFAgcGFja2V0cyB0 byBFbmQtZGV2aWNlcyBvciBhIHRoaXJkIHBhcnR5IHRoYXQgb2JzZXJ2ZXMgdGhlIFJUUCBhbmQg UlRDUCB0cmFmZmljIGJ1dCBkb2VzIG5vdCBtYWtlIGl0c2VsZiB2aXNpYmxlIHRvIHRoZSBSVFAg U2Vzc2lvbiBwYXJ0aWNpcGFudHMgKGkuZS4sIHRoZSB0aGlyZCBwYXJ0eSBtb25pdG9yIGRlcGlj dGVkIGluIGZpZ3VyZSAxKSBjYW4gYWN0IGFzIHRoZQ0KICAgICAgPj4gUlRQIG1vbml0b3IuIFRo ZSB0aGlyZCBwYXJ0eSBtb25pdG9yIHNob3VsZCBiZSBwbGFjZWQgb24gdGhlIFJUUC9SVENQIHBh dGhzIGJldHdlZW4gdGhlIHNlbmRlciwgaW50ZXJtZWRpYXRlIGFuZCB0aGUgcmVjZWl2ZXIuIFRo ZSBSVFAgbW9uaXRvciBhbHNvIGV4cG9zZXMgcmVhbCB0aW1lIEFwcGxpY2F0aW9uIFFvUy9Rb0Ug bWV0cmljIGluZm9ybWF0aW9uIGluIHRoZSBhcHByb3ByaWF0ZSByZXBvcnQgYmxvY2sgZm9ybWF0 IChlLmcuLFJUQ1AgWFIgb3Igb3RoZSBub24tUlRQIG1lYW5zKSB0byB0aGUgbWFuYWdlbWVudCBz eXN0ZW0uIFN1Y2ggaW5mb3JtYXRpb24gY2FuIGJlIGZvcm11bGF0ZWQgYXMgZGlmZmVyZW50IG1l dHJpYyB0eXBlcywgZS5nLixhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWMsIHRyYW5zcG9ydCBsZXZl bCBtZXRyaWMsIGVuZCBzeXN0ZW0gbWV0cmljLCBpbnRlcnZhbCBtZXRyaWMsIGN1bXVsYXRpdmUg bWV0cmljLCBzYW1wbGVkIG1ldHJpYywgZGlyZWN0IG1ldHJpYywgY29tcG9zZWQgbWV0cmljLGV0 Yy4gQm90aCB0aGUgUlRDUCBvciBSVENQIFhSIGNhbiBiZSBleHRlbmRlZCB0byBjb252ZXkgdGhl c2UgbWV0cmljcy4gVGhlIGRldGFpbHMgb24gdHJhbnNwb3J0IHByb3RvY29scyBmb3IgdGhlc2Ug bWV0cmljIGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuIFJUUCBtYXkgYmUgdXNlZCB0byBt dWx0aWNhc3QgZ3JvdXBzLCBib3RoIEFueSBTb3VyY2UgTXVsdGljYXN0IChBU00pIGFuZCBTb3Vy Y2UgU3BlY2lmaWMgTXVsdGljYXN0IChTU00pLiBUaGVzZSBncm91cHMgY2FuIGJlIG1vbml0b3Jl ZCB1c2luZyBSVENQLiBJbiB0aGUgQVNNIGNhc2UsIHRoZSBtb25pdG9yIGlzIGEgbWVtYmVyIG9m IHRoZSBtdWx0aWNhc3QgZ3JvdXAgYW5kIGxpc3RlbnMgdG8gUlRDUCBYUiByZXBvcnRzIGZyb20g YWxsIG1lbWJlcnMgb2YgdGhlIEFTTQ0KICAgICAgPj4gZ3JvdXAuIEluIHRoZSBTU00gY2FzZSwg dGhlcmUgaXMgYSB1bmljYXN0IGZlZWRiYWNrIHRhcmdldCB0aGF0IHJlY2VpdmVzIFJUQ1AgZmVl ZGJhY2sgZnJvbSByZWNlaXZlcnMgYW5kIGRpc3RyaWJ1dGVzIGl0IHRvIG90aGVyIG1lbWJlcnMg b2YgdGhlIFNTTSBncm91cCAoc2VlIGZpZ3VyZSAxIG9mIFJGQzU3NjApLiBUaGUgbW9uaXRvciB3 aWxsIG5lZWQgdG8gYmUgY28tbG9jYXRlZCB3aXRoIHRoZSBmZWVkYmFjayB0YXJnZXQgdG8gcmVj ZWl2ZSBhbGwgZmVlZGJhY2sgZnJvbSB0aGUgcmVjZWl2ZXJzICh0aGlzIG1heSBhbHNvIGJlIGFu IGludGVybWVkaWF0ZSBzeXN0ZW0pLiBJbiBib3RoIEFTTSBhbmQgU1NNIHNjZW5hcmlvcywgcmVj ZWl2ZXJzIGNhbiBzZW5kIFJUQ1AgWFIgcmVwb3J0cyB0byBlbmhhbmNlIHRoZSByZWNlcHRpb24g cXVhbGl0eSByZXBvcnRpbmcuICIgPiBJbiB0aGUgZGVmaW5pdGlvbiBvZiBDb21wb3NlZCBtZXRy aWNzLCB0aGUgc2VudGVuY2UgIkFuIGV4YW1wbGUgaXMgYSANCiAgICAgID4+PiBtZXRyaWMgY2Fs Y3VsYXRlZCBiYXNlZCBvbiBkZXJpdmVkIG1ldHJpY3MgdGhhdCBoYXZlIGJlZW4gbWVhc3VyZWQu IiANCiAgICAgID4+PiBtYWtlcyBsaXR0bGUgc2Vuc2UuIFtRaW5dIFRoZSBkZXJpdmVkIG1ldHJp Y3MgaW4gdGhlIHNlbnRlbmNlIHNob3VsZCBiZWVuIGNvcnJlY3RlZCBhcyAiZGlyZWN0IG1ldHJp YyIuID5EaWQgeW91IG1lYW4gc29tZXRoaW5nIGxpa2UgIkFuIGV4YW1wbGUgaXMgYSBtZXRyaWMg DQogICAgICA+Pj4gZGVyaXZlZCBieSBhbGdvcml0aG1pY2FsbHkgY29tYmluaW5nIG1lYXN1cmVk IG1ldHJpY3MuIj8gW1Fpbl06SSBhZ3JlZSB3aXRoIHlvdXIgc3VnZ2VzdGVkIHRleHQgYW5kIGxp a2UgdG8gYWRvcHQgeW91ciBzdWdnZXN0aW9uLiA+IFRoZSBkZWZpbml0aW9ucyBvZiBJbnRlcnZh bCwgQ3VtdWxhdGl2ZSwgYW5kIFNhbXBsZWQgbWV0cmljcyBhcmUgbm90IGNsZWFyLiBbUWluXTog SSBhZ3JlZSB0aGUgZGVmaW5pdGlvbiBmb3IgdGhlc2UgdGhyZWUgbWV0cmljcyBuZWVkIHRvIGJl IG1vcmUgY2xlYWVyLCBJIHByb3Bvc2VzIHRvIGRvIHRoZSBmb2xsb3dpbmcgY2hhbmdlczogTkVX IFRleHQ6ICIgSW50ZXJ2YWwgbWV0cmljcyBNZXRyaWNzIG9mIHdoaWNoIHRoZSByZXBvcnRlZCB2 YWx1ZXMgYXJlIG1lYXN1cmVkIGluIHRoZSBtb3N0IHJlY2VudCBtZWFzdXJlbWVudCBpbnRlcnZh bCBkdXJhdGlvbiBiZXR3ZWVuIHN1Y2Nlc3NpdmUgbWV0cmljcyByZXBvcnRzLiBTdWNoIG1lYXN1 cmVtZW50IGludGVydmFsIGlzIGVxdWFsIHRvIG9uZSBSVENQIHJlcG9ydCBpbnRlcnZhbCAoUkZD MzU1MCxTZWN0aW9uIDYuMikuIEN1bXVsYXRpdmUgbWV0cmljcyBNZXRyaWNzIG9mIHdoaWNoIHRo ZSByZXBvcnRlZCB2YWx1ZXMgYXBwbHkgdG8gdGhlIGFjY3VtdWxhdGlvbiBwZXJpb2QgY2hhcmFj dGVyaXN0aWMgb2YgY3VtdWxhdGl2ZSBtZWFzdXJlbWVudHMuIFRoZSByZXBvcnRlZCB2YWx1ZXMg YXJlIG1lYXN1cmVkIGR1cmluZyB0aGUgYWNjdW11bGF0aW9uIHBlcmlvZC4gVGhlIGFjY3VtdWxh dGlvbiBwZXJpb2Qgc3BhbnMgb3ZlciBtb3JlIHRoYW4gb25lIFJUQ1AgcmVwb3J0IGludGVydmFs cy4gU2FtcGxlZCBtZXRyaWNzIE1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVkIHZhbHVlcyBv bmx5IGFwcGx5IHRvIHRoZSB2YWx1ZSBvZiBhIGNvbnRpbnVvdXNseSBtZWFzdXJlZCBvcg0KICAg ICAgPj4gY2FsY3VsYXRlZCBtZXRyaWMgdGhhdCBoYXMgYmVlbiBzYW1wbGVkIGF0IGFueSBnaXZl biBpbnN0YW5jZSBvZiB0aGUgUlRDUCByZXBvcnQgaW50ZXJ2YWwuIE9uZSBleGFtcGxlIG9mIHN1 Y2ggbWV0cmljIGlzIHRoZSBpbnRlci1hcnJpdmFsIGppdHRlciBkZXNjcmliZWQgaW4gdGhlIHNl Y3Rpb24gNi40LjEgb2YgUkZDMzU1MC4gIiA+IElmIHRoZSBkaXNjdXNzaW9uIGF0IHRoZSBlbmQg b2Ygc2VjdGlvbiAzLjEgaXMga2VwdCwgdGhlIHJlZmVyZW5jZSB0byANCiAgICAgID4+PiBSRkM1 NzYwIHNob3VsZCBiZSBhIHJlYWwgcmVmZXJlbmNlLCBhbmQgUkZDNTc2MCBzaG91bGQgYXBwZWFy IGluIHRoZSANCiAgICAgID4+PiByZWZlcmVuY2Ugc2VjdGlvbi4gW1Fpbl06IE9rYXkuID4gVGhl IHBvaW50IG9mIHNlY3Rpb24gMy4yIGlzIG5vdCBvYnZpb3VzLiBIb3cgZG9lcyBpdCBjb250cmli dXRlIHRvIHRoZSANCiAgICAgID4+PiBkZXNjcmlwdGlvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlLiBJ dCBtaXhlcyB0YWxraW5nIGFib3V0IHdoYXQgcmVwb3J0IA0KICAgICAgPj4+IGJsb2NrcyBhcmUg d2l0aCBvY2Nhc2lvbmFsbHkgbmVlZGluZyB0byBzZW5kIHRoZW0gbW9yZSBmcmVxdWVudGx5LiBU aG9zZSANCiAgICAgID4+PiBwb2ludHMgY291bGQgYmUgbWFkZSBzZXBhcmF0ZWx5IGFuZCBtb3Jl IHNpbXBseS4gW1Fpbl06IE9rYXkuIEkgbGlrZSB0byBpbmNvcnBvcmF0ZSB0aGUga2V5IHBvaW50 cyBpbiB0aGUgc2VjdGlvbiAzLjIgaW50byBzZWN0aW9uIDMuMSA+IFNlY3Rpb24gMy4zIGlzIG5v dCBjbGVhciAtIGl0IHN0YXJ0cyBvZmYgc2F5aW5nIHRoYXQgdGhlIGxvY2F0aW9uIG9mIHRoZSAN CiAgICAgID4+PiBzZW5kZXIgYW5kIHJlY2VpdmVyIG1heSBjaGFuZ2Ugd2hhdCBtZXRyaWNzIGFy ZSBtZWFuaW5nZnVsLiBJdCdzIG5vdCANCiAgICAgID4+PiBjbGVhciB3aGF0IHlvdSBtZWFuIGJ5 IGxvY2F0aW9uLiBZb3UgY2VydGFpbmx5IGRvbid0IG1lYW4gZ2Vvc3BhdGlhbCANCiAgICAgID4+ PiBjb29yZGluYXRlcy4gRG8geW91IG1lYW4gYW55dGhpbmcgb3RoZXIgdGhhbiB3aGV0aGVyIHRo ZSBlbGVtZW50IGlzIA0KICAgICAgPj4+IHRydXN0ZWQgb3IgdW50cnVzdGVkIGJ5IHRoZSBvcGVy YXRpb25zIG5ldHdvcms/IElmIHNvLCBzYXkgdGhhdC4gVGhlIA0KICAgICAgPj4+IHJlc3Qgb2Yg dGhlIHBhcmFncmFwaCBvbmx5IHNwZWFrcyB0byB3aGF0IGVsZW1lbnQgY29sbGVjdHMgdGhlIG1l dHJpY3MuIFtRaW5dIFNlY3Rpb24gMy4zIGlzIG9ubHkgdXNlZCB0byBkZXNjcmliZSB3aGVyZSBv ciBmcm9tIHdoaWNoIFJUUCBlbnRpdHkgdG8gZ2F0aGVyIHRoZSBtZXRyaWNzIChpLmUuLCBtZWFz dXJlbWVudCBwb2ludCkgaW4gdGhlIHBoeXNpY2FsIG5ldHdvcmsgYW5kIGlzIG5vdCBmb2N1cyBv ZiB0aGlzIGRvY3VtZW50LiBTZWNvbmRseSwgSSB0aGluayB0aGUgZGVmaW5pdGlvbiBvZiBhcHBs aWNhdGlvbiBsZXZlbCBtZXRyaWNzIGhhcyBhbHJlYWR5IGNsYXJpZmllZCB0aGF0IGFwcGxpY2F0 aW9uIGxldmVsIG1ldHJpY3MgaXMgbm9ybWFsbHkgZ2F0aGVyZWQgZnJvbSB1c2VyIGVuZHBvaW50 LiA+IEl0J3Mgbm90IGNsZWFyIHRoYXQgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MgaXMg Y2hhbmdlZCBhdCBhbGwgLSANCiAgICAgID4+PiBqdXN0IHdoZXJlIHlvdSBjb2xsZWN0IHRoZW0u IElmIHRoZSBzZXQgb2YgbWVhbmluZ2Z1bCBtZXRyaWNzIGRvZXMgaW4gDQogICAgICA+Pj4gZmFj dCBjaGFuZ2UsIHRoZXJlIG5lZWRzIHRvIGJlIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbiBoZXJlLiBb UWluXTogVGhlIG1ldHJpY3MgYWN0dWFsbHkgZG9lc24ndCBjaGFuZ2UuU2luY2UgdGhlIGRlZmlu aXRpb24gb2YgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcyBIYXZlIGFscmVhZHkgY29udmV5ZWQg dGhlIG1lYW5pbmcgb2Ygd2hhdCBzZWN0aW9uIDMuMyB3YW50cyB0byBkZXNjcmliZSwgSSBwcm9w b3NlIHRvIHJlbW92ZSB0aGlzIHNlY3Rpb24uID4gU2VjdGlvbiA0J3MgZmlyc3QgcGFyYWdyYXBo OiBJcyAicHJvYmFibHkiIHRoZSBiZXN0IHRoZSB3b3JraW5nIGdyb3VwIA0KICAgICAgPj4+IGNh biBzYXk/IFtRaW5dOk5vLCB3aWxsIHJlbW92ZSB0aGlzIHdvcmQuID4gVGhlIGxhc3QgdHdvIHNl bnRlbmNlcyBvZiB0aGUgc2Vjb25kIGJ1bGxldCBpbiBzZWN0aW9uIDQgZG8gbm90IHBhcnNlLiAN CiAgICAgID4+PiBQbGVhc2Ugc2ltcGxpZnkgdGhlbS4gW1Fpbl06IE9rYXksIGhvdyBhYm91dCBj aGFuZ2UgdGhlbSBhcyBmb2xsb3dzOiBORVcgVGV4dDogIiBXaXRoIHRoZXNlIG1pbmltYWwgbnVt YmVyIG9mIFJUQ1Agc3RhdGlzdGljcyBwYXJhbWV0ZXJzIG1hcHBlZCB0byBub24tUlRDUCBtZWFz dXJlbWVudHMsIGl0IGlzIGhhcmQgdG8gcHJvdmlkZSBhY2N1cmF0ZSBtZWFzdXJlcyBvZiByZWFs IHRpbWUgYXBwbGljYXRpb24gcXVhbGl0eSxjb25kdWN0IGRldGFpbGVkIGRhdGEgYW5hbHlzaXMg YW5kIGNyZWF0ZXMgYWxlcnRzIHRpbWx5IHRvIHRoZSB1c2Vycy4gVGhlcmVmb3JlIGNvcnJlbGF0 aW9uIGJldHdlZW4gUlRDUCBYUiBhbmQgbm9uLVJUUCBkYXRhIHNob3VsZCBiZSBwcm92aWRlZC4g IiA+IFRoZSBmaXJzdCBmdWxsIHNlbnRlbmNlIG9mIHRoZSB0aGlyZCBidWxsZXQgaW4gc2VjdGlv biA0IGRvZXMgbm90IG1ha2UgDQogICAgICA+Pj4gc2Vuc2UuIFRoZSB3aG9sZSBidWxsZXQgY291 bGQgYmUgY2xhcmlmaWVkLiBbUWluXTogQWdyZWUgYW5kIHdpbGwgcmVtb3ZlIHRoZSBmaXJzdCBz ZW50ZW5jZS4gPiBUaGUgZm91cnRoIGJ1bGxldCBpbiBzZWN0aW9uIDQgYW5kIHNlY3Rpb24gNS41 IHNob3VsZCBjYWxsIG91dCB0aGF0IA0KICAgICAgPj4+IFJGQzM2MTEgYWxyZWFkeSBzZXQgQmxv Y2sgVHlwZSAyNTUgYXNpZGUgZm9yIGZ1dHVyZSBleHRlbnNpb25zLCANCiAgICAgID4+PiBhbnRp Y2lwYXRpbmcgdGhlIHBvdGVudGlhbCBuZWVkIHRvIGV4dGVuZCB0aGUgYmxvY2sgdHlwZSBzcGFj ZS4gW1Fpbl06IE9rYXksIEhvdyBhYm91dCByZXZpc2luZyB0aGUgc2VjdGlvbiA0LGJ1bGxldCA0 IGFzIGZvbGxvd3M6ICIgQ29uc3VtcHRpb24gb2YgWFIgYmxvY2sgY29kZSBwb2ludHMuIFRoZSBS VENQIFhSIGJsb2NrIG5hbWVzcGFjZSBpcyBsaW1pdGVkIGJ5IHRoZSA4LWJpdCBibG9jayB0eXBl IGZpZWxkIGluIHRoZSBSVENQIFhSIGhlYWRlci4gU3BhY2UgZXhoYXVzdGlvbiBtYXkgYmUgYSBj b25jZXJuIGluIHRoZSBmdXR1cmUuIEFudGljaXBhdGluZyB0aGUgcG90ZW50aWFsIG5lZWQgdG8g ZXh0ZW5kIHRoZSBibG9jayB0eXBlIHNwYWNlLCBpdCBpcyBub3RlZCBpbiBbUkZDMzYxMV0gdGhh dCBCbG9jayBUeXBlIDI1NSBpcyByZXNlcnZlZCBmb3IgZnV0dXJlIGV4dGVuc2lvbnMsICIgPiBJ biBzZWN0aW9uIDUsIGNvbnNpZGVyIG5hbWluZyB0aGUgc3Vic2VjdGlvbnMgd2l0aCB0aGUgYWN0 dWFsIGd1aWRlbGluZSANCiAgICAgID4+PiBpbnN0ZWFkIG9mIHRoZSBwcm9ibGVtIHRoZSBndWlk ZWxpbmUgaXMgdHJ5aW5nIHRvIGFkZHJlc3MuDQogICAgICA+Pj4gNS4xLiBNZXRyaWMgYmxvY2tz IHNob3VsZCBjb250YWluIGEgc2luZ2xlIG1ldHJpYyBbUWluXTogSSBzdWdnZXN0IHRvIGNoYW5n ZSBpdCBhcyAiQ29udGFpbiB0aGUgc2luZ2xlIG1ldHJpY3MgaW4gdGhlIG1ldHJpYyBibG9jayIg PiA1LjIuIEluY2x1ZGUgdGhlIHBheWxvYWQgdHlwZSBhbmQgZm9ybWF0IHBhcmFtZXRlcnMgaW4g dGhlIG1ldHJpYyBibG9jayBbUWluXTogT2theS4gPiA1LjMuIFVzZSBSVENQIFNERVMgdG8gY29y cmVsYXRlIFhSIHJlcG9ydHMgd2l0aCBub24tUlRQIGRhdGEgW1Fpbl06IE9rYXkuID4gNS40LiBE b24ndCByZXBlYXQgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gYWNyb3NzIG1ldHJpYyBibG9ja3MN CiAgICAgID4+PiANCiAgICAgID4+IFtRaW5dOiBJdCBpcyBub3QgcG9zc2libGUgY29tcGxldGVs eSB0byBhdm9pZCBtZWFzdXJlbWVudCBpbmZvcm1hdGlvbiByZXBlYXRpdGlvbi4gZS5nLiwgZm9y IHBhY2tldCBsb3NzIHJvYnVzdG5lc3MgaWYgdGhlIHJlcG9ydCBibG9ja3MgZm9yIHRoZSBzYW1l IGludGVydmFsIHNwYW4gb3ZlciBtb3JlIHRoYW4gb25lIFJUQ1AgcGFja2V0IHRoZW4gZWFjaCBt dXN0IGhhdmUgdGhlIHNhbWUgbWVhc3VyZW1lbnQgaWRlbnRpdHkgaW5mb3JtYXRpb24gU28gSSBz dWdnZXN0IHRvIGNoYW5nZSBpdCBhczogInJlZHVjZSBtZWFzdXJlbWVudCBpbmZvcm1hdGlvbiBh Y3Jvc3MgbWV0cmljIGJsb2NrcyIgPiBUaGlzIHBvaW50cyBvdXQgYSBzdHJ1Y3R1cmFsIHByb2Js ZW0gd2l0aCB0aGUgc2VjdGlvbi4gV2h5IGlzIDUuNSBoZXJlPyANCiAgICAgID4+PiBJdCdzIG5v dCBhIGd1aWRlbGluZS4gW1Fpbl06IEFncmVlIGFuZCBhbHNvIGFzIGRpc2N1c3NlZCxTcGFjZSBl eGhhdXN0aW9uIGlzIG5vdCBiaWcgaXNzdWUuIEhvdyBhYm91dCByZW1vdmUgdGhpcyBzZWN0aW9u PyA+ICgqKSBBbmQgaXQgcmFpc2VzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUgZG9jdW1lbnQg aXMgdHJ5aW5nIHRvIA0KICAgICAgPj4+IGFjaGlldmUgd2l0aCBzZWN0aW9uIDUuNC4gVGhhdCBz ZWN0aW9uIGNsYWltcyB0aGUgZG9jdW1lbnQgaXMgcHJvcG9zaW5nIA0KICAgICAgPj4+IGEgbmV3 IFhSIGJsb2NrIHR5cGUgdG8gaGVscCBhdm9pZCBkdXBsaWNhdGlvbiwgYnV0IGl0IGRvZXNuJ3Qg YWN0dWFsbHkgDQogICAgICA+Pj4gZGVmaW5lIHRoZSBuZXcgYmxvY2sgdHlwZS4gSXMgdGhlIGd1 aWRlbGluZSBzYXlpbmcgc2ltcGx5IGRvbid0IHJlcGVhdCANCiAgICAgID4+PiBtZWFzdXJlbWVu dHMgb3IgaXRzIHRoZSBndWlkZWxpbmUgc2F5aW5nICJ1c2UgdGhpcyBuZXcgWFIgYmxvY2sgdHlw ZSB3ZSANCiAgICAgID4+PiBoYXZlbid0IGRlZmluZWQgeWV0Ij8gW1Fpbl06IEp1c3QgdG8gY2xh cmlmeSwgd2UgaGF2ZSBhbHJlYWR5IGRlZmluZWQgb25lIG5ldyBYUiBCbG9jayB0eXBlIHRvIGhl bHAgYXZvaWQgb3IgcmVkdWNlIGR1cGxpY2F0aW9uLiBJdCBpcyBtZWFzdXJlbWVudCBpbmZvcm1h dGlvbiBibG9jay4gVGhlIHJlbGV2YW50IGRyYWZ0IGlzIGF2YWlsYWJsZSBhdDogaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbWVhcy1pZGVudGl0 eS0wNiA+VGhlIHNlY3Rpb24gbmVlZHMgbW9yZSBjbGFyaXR5LiBJZiBpdCByZWFsbHkgaXMgDQog ICAgICA+Pj4gdHJ5aW5nIHRvIGRlZmluZSBhIG5ldyB0eXBlLCB0aGVyZSdzIG1vcmUgd29yayB0 byBiZSBkb25lLiBbUWluXTogSW4gb3JkZXIgdG8gYXZvaWQgc3VjaCBjb25mdXNpb24sIEkgcHJv cG9zZWQgdG8gZG8gdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIHNlY3Rpb24gNS40OiBPTEQg VGV4dDogIiBUaGlzIG1lbW8gcHJvcG9zZXMgdG8gZGVmaW5lIGEgbmV3IFhSIEJsb2NrIHRoYXQg d2lsbCBiZSB1c2VkIHRvIGNvbnZleSB0aGUgY29tbW9uIHRpbWUgcGVyaW9kIGFuZCB0aGUgbnVt YmVyIG9mIHBhY2tldHMgc2VudCBkdXJpbmcgdGhpcyBwZXJpb2QuICIgTmV3IHRleHQ6ICIgVGhp cyBtZW1vIHByb3Bvc2VzIHRvIGRlZmluZSBhIG5ldyBYUiBCbG9jayAoaS5lLiwgdGhlIE1lYXN1 cmVtZW50IGluZm9ybWF0aW9uIGJsb2NrW0kuRC1pZXRmLXhyYmxvY2stcnRjcC14ci1tZWFzLWlk ZW50aXR5XSkgdGhhdCB3aWxsIGJlIHVzZWQgdG8gY29udmV5IHRoZSBjb21tb24gdGltZSBwZXJp b2QgYW5kIHRoZSBudW1iZXIgb2YgcGFja2V0cyBzZW50IGR1cmluZyB0aGlzIHBlcmlvZC4gIiA+ IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBwYXJ0aWN1bGFybHkgdGhlIHRo aXJkIHBhcmFncmFwaCwgDQogICAgICA+Pj4gbmVlZHMgdG8gYmUgY2xlYXJlci4gV2hhdCBleGFj dGx5IGRvIHlvdSBtZWFuIGJ5ICJtb25pdG9yaW5nIHNob3VsZCBiZSANCiAgICAgID4+PiBwcm9o aWJpdGVkIiwgYW5kIGhvdyBpcyB0aGUgZmFjdCB0aGF0IHRoaXJkIHBhcnR5IG1vbml0b3JzIGRv bid0IHNlbmQgDQogICAgICA+Pj4gUlRDUCByZWxldmFudD8gRGlkIHlvdSBpbnRlbmQgdGhvc2Ug dG8gYmUgc2VwYXJhdGUgcG9pbnRzPyBbUWluXTogWWVzLCB0aGV5IGFyZSBvbiB0aGUgZGlmZmVy ZW50IHBvcnQuIFN1Y2ggbW9uaXRvciBtYXkgcmVjZWl2ZSBSVFAgcGFja2V0IGJ1dCBkb2VzIG5v dCBzZW5kIFJUQ1AgcGFja2V0LiA+IEVkaXRvcmlhbCBOaXRzIGFuZCBTdWdnZXN0aW9uczoNCiAg ICAgID4+PiANCiAgICAgID4+PiBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBpbnRyb2R1Y3Rp b24gaXMgb3Zlcmx5IGNvbXBsZXgsIGFuZCB3b24ndCBhZ2UgDQogICAgICA+Pj4gd2VsbC4gSSBz dWdnZXN0IHJlcGxhY2luZyBpdCB3aXRoOiAiTXVsdGltZWRpYSBzZXJ2aWNlcyB1c2luZyB0aGUg DQogICAgICA+Pj4gUmVhbC1UaW1lIFByb3RvY29sIChSVFApIGFyZSBzZWVpbmcgaW5jcmVhc2Vk IHVzZS4gU3RhbmRhcmQgbWV0aG9kcyBmb3IgDQogICAgICA+Pj4gZ2F0aGVyaW5nIFJUUCBwZXJm b3JtYW5jZSBtZXRyaWNzIGZyb20gdGhlc2UgYXBwbGljYXRpb25zIGFyZSBuZWVkZWQgdG8gDQog ICAgICA+Pj4gbWFuYWdlIHVuY2VydGFpbnRpZXMgaW4gdGhlIGJlaGF2aW9yIGFuZCBhdmFpbGFi aWxpdHkgb2YgdGhlaXIgDQogICAgICA+Pj4gc2VydmljZXMuIiBUaGVuIHJlcGxhY2UgIlRoZXNl IHJhcGlkbHkgZW1lcmdpbmcgc3RhbmRhcmRzLCIgd2l0aCANCiAgICAgID4+PiAiU3RhbmRhcmRz Ii4gW1Fpbl06IE9rYXkuID4gSW50cm9kdWN0aW9uIHBhcmFncmFwaCAzIHNlbnRlbmNlIDIgc2hv dWxkIHN0YXJ0ICJUaGUgUlRDUCBHdWlkZWxpbmVzIA0KICAgICAgPj4+IFtSRkM1OTY4XSIuIEl0 IHdvdWxkIGJlIGV2ZW4gYmV0dGVyIHRvIHVzZSB0aGUgZnVsbCB0aXRsZSBmcm9tIDU5Njg6IA0K ICAgICAgPj4+ICdUaGUgIkd1aWRlbGluZXMgZm9yIEV4dGVuZGluZyB0aGUgUlRQIENvbnRyb2wg UHJvdG9jb2wgKFJUQ1ApIiBbUkZDNTk2OF0nIFtRaW5dOiBPa2F5LiA+IFRoaXMgbWF5IGJlY29t ZSBtb290IGFzIHNlY3Rpb24gMyBpcyBtb2RpZmllZCB0byBtYWtlIGl0cyBtYWluIHBvaW50IA0K ICAgICAgPj4+IG1vcmUgb2J2aW91cywgYnV0IFJGQzM1NTAgZG9lcyBub3QgY2hhcmFjdGVyaXpl IE1vbml0b3JzIGFzICJhIHNvdXJjZSBvZiANCiAgICAgID4+PiBpbmZvcm1hdGlvbiIuIFRoYXQg Y291bGQgYmUgbWlzdW5kZXJzdG9vZC4gUGxlYXNlIGNob29zZSBhbm90aGVyIHdvcmQuIA0KICAg ICAgPj4+IFBlcmhhcHMgInJlcG9zaXRvcnkiPyBbUWluXTogT2theSwgcmVwb3NpdG9yeSBsb29r cyBnb29kIHRvIG1lLiA+IEluIGJ1bGxldCBsaXN0cywgc3RhcnRpbmcgYW4gZW50cnkgd2l0aCAi b3IiIG9yICJhbmQiIGlzIHVubmVjZXNzYXJ5LiBJdCANCiAgICAgID4+PiBzaG91bGQgYmUgY2xl YXIgZnJvbSB0aGUgaW50cm9kdWN0aW9uIHRvIHRoZSBsaXN0IHdoZXRoZXIgdGhlIGluZGl2aWR1 YWwgDQogICAgICA+Pj4gZW50cmllcyBzaG91bGQgYmUgY29tYmluZWQgb3Igc2VsZWN0ZWQgZnJv bS4gW1Fpbl06IE9rYXkuID4gSW4gc2VjdGlvbiAzLjEgd2hlcmUgeW91IHNheSAiUlRQIG1heSBi ZSB1c2VkIHRvIG11bHRpY2FzdCBncm91cHMiIGRpZCANCiAgICAgID4+PiB5b3UgbWVhbiAiUlRQ IG1heSBiZSBzZW50IHRvIG11bHRpY2FzdCBncm91cHMiIG9yICJSVFAgbWF5IGJlIHVzZWQgd2l0 aCANCiAgICAgID4+PiBtdWx0aWNhc3QgZ3JvdXBzIj8gW1Fpbl06IEkgdGhpbmsgaXQgc2hvdWxk IGJlIHRoZSBsYXR0ZXIgY2FzZSxpLmUuLCIgUlRQIG1heSBiZSB1c2VkIHdpdGggDQogICAgICA+ PiBtdWx0aWNhc3QgZ3JvdXBzIi4gPiANCiAgICAgID4+PiBJbiBzZWN0aW9uIDMuMiAiVGhlIGZv bGxvd2luZyBhcmUgZm91ciB1c2UgY2FzZXMgYnV0IGFyZSBub3QgbGltaXRlZCANCiAgICAgID4+ PiB0bzoiIGRvZXMgbm90IHBhcnNlLiBUaGUgYnVsbGV0cyBhcmVuJ3QgcmVhbGx5IHVzZSBjYXNl cyBhcyBtdWNoIGFzIHRoZXkgDQogICAgICA+Pj4gYXJlIG1lY2hhbmlzbXMuIFdvdWxkIGl0IG1h a2UgbW9yZSBzZW5zZSB0byBzYXkgIkhlcmUgYXJlIGZvdXIgDQogICAgICA+Pj4gbWVjaGFuaXNt cyB0aGF0IGhhdmUgYmVlbiBjcmVhdGVkIHRvIGFkZHJlc3MgdGhlIG5lZWQgZm9yIG1vcmUgZnJl cXVlbnQgDQogICAgICA+Pj4gcmVwb3J0aW5nLiBUaGlzIGxpc3QgaXMgbm90IGludGVuZGVkIHRv IGJlIGV4aGF1c3RpdmUuIiBUaGUgdGhpcmQgYnVsbGV0IA0KICAgICAgPj4+IGluIHRoYXQgbGlz dCBzaG91bGQgc2F5ICJSVENQIGFuZCBSVENQIFhSIGFyZSIgaW5zdGVhZCBvZiAiUlRDUCBvciBS VENQIA0KICAgICAgPj4+IFhSIGlzIi4gW1Fpbl06IE9rYXksIGJ1dCBJIGhhdmUgaW5jb3Jwb3Jh dGVkIHRoZSBrZXlwb2ludHMgb2Ygc2VjdGlvbiAzLjIgaW50byBzZWN0aW9uIDMuMS4gPiBUaGUg YnVsbGV0cyBpbiBzZWN0aW9uIDQgd291bGQgYmUgYmV0dGVyIGFzIHN1YnNlY3Rpb25zIHdpdGgg dGl0bGVzIA0KICAgICAgPj4+ICh0YWtlbiBmcm9tIHRoZSBmaXJzdCBwaHJhc2Ugb2YgdGhlIGJ1 bGxldCkuIFtRaW5dOiBPa2F5LiA+IEkgc3VnZ2VzdCB0aGlzIGFsdGVybmF0aXZlIGZvciB0aGUg Zmlyc3QgZnVsbCBzZW50ZW5jZSBpbiB0aGUgZmlyc3QgDQogICAgICA+Pj4gYnVsbGV0IG9mIHNl Y3Rpb24gNCA6ICJBIGNvbXBvdW5kIG1ldHJpY3MgYmxvY2sgaXMgZGVzaWduZWQgdG8gY29udGFp biBhIA0KICAgICAgPj4+IGxhcmdlIG51bWJlciBvZiBwYXJhbWV0ZXJzIGZyb20gZGlmZmVyZW50 IGNsYXNzZXMgZm9yIGEgc3BlY2lmaWMgDQogICAgICA+Pj4gYXBwbGljYXRpb24gaW4gYSBzaW5n bGUgYmxvY2suIiBbUWluXTogT2theS4gPiBTZWN0aW9uIDUncyB0aXRsZSBzaG91bGQgYmUgIkd1 aWRlbGluZXMgZm9yIHJlcG9ydGluZyIgaW5zdGVhZCBvZiANCiAgICAgID4+PiAiR3VpZGVsaW5l IGZvciByZXBvcnRpbmciIFtRaW5dOiBPa2F5LiA+IEluIHNlY3Rpb24gNS4xIEkgc3VnZ2VzdCAi anVzdGlmeSB0aGUgb3ZlcmhlYWQsIiBpbnN0ZWFkIG9mICJqdXN0aWZ5IHRoZSANCiAgICAgID4+ PiBvdmVyaGVhZHMsIiBbUWluXTogT2theS4gPiBTZWN0aW9uIDcgLSB0aGUgbGFzdCBzZW50ZW5j ZSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIGRvZXMgbm90IHBhcnNlLiBUaGUgDQogICAgICA+Pj4g c2Vjb25kIHBhcmFncmFwaCAod2hpY2ggaXMgYSBzaW5nbGUgc2VudGVuY2UpIHNob3VsZCBiZSBj bGFyaWZpZWQgLSBhbiANCiAgICAgID4+PiBNQ1UgaXMgbm90IGEgdG9wb2xvZ3kuIFtRaW5dOiBP a2F5LiBIb3cgYWJvdXQgcmV2aXNpbmcgdGhlbSBhcyBmb2xsb3dzOiBPTEQgVGV4dDogIiBUaGUg dG9wb2xvZ2llcyBpbiB0aGlzIGNhdGVnb3J5IGFyZSBUb3BvLVZpZGVvLVN3aXRjaC1NQ1UgYW5k IFRvcG8tUlRDUC10ZXJtaW5hdGluZy1NQ1UuIFN1Y2ggdG9wb2xvZ2llcyBiYXNlZCBvbiBzeXN0 ZW1zIGRvIG5vdCBiZWhhdmUgYWNjb3JkaW5nIHRvIHRoZSBSVFAgcHJvdG9jb2wgW1JGQzM1NTBd LiBDb25zaWRlcmluZyB0aGUgTUNVIGFuZCB0cmFuc2xhdG9yIGFyZSB0d28gdHlwaWNhbCB0b3Bv bG9naWVzIGluIHRoZSB0d28gY2F0ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1l bnQgd2lsbCB0YWtlIHRoZW0gYXMgdHdvIHR5cGljYWwgZXhhbXBsZXMgdG8gZXhwbGFpbiBob3cg UlRDUCBYUiByZXBvcnQgd29ya3MgaW4gZGlmZmVyZW50IFJGQzUxMTcgdG9wb2xvZ2llcy4gIiBO RVcgVGV4dDogIiBUaGUgdG9wb2xvZ2llcyBpbiB0aGlzIGNhdGVnb3J5IGFyZSBUb3BvLVZpZGVv LVN3aXRjaC1NQ1UgYW5kIFRvcG8tUlRDUC10ZXJtaW5hdGluZy1NQ1UuIFN1Y2ggdG9wb2xvZ2ll cyBiYXNlZCBvbiBzeXN0ZW1zIChlLmcuLE1DVSkgZG8gbm90IGJlaGF2ZSBhY2NvcmRpbmcgdG8g dGhlIFJUUCBwcm90b2NvbCBbUkZDMzU1MF0uIENvbnNpZGVyaW5nIHRoZSBNQ1UgYW5kIHRyYW5z bGF0b3IgYXJlIHR3byB0eXBpY2FsIGludGVybWVkaWFyeSBzeXN0ZW1zIGluIHRoZSB0d28gY2F0 ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1lbnQgd2lsbCB0YWtlIHRoZW0gYXMg dHdvIHR5cGljYWwgZXhhbXBsZXMgdG8gZXhwbGFpbiBob3cgUlRDUCBYUiByZXBvcnQgd29ya3Mg aW4gZGlmZmVyZW50IFJGQzUxMTcgdG9wb2xvZ2llcy4gIiA+IFRoZSBsYXN0IHR3byBzZW50ZW5j ZXMgb2YgdGhlIGZpcnN0DQogICAgICA+PiBwYXJhZ3JhcGggb2YgdGhlIHNlY3VyaXR5IA0KICAg ICAgPj4+IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYWRkIG5vdGhpbmcgdG8gdGhlIGRvY3VtZW50 LiBJIHN1Z2dlc3QgZGVsZXRpbmcgdGhlbS4gW1Fpbl06IE9rYXkuID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgID4+PiBBdWRpby9WaWRlbyBU cmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KICAgICAgPj4+IGF2dCBhdCBpZXRmLm9yZw0KICAg ICAgPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0ID4NCiAgICAg ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICA+PiANCiAgICAgID4+ ICogUmVmZXJlbmNlczogDQogICAgICA+PiAqIFtBVlRDT1JFXSBTdWJqZWN0OiBBRCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMgDQogICAgICA+PiAqIEZyb206IFJvYmVy dCBTcGFya3MNCiAgICAgID4+ICogUHJldiBieSBEYXRlOiBbQVZUQ09SRV0gUHJvdG9jb2wgQWN0 aW9uOiAnRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgZm9yIFJUUCBvdmVy IA0KICAgICAgPj4gVURQJyB0byBQcm9wb3NlZCBTdGFuZGFyZCAoZHJhZnQtaWV0Zi1hdnRjb3Jl LWVjbi1mb3ItcnRwLTA4LnR4dCkgDQogICAgICA+PiAqIFByZXZpb3VzIGJ5IHRocmVhZDogW0FW VENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0x MyANCiAgICAgID4+ICogTmV4dCBieSB0aHJlYWQ6IFtBVlRDT1JFXSBQcm90b2NvbCBBY3Rpb246 ICdFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBmb3IgUlRQIG92ZXIgDQog ICAgICA+PiBVRFAnIHRvIFByb3Bvc2VkIFN0YW5kYXJkIChkcmFmdC1pZXRmLWF2dGNvcmUtZWNu LWZvci1ydHAtMDgudHh0KSANCiAgICAgID4+ICogSW5kZXgoZXMpOiANCiAgICAgID4+ICogRGF0 ZQ0KICAgICAgPj4gKiBUaHJlYWQNCiAgICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgICA+PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29y ZSBNYWludGVuYW5jZQ0KICAgICAgPj4gYXZ0QGlldGYub3JnDQogICAgICA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KICAgICAgPiANCiAgICAgID4gDQogICAg ICA+IA0KICAgICAgPiAtLSANCiAgICAgID4gQ29saW4gUGVya2lucw0KICAgICAgPiBodHRwOi8v Y3NwZXJraW5zLm9yZy8NCiAgICAgID4gDQogICAgICA+IA0KDQoNCg0KICAgICAgLS0gDQogICAg ICBDb2xpbiBQZXJraW5zDQogICAgICBodHRwOi8vY3NwZXJraW5zLm9yZy8NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQogIC0tIA0KICBDb2xpbiBQZXJraW5zDQogIGh0dHA6Ly9jc3BlcmtpbnMub3Jn Lw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogIHhyYmxvY2sgbWFpbGluZyBs aXN0DQogIHhyYmxvY2tAaWV0Zi5vcmcNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby94cmJsb2NrDQo= ------=_NextPart_000_006D_01CD3B1E.9777A230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTIyMiI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIA0Kc3R5bGU9IldPUkQtV1JBUDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIiANCmJnQ29s b3I9I2ZmZmZmZj4NCjxESVY+T2theSxDb21iaW5pbmcgQWxicmVjaHQgYW5kIHlvdXIgbmV3IHN1 Z2dlc3Rpb25zLCBub3cgSSBwcm9wb3NlIHRoZSANCmZvbGxvd2luZyBjaGFuZ2VzIHRvIHRoZSBz ZWN0aW9uIDMuMzo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPk5FVyBURVhUOjwvRElW Pg0KPERJVj4iPC9ESVY+DQo8RElWPg0KPFAgDQpzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBt c28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IGF1dG8i IA0KY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkxBWU9VVC1HUklELU1PREU6IGJvdGg7 IEZPTlQtRkFNSUxZOiAmIzIzNDM1OyYjMjAzMDc7OyBGT05ULVNJWkU6IDEycHQ7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7IiANCmxhbmc9RU4tVVM+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4zLjMuIExvY2F0aW9uIG9mIFJUUCANCk1vbml0b3JzLjxCUj48QlI+ VGhlcmUgYXJlIHNldmVyYWwgcG9zc2libGUgbG9jYXRpb25zIGZyb20gd2hlcmUgUlRQIHNlc3Np b25zIA0KY2FuIGJlIG1vbml0b3JlZC4gVGhlc2UgaW5jbHVkZSBlbmQtc3lzdGVtcyB0aGF0IHRl cm1pbmF0ZSBSVFAgc2Vzc2lvbnMsIA0KbWlkZGxlYm94ZXMgdGhhdCBhcmUgYW4gYWN0aXZlIHBh cnQgb2YgYW4gUlRQIHNlc3Npb24sIGFuZCB0aGlyZC1wYXJ0eSBkZXZpY2VzIA0KdGhhdCBwYXNz aXZlbHkgbW9uaXRvciBhbiBSVFAgc2Vzc2lvbi4gTm90IGV2ZXJ5IFJUUCBzZXNzaW9ucyB3aWxs IGluY2x1ZGUgDQptb25pdG9yaW5nLCBhbmQgdGhvc2Ugc2Vzc2lvbnMgdGhhdCBhcmUgbW9uaXRv cmVkIHdpbGwgbm90IGFsbCBpbmNsdWRlIGVhY2ggdHlwZSANCm9mIG1vbml0b3IuIFRoZSBwZXJm b3JtYW5jZSBtZXRyaWNzIGNvbGxlY3RlZCBieSBSVFAgbW9uaXRvcnMgY2FuIGJlIGRpdmlkZWQg DQppbnRvIGVuZCBzeXN0ZW0gbWV0cmljcywgYXBwbGljYXRpb24gbGV2ZWwgbWV0cmljcywgYW5k IHRyYW5zcG9ydCBsZXZlbCBtZXRyaWNzLiANClNvbWUgb2YgdGhlc2UgbWV0cmljcyBtYXkgYmUg c3BlY2lmaWMgdG8gdGhlIG1lYXN1cmVtZW50IHBvaW50IG9mIHRoZSBSVFAgDQptb25pdG9yLCBv ciBkZXBlbmQgb24gd2hlcmUgdGhlIFJUUCBtb25pdG9ycyBhcmUgbG9jYXRlZCBpbiB0aGUgbmV0 d29yaywgd2hpbGUgDQpvdGhlcnMgYXJlIG1vcmUgZ2VuZXJhbCBhbmQgY2FuIGJlIGNvbGxlY3Rl ZCBpbiBhbnkgbW9uaXRvcmluZyBsb2NhdGlvbi4gDQo8QlI+PEJSPkVuZC1zeXN0ZW0gbW9uaXRv cmluZyBpcyBtb25pdG9yaW5nIHRoYXQgaXMgZGVwbG95ZWQgb24gZGV2aWNlcyB0aGF0IA0KdGVy bWluYXRlIFJUUCBmbG93cy4gRmxvd3MgY2FuIGJlIHRlcm1pbmF0ZWQgaW4gdXNlciBlcXVpcG1l bnQsIHN1Y2ggYXMgcGhvbmVzLCANCnZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zLCBvciBJUFRW IHNldC10b3AgYm94ZXMuIEFsdGVybmF0aXZlbHksIHRoZXkgY2FuIGJlIA0KdGVybWluYXRlZCBp biBkZXZpY2VzIHRoYXQgZ2F0ZXdheSBiZXR3ZWVuIFJUUCBhbmQgb3RoZXIgdHJhbnNwb3J0IHBy b3RvY29scy4gDQpUcmFuc3BvcnQgYW5kIGVuZCBzeXN0ZW0gbWV0cmljcywgYXBwbGljYXRpb24g bGV2ZWwgbWV0cmljcyB0aGF0IGRvbpJ0IHJlZmxlY3QgDQplbmQgdG8gZW5kIHVzZXIgZXhwZXJp ZW5jZSBtYXkgYmUgY29sbGVjdGVkIGF0IGFsbCB0eXBlcyBvZiBlbmQgc3lzdGVtLCBidXQgc29t ZSANCmFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgKGkuZS4scXVhbGl0eSBvZiBleHBlcmllbmNl IG1ldHJpY3MpIG1heSBvbmx5IGJlIA0KYXBwbGljYWJsZSBmb3IgdXNlci1mYWNpbmcgZW5kIHN5 c3RlbXMuPEJSPjxCUj5SVFAgc2Vzc2lvbnMgY2FuIGluY2x1ZGUgDQptaWRkbGVib3hlcyB0aGF0 IGFyZSBhbiBhY3RpdmUgcGFydCBvZiB0aGUgc3lzdGVtLiBUaGVzZSBtaWRkbGVib3hlcyBpbmNs dWRlIFJUUCANCm1peGVycyBhbmQgdHJhbnNsYXRvcnMsIE1DVXMsIHJldHJhbnNtaXNzaW9uIHNl cnZlcnMsIGV0Yy4gSWYgdGhlIG1pZGRsZWJveCANCmVzdGFibGlzaGVzIHNlcGFyYXRlIFJUUCBz ZXNzaW9ucyB0byB0aGUgb3RoZXIgcGFydGljaXBhbnRzLCB0aGVuIGl0IG11c3QgYWN0IGFzIA0K YW4gZW5kIHN5c3RlbSBpbiBlYWNoIG9mIHRob3NlIHNlcGFyYXRlIFJUUCBzZXNzaW9ucyBmb3Ig dGhlIHB1cnBvc2VzIG9mIA0KbW9uaXRvcmluZy4gSWYgYSBzaW5nbGUgUlRQIHNlc3Npb24gdHJh dmVyc2VzIHRoZSBtaWRkbGVib3gsIHRoZW4gdGhlIG1pZGRsZWJveCANCmNhbiBiZSBhc3NpZ25l ZCBhbiBTU1JDIGluIHRoYXQgc2Vzc2lvbiB3aGljaCBpdCBjYW4gdXNlIGZvciBpdCdzIHJlcG9y dHMuIA0KVHJhbnNwb3J0IGxldmVsIG1ldHJpY3MgbWF5IGJlIGNvbGxlY3RlZCBhdCBzdWNoIG1p ZGRsZWJveC48QlI+PEJSPlRoaXJkLXBhcnR5IA0KbW9uaXRvcnMgbWF5IGJlIGRlcGxveWVkIHRo YXQgcGFzc2l2ZWx5IG1vbml0b3IgUlRQIHNlc3Npb25zIGZvciBuZXR3b3JrIA0KbWFuYWdlbWVu dCBwdXJwb3Nlcy4gVGhpcmQtcGFydHkgbW9uaXRvcnMgb2Z0ZW4gZG8gbm90IHNlbmQgcmVwb3J0 cyBpbnRvIHRoZSBSVFAgDQpzZXNzaW9uIGJlaW5nIG1vbml0b3JlZCwgYnV0IGluc3RlYWQgY29s bGVjdCB0cmFuc3BvcnQgYW5kIGVuZCBzeXN0ZW0gbWV0cmljcywgDQphcHBsaWNhdGlvbiBsZXZl bCBtZXRyaWNzIHRoYXQgYXJlIHJlcG9ydGVkIHZpYSBzb21lIG5ldHdvcmsgbWFuYWdlbWVudCAN CmFwcGxpY2F0aW9uLiBJbiBzb21lIGNhc2VzLCBob3dldmVyLCB0aGlyZC1wYXJ0eSBtb25pdG9y cyBjYW4gc2VuZCByZXBvcnRzIHRvIA0Kc29tZSBvciBhbGwgcGFydGljaXBhbnRzIGluIHRoZSBz ZXNzaW9uIGJlaW5nIG1vbml0b3JlZC4gRm9yIGV4YW1wbGUsIGluIGEgbWVkaWEgDQpzdHJlYW1p bmcgc2NlbmFyaW8sIHRoaXJkLXBhcnR5IG1vbml0b3JzIG1heSBiZSBkZXBsb3llZCB0aGF0IHBh c3NpdmVseSBtb25pdG9yIA0KdGhlIHNlc3Npb24gYW5kIHNlbmQgcmVjZXB0aW9uIHF1YWxpdHkg cmVwb3J0cyB0byB0aGUgbWVkaWEgc291cmNlLCBidXQgbm90IHRvIA0KdGhlIHJlY2VpdmVycy48 P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPjwvRElWPg0K PERJVj4iPC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj5SZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8 QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJ TkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsi Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBi bGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1jc3BAY3NwZXJraW5zLm9yZyBocmVmPSJt YWlsdG86Y3NwQGNzcGVya2lucy5vcmciPkNvbGluIFBlcmtpbnM8L0E+IA0KICA8L0RJVj4NCiAg PERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0 bGU9YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlIA0KICBocmVmPSJtYWlsdG86YWxicmVjaHRzY2h3 YXJ6QHlhaG9vLmRlIj5BbGJyZWNodCBTY2h3YXJ6PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9eHJibG9ja0Bp ZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOnhyYmxvY2tAaWV0Zi5vcmciPnhyYmxvY2tAaWV0Zi5v cmc8L0E+IDsgPEEgdGl0bGU9YXZ0QGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86YXZ0QGlldGYu b3JnIj5hdnRAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMy MzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IEZyaWRheSwgTWF5IDI1LCAyMDEyIDEyOjM5IEFN PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJq ZWN0OjwvQj4gUmU6IFt4cmJsb2NrXSBbQVZUQ09SRV0gU3ViamVjdDogQUQgDQogIHJldmlldyBv ZmRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPkFs YnJlY2h0LA0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj5BZ3JlZWQgLSB0aGF0IHNlZW1zIGxp a2UgYSB1c2VmdWwgZGlzdGluY3Rpb24uPC9ESVY+DQogIDxESVY+Q29saW48L0RJVj4NCiAgPERJ Vj48QlI+PC9ESVY+DQogIDxESVY+PEJSPg0KICA8RElWPg0KICA8RElWPk9uIDI0IE1heSAyMDEy LCBhdCAwMjoxMiwgQWxicmVjaHQgU2Nod2FyeiB3cm90ZTo8L0RJVj48QlIgDQogIGNsYXNzPUFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmU+DQogIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAg IDxESVY+DQogICAgPERJViANCiAgICBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogI2ZmZjsgRk9O VC1GQU1JTFk6IENvdXJpZXIgTmV3LCBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1z ZXJpZjsgQ09MT1I6ICMwMDA7IEZPTlQtU0laRTogMTBwdCI+DQogICAgPERJVj48U1BBTj5JIHdv dWxkIHN1cHBvcnQgdGhhdCBkaXJlY3Rpb24gYW5kIHN0cnVjdHVyaW5nIA0KICAgIHByb3Bvc2Fs LjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxCUj48U1BBTj48L1NQQU4+PC9ESVY+DQogICAgPERJ Vj48U1BBTj5TaWRlIGNvbW1lbnQgdG8gdGhlIG5vdGlvbiBvZiAiZW5kIHN5c3RlbSBtZXRyaWMi OjwvU1BBTj48L0RJVj4NCiAgICA8RElWPldlIHNob3VsZCBiZSBjYXJlZnVsbHkgYmVjYXVzZSBp dCBjb3VsZCBiZSBpbnRlcnByZXRhdGVkIGluIHR3byANCiAgICBkaXJlY3Rpb25zOjwvRElWPg0K ICAgIDxESVY+YSkgbWV0cmljIHJlbGF0ZWQgdG8gUlRQIHRvcG9sb2d5ICJSVFAgZW5kIHN5c3Rl bSI8L0RJVj4NCiAgICA8RElWPmIpIG1ldHJpYyByZWxhdGVkIHRvIHVzZXIgZXF1aXBtZW50PC9E SVY+DQogICAgPERJVj48QlI+PC9ESVY+DQogICAgPERJVj5UaGVyZSdzIGEgc3VidGxlIGRpZmZl cmVuY2UgYmV0d2VlbiBib3RoLCB0aGUgIlJUUCBlbmQgc3lzdGVtIiBGVU5DVElPTiANCiAgICBj b3VsZCBiZSBsb2NhdGVkIGluIG11bHRpcGxlIGRpZmZlcmVudCBwaHlzaWNhbCBlbnRpdGllcyBs aWtlIHVzZXIgDQogICAgZXF1aXBtZW50LCBidXQgYWxzbyBSVFAtdG8tWCBnYXRld2F5IGVxdWlw bWVudC4gVGhlIGxhdGVyIG9uZXMgYXJlIG5vdCANCiAgICBsb2NhdGVkIGF0IHRoZSBlbmQgb2Yg dGhlIG92ZXJhbGwgY29tbXVuaWNhdGlvbiBwYXRoLjwvRElWPg0KICAgIDxESVY+Q29uY2x1c2lv biBmb3IgdGhpcyBleGFtcGxlOiBlLmcuIFFvRSBtZXRyaWNzIChhcyBhcHBsaWNhdGlvbiBsZXZl bCANCiAgICBtZXRyaWNzKSBtaWdodCBiZSBtb25pdG9yZWQgaW4gYW4gIlJUUCBlbmQgc3lzdGVt IiB3aGVuIGxvY2F0ZWQgaW4gdXNlciANCiAgICBlcXVpcG1lbnQsIGJ1dCBub3QgaWYgIlJUUCBl bmQgc3lzdGVtIiB3b3VsZCBiZSBsb2NhdGVkIGluIG5ldHdvcmsgbGV2ZWwgDQogICAgZXF1aXBt ZW50LiBDb25zZXF1ZW50bHksIHRoZSBhc3NvY2lhdGlvbiBvZiBRb0UgbWV0cmljcyBhcyAiZW5k IHN5c3RlbSANCiAgICBtZXRyaWNzIiB3b3VsZCBiZSBhbWJpZ3VvdXMuPC9ESVY+DQogICAgPERJ Vj48QlI+PC9ESVY+DQogICAgPERJVj5NeSBmZWVsaW5nOjwvRElWPg0KICAgIDxESVY+d2UgZG9u J3QgbmVlZCBuZWNlc3NhcmlseSB0aGUgY29uY2VwdCBvZiBhbiAiZW5kIHN5c3RlbSBtZXRyaWMi LCBidXQgd2UgDQogICAgbmVlZCBhIGxvY2F0aW9uIGNvbmNlcHQgZm9yIFJUUCBtb25pdG9ycyB3 aXRoIHJlc3BlY3QgdG8gdGhlIHRvcG9sb2d5IG9mIHRoZSANCiAgICBlbmQtdG8tZW5kIGNvbW11 bmljYXRpb24gcGF0aCAoIndoaWNoIGFnYWluIG1pZ2h0IGJlIGNvbXBsZXRlbHkgZTJlIFJUUCAN CiAgICBiYXNlZCBvciBzb21lIHNlZ21lbnRzIG1pZ2h0IGJlIG5vbi1SVFAgLi4uIikuPC9ESVY+ DQogICAgPERJVj48QlI+PC9ESVY+DQogICAgPERJVj4tQWxicmVjaHQ8QlI+PFNQQU4+PC9TUEFO PjwvRElWPg0KICAgIDxESVY+PFNQQU4+PEJSPjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxCUj4N CiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigxNiwxNiwyNTUp IDJweCBzb2xpZDsgTUFSR0lOLVRPUDogNXB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxF RlQ6IDVweCI+DQogICAgICA8RElWIA0KICAgICAgc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVy IE5ldywgY291cmllciwgbW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWY7IEZPTlQtU0laRTog MTBwdCI+DQogICAgICA8RElWIA0KICAgICAgc3R5bGU9IkZPTlQtRkFNSUxZOiB0aW1lcyBuZXcg cm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWY7IEZPTlQtU0laRTogMTJwdCI+DQogICAgICA8 RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yIGZhY2U9QXJpYWw+DQogICAgICA8SFIgU0laRT0xPg0K ICAgICAgPEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Wb246PC9TUEFOPjwvQj4g Q29saW4gUGVya2lucyAmbHQ7PEEgDQogICAgICBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5v cmciPmNzcEBjc3BlcmtpbnMub3JnPC9BPiZndDs8QlI+PEI+PFNQQU4gDQogICAgICBzdHlsZT0i Rk9OVC1XRUlHSFQ6IGJvbGQiPkFuOjwvU1BBTj48L0I+IFFpbiBXdSAmbHQ7PEEgDQogICAgICBo cmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L0E+Jmd0 OyA8QlI+PEI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkNDOjwvU1BB Tj48L0I+IEFsYnJlY2h0IFNjaHdhcnogJmx0OzxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmFsYnJl Y2h0c2Nod2FyekB5YWhvby5kZSI+YWxicmVjaHRzY2h3YXJ6QHlhaG9vLmRlPC9BPiZndDs7IA0K ICAgICAgPEEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9BPjsgPEEg DQogICAgICBocmVmPSJtYWlsdG86eHJibG9ja0BpZXRmLm9yZyI+eHJibG9ja0BpZXRmLm9yZzwv QT4gPEJSPjxCPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5HZXNlbmRl dDo8L1NQQU4+PC9CPiAyMzoyMSBNaXR0d29jaCwgMjMuTWFpIA0KICAgICAgMjAxMjxCUj48Qj48 U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkJldHJlZmY6PC9TUEFOPjwvQj4gUmU6IA0K ICAgICAgW0FWVENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiANCiAgICAgIGRyYWZ0LWlldGYt YXZ0Y29yZS1tb25hcmNoLTEzPEJSPjwvRk9OVD48L0RJVj48QlI+UWluLDxCUj48QlI+VGhlIHRl eHQgeW91IA0KICAgICAgcHJvcG9zZSBpcyBiZXR0ZXIsIGJ1dCBJJ20gc3RpbGwgbm90IHN1cmUg aXQncyBjbGVhci4gSSB3b25kZXIgaWYgaXQgbWF5IA0KICAgICAgYmUgd29ydGggc3BsaXR0aW5n IHRoYXQgc2VjdGlvbiBpbnRvIHNldmVyYWwgcGFyYWdyYXBocywgYW5kIGdpdmluZyBhIA0KICAg ICAgbGl0dGxlIG1vcmUgZGVzY3JpcHRpb24uIE9uZSBwYXJhZ3JhcGggY291bGQgZGlzY3VzcyB0 aGUgcG9zc2libGUgDQogICAgICBsb2NhdGlvbnMgZm9yIG1vbml0b3JzOiBpbiBlbmQtc3lzdGVt cywgaW4gbWlkZGxlYm94ZXMgdGhhdCBhcmUgYW4gYWN0aXZlIA0KICAgICAgcGFydCBvZiBhbiBS VFAgc2Vzc2lvbiAoZS5nLiwgUlRQIG1peGVycyBvciB0cmFuc2xhdG9ycyksIG9yIGluIA0KICAg ICAgdGhpcmQtcGFydHkgZGV2aWNlcyB0aGF0IHBhc3NpdmVseSBtb25pdG9yIGFuIFJUUCBzZXNz aW9uLiBGb3IgZWFjaCBvZiANCiAgICAgIHRoZXNlIGxvY2F0aW9ucywgeW91IGNvdWxkIHRoZW4g aW5jbHVkZSBhIHBhcmFncmFwaCB0aGF0IGJyaWVmbHkgZXhwbGFpbnMgDQogICAgICB0aGUgdXNl cyBmb3IgbW9uaXRvcnMgaW4gdGhhdCBsb2NhdGlvbiwgYW5kIHRoZSB0eXBlcyBvZiBtZXRyaWNz IHRoZXkncmUgDQogICAgICBzdWl0ZWQgdG8gbW9uaXRvcmluZywgcGVyaGFwcyB3aXRoIGV4YW1w bGVzLiANCiAgICAgIDxCUj48QlI+Q29saW48QlI+PEJSPjxCUj48QlI+PEJSPk9uIDIzIE1heSAy MDEyLCBhdCAwNDoyMiwgUWluIFd1IA0KICAgICAgd3JvdGU6PEJSPiZndDsgSGksPEJSPiZndDsg VGFrZSBSb2JlcnQsQ29saW4gYW5kIEFsYnJlY2hldCdzIGNvbW1lbnRzIGludG8gDQogICAgICBh Y2NvdW50LCBJIHByb3Bvc2UgdG8gcmV3cml0ZSBzZWN0aW9uIDMuMyB3aXRoIHRoZSBmb2xsb3dp bmcgDQogICAgICBjaGFuZ2VzOjxCUj4mZ3Q7IE9MRCBURVhUOjxCUj4mZ3Q7ICI8QlI+Jmd0OyAz LjMuJm5ic3A7IFJUUCANCiAgICAgIFNlbmRlci9SZWNlaXZlciBlbnRpdGllcyBsb2NhdGVkIGlu IG5ldHdvcmsgbm9kZXM8QlI+Jmd0OyA8QlI+Jmd0OyZuYnNwOyANCiAgICAgIFRoZSBsb2NhdGlv biBvZiB0aGUgUlRQIFNlbmRlci9SZWNlaXZlciBlbnRpdGllcyBtYXkgaW1wYWN0IGEgc2V0IA0K ICAgICAgb2Y8QlI+Jmd0OyZuYnNwOyBtZWFuaW5nZnVsIG1ldHJpY3MuJm5ic3A7IEZvciBpbnN0 YW5jZSwgYXBwbGljYXRpb24gbGV2ZWwgDQogICAgICBtZXRyaWNzIGZvciBRb0U8QlI+Jmd0OyZu YnNwOyByZWxhdGVkIHBlcmZvcm1hbmNlIHBhcmFtZXRlcnMgYXJlIHVuZGVyIA0KICAgICAgbW9z dCBjb25kaXRpb25zIG1lYXN1cmVkIGF0PEJSPiZndDsmbmJzcDsgdGhlIHVzZXIgZGV2aWNlIHRo YXQgcmVjZWl2ZXMgDQogICAgICBSVFAgZGF0YSBwYWNrZXRzLiZuYnNwOyBIb3dldmVyIGluIHNv bWU8QlI+Jmd0OyZuYnNwOyBjYXNlcywgZ2l2ZW4gdGhlIA0KICAgICAgZmFjdG9ycyAoICJtZWFz dXJlbWVudCBwb2ludCBsb2NhdGlvbiIsICJtZWFzdXJlbWVudDxCUj4mZ3Q7Jm5ic3A7IG1vZGVs IA0KICAgICAgbG9jYXRpb24iLCAiYXdhcmVuZXNzIG9mIGNvbnRlbnQgaW5mb3JtYXRpb24iLCBl dGMgW1AuTkFNU10pPEJSPiZndDsmbmJzcDsgDQogICAgICB0YWtlbiBpbnRvIGFjY291bnQsIHN1 Y2ggbWV0cmljcyBtYXkgYmUgbWVhc3VyZWQgaW4gYSBuZXR3b3JrIA0KICAgICAgbm9kZTxCUj4m Z3Q7Jm5ic3A7IGluc3RlYWQgb2YgYSB1c2VyIGRldmljZS48QlI+Jmd0OyA8QlI+Jmd0OyAiPEJS PiZndDsgDQogICAgICBORVcgVEVYVDo8QlI+Jmd0OyAiPEJSPiZndDsgMy4zLiBNZWFzdXJlbWVu dCBwb2ludCBvZiB0aGUgUlRQIG1vbml0b3IgDQogICAgICB3aXRoaW4gdGhlIG5ldHdvcmsuPEJS PiZndDsgPEJSPiZndDsgVGhlIFJUUCBtb25pdG9ycyBhcmUgc3ByZWFkIGFjcm9zcyBhIA0KICAg ICAgc2luZ2xlIGRvbWFpbihlLmcuLCBuZXR3b3JrJm5ic3A7IGRvbWFpbikgb3IgPEJSPiZndDsg bXVsdGlwbGUgZG9tYWlucyANCiAgICAgIChlLmcuLCBiZXR3ZWVuIG5ldHdvcmsgZG9tYWluIGFu ZCBzZXJ2aWNlIGRvbWFpbilpbiB0aGUgbmV0d29yay48QlI+Jmd0OyANCiAgICAgIFRoZSBwZXJm b3JtYW5jZSBNZXRyaWNzIHJlcG9ydGVkIGZyb20gdGhlIFJUUCBtb25pdG9yIGNhbiBiZSBkaXZp ZGVkIGludG8gDQogICAgICBlbmQgc3lzdGVtIDxCUj4mZ3Q7IG1ldHJpY3MsIGFwcGxpY2F0aW9u IGxldmVsIG1ldHJpY3MsIHRyYW5zcG9ydCBsZXZlbCANCiAgICAgIG1ldHJpY3MuIFNvbWUgb2Yg dGhlc2UgbWV0cmljcyA8QlI+Jmd0OyBtYXkgYmUgc3BlY2lmaWMgdG8gdGhlIG1lYXN1cmVtZW50 IA0KICAgICAgcG9pbnQgb2YgdGhlIFJUUCBtb25pdG9yIG9yIGRlcGVuZCBvbiB3aGVyZSA8QlI+ Jmd0OyB0aGUgUlRQIG1vbml0b3JzIGFyZSANCiAgICAgIGxvY2F0ZWQgaW4gdGhlIG5ldHdvcmsu IEZvciBpbnN0YW5jZSwgZW5kIHN5c3RlbSBtZXRyaWNzIGFyZSBvbmx5PEJSPiZndDsgDQogICAg ICBhdmFpbGFibGUgb3IgbWVhc3VyZWQgYXQgdGhlIFJUUCBlbmQgc3lzdGVtIG9yIHRlcm1pbmFs IGRldmljZS4gDQogICAgICBBcHBsaWNhdGlvbiBsZXZlbDxCUj4mZ3Q7IG1ldHJpY3MgdGhhdCBy ZWZsZWN0IGVuZCB0byBlbmQgdXNlciBleHBlcmllbmNlIA0KICAgICAgYXQgdGhlIGFwcGxpY2F0 aW9uLWxldmVsIGFyZSBtZWFzdXJlZCA8QlI+Jmd0OyBtb3JlIHByZWNpc2Ugb3IgbGVzcyANCiAg ICAgIGNvbXBsaWNhdGVkIGF0IHRoZSBSVFAgZW5kIHN5c3RlbSB0aGFuIG1lYXN1cmVkIGZyb20g aW50ZXJtZWRpYXJ5IDxCUj4mZ3Q7IA0KICAgICAgc3lzdGVtIChlLmcuLCB0aGUgUlRQIG1lZGlh IHRyYW5zbGF0b3IpIGluIHRoZSBuZXdvcmsuIEZvciB0cmFuc3BvcnQgbGV2ZWwgDQogICAgICBt ZXRyaWNzLCB0YWtlczxCUj4mZ3Q7IG9uZSB3YXkgZGVsYXkgYXMgYW4gZXhhbXBsZSwgaW4gdGhl IGFzeW1tZXRyaWMgDQogICAgICBuZXR3b3JrLCB0aGUgb25lIHdheSBkZWxheSBtZWFzdXJlZCA8 QlI+Jmd0OyBhdCB0aGUgUlRQIHNlbmRlciBlbnRpdHkgaXMgDQogICAgICBkaWZmZXJlbnQgZnJv bSBvbmUgd2F5IGRlbGF5IG1lYXN1cmVkIGF0IHRoZSBSVFAgPEJSPiZndDsgcmVjZWl2ZXIgZW50 aXR5LiANCiAgICAgIDxCUj4mZ3Q7ICI8QlI+Jmd0OyA8QlI+Jmd0OyBSZWdhcmRzITxCUj4mZ3Q7 IC1RaW48QlI+Jmd0OyAtLS0tLSBPcmlnaW5hbCANCiAgICAgIE1lc3NhZ2UgLS0tLS0gPEJSPiZn dDsgRnJvbTogIkNvbGluIFBlcmtpbnMiICZsdDs8QSANCiAgICAgIGhyZWY9Im1haWx0bzpjc3BA Y3NwZXJraW5zLm9yZyIgDQogICAgICB5bWFpbHRvPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmci PmNzcEBjc3BlcmtpbnMub3JnPC9BPiZndDs8QlI+Jmd0OyBUbzogDQogICAgICAiUWluIFd1IiAm bHQ7PEEgaHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSIgDQogICAgICB5bWFpbHRvPSJt YWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L0E+Jmd0OzxCUj4m Z3Q7IENjOiANCiAgICAgICJBbGJyZWNodCBTY2h3YXJ6IiAmbHQ7PEEgaHJlZj0ibWFpbHRvOmFs YnJlY2h0c2Nod2FyekB5YWhvby5kZSIgDQogICAgICB5bWFpbHRvPSJtYWlsdG86YWxicmVjaHRz Y2h3YXJ6QHlhaG9vLmRlIj5hbGJyZWNodHNjaHdhcnpAeWFob28uZGU8L0E+Jmd0OzsgDQogICAg ICAmbHQ7PEEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyIgDQogICAgICB5bWFpbHRvPSJtYWls dG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L0E+Jmd0OzxCUj4mZ3Q7IFNlbnQ6IFR1ZXNk YXksIA0KICAgICAgTWF5IDIyLCAyMDEyIDc6MDQgUE08QlI+Jmd0OyBTdWJqZWN0OiBSZTogW0FW VENPUkVdIFN1YmplY3Q6IEFEIHJldmlldyBvZiANCiAgICAgIGRyYWZ0LWlldGYtYXZ0Y29yZS1t b25hcmNoLTEzPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgSSBhbHNvIGRvbid0IGFncmVlIA0K ICAgICAgd2l0aCBkZWxldGluZyBTZWN0aW9uIDMuMyBmcm9tIHRoZSBtb25hcmNoIGRyYWZ0LiA8 QlI+Jmd0OyA8QlI+Jmd0OyBUaGUgDQogICAgICBhcmNoaXRlY3R1cmUgbmVlZHMgdG8gYmUgY2xl YXIgdGhhdCB0aGVyZSBhcmUgdmFsaWQgc2NlbmFyaW9zIGZvciBSVFAgDQogICAgICBtb25pdG9y aW5nIHdpdGhpbiBhIG5ldHdvcmssIGVpdGhlciBpbiBzb21lIG1pZGRsZWJveCB0aGF0IGNvbXBy aXNlcyBwYXJ0IA0KICAgICAgb2YgYW4gUlRQIHNlc3Npb24sIG9yIGluIGEgdGhpcmQtcGFydHkg bW9uaXRvcmluZyBkZXZpY2UgdXNlZCBmb3IgbmV0d29yayANCiAgICAgIG1hbmFnZW1lbnQgcHVy cG9zZXMuIFNlY3Rpb24gMy4zIGlzIGEgcmVhc29uYWJsZSBwbGFjZSB0byBkaXNjdXNzIHRoZXNl LCANCiAgICAgIGFuZCB0byBleHBsYWluIHdoeSB0aGUgbWV0cmljcyB0aGF0IGNhbiBiZSByZXBv cnRlZCBmcm9tIG1pZGRsZWJveGVzIGFyZSANCiAgICAgIGRpZmZlcmVudCB0byB0aG9zZSB0aGF0 IGNhbiBiZSBjYXB0dXJlZCBhdCBlbmQgc3lzdGVtcy48QlI+Jmd0OyA8QlI+Jmd0OyANCiAgICAg IENvbGluPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgT24gMjIgTWF5IDIwMTIs IGF0IDA3OjUzLCBRaW4gV3UgDQogICAgICB3cm90ZTo8QlI+Jmd0OyZndDsgSGksOjxCUj4mZ3Q7 Jmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICAgICAgPEJSPiZndDsmZ3Q7IEZy b206ICJBbGJyZWNodCBTY2h3YXJ6IiAmbHQ7PEEgDQogICAgICBocmVmPSJtYWlsdG86YWxicmVj aHRzY2h3YXJ6QHlhaG9vLmRlIiANCiAgICAgIHltYWlsdG89Im1haWx0bzphbGJyZWNodHNjaHdh cnpAeWFob28uZGUiPmFsYnJlY2h0c2Nod2FyekB5YWhvby5kZTwvQT4mZ3Q7PEJSPiZndDsmZ3Q7 IA0KICAgICAgVG86ICZsdDs8QSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIiANCiAg ICAgIHltYWlsdG89Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNv bTwvQT4mZ3Q7PEJSPiZndDsmZ3Q7IA0KICAgICAgQ2M6ICZsdDs8QSBocmVmPSJtYWlsdG86YXZ0 QGlldGYub3JnIiANCiAgICAgIHltYWlsdG89Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRm Lm9yZzwvQT4mZ3Q7OyAmbHQ7PEEgDQogICAgICBocmVmPSJtYWlsdG86cmpzcGFya3NAbm9zdHJ1 bS5jb20iIA0KICAgICAgeW1haWx0bz0ibWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tIj5yanNw YXJrc0Bub3N0cnVtLmNvbTwvQT4mZ3Q7PEJSPiZndDsmZ3Q7IA0KICAgICAgU2VudDogVHVlc2Rh eSwgTWF5IDIyLCAyMDEyIDExOjE4IEFNPEJSPiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbQVZUQ09S RV0gDQogICAgICBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFy Y2gtMTM8QlI+Jmd0OyZndDsgDQogICAgICA8QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IERlYXIg QWxsLDxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgY29uY2VybmluZyANCiAgICAgIHRoZSByZXNv bHV0aW9uIHByb3Bvc2FsIGZvciBjbGF1c2UgMy4zOjxCUj4mZ3Q7Jmd0OyBJIGRvbid0IGFncmVl IGluIGp1c3QgDQogICAgICBkZWxldGluZyBhZ2FpbiB0aGF0IHNlY3Rpb24hPEJSPiZndDsmZ3Q7 IFRoZXJlIHdhcyBxdWl0ZSBhIGxvbmcgZGViYXRlIGZvciANCiAgICAgIGluY29ycG9yYXRpbmcg c3VjaCBhIGNsYXVzZS48QlI+Jmd0OyZndDsgVGhlIG9yaWdpbmFsIHRleHQgcHJvcG9zYWwgd2Fz IA0KICAgICAgbXVjaCBtb3JlIGRldGFpbGVkLiBQZXJoYXBzIHRoZSBzaG9ydGVuaW5nIHRvIGp1 c3QgYSBzaW5nbGUgcGFyYWdyYXBoIGlzIA0KICAgICAgdGhlIG1haW4gY2F1c2UgZm9yIHVuY2xh cml0eS48QlI+Jmd0OyZndDsgVGh1cywgaW5zdGVhZCBvZiByZW1vdmluZyANCiAgICAgIHByZXZp b3VzIGFncmVlZCB0ZXh0LCB3ZSBqdXN0IHJhdGhlciBleHRlbmQgaXQgYWdhaW4uPEJSPiZndDsm Z3Q7IA0KICAgICAgPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBbUWluXTogPEJSPiZndDsmZ3Q7 IFRoZSByZWFzb24gSSBwcm9wb3NlIHRvIA0KICAgICAgcmVtb3ZlIHRoZSBzZWN0aW9uIDMuMyBp cyA8QlI+Jmd0OyZndDsgYS4gSSB0aGluayBSb2JlcnQgaXMgY29ycmVjdC4gVGhlIA0KICAgICAg c2V0IG9mIG1lYW5pbmdmdWwgbWV0cmljcyBpc24ndCBjaGFuZ2VkIGF0IGFsbCZuYnNwOyB3aGVy ZXZlciB5b3UgY29sbGVjdCANCiAgICAgIHRoZW0uIEl0IHNlZW1zIGxpdHRsZSBzZW5zZSA8QlI+ Jmd0OyZndDsmbmJzcDsgdG8gc2F5ICJ0aGUgbG9jYXRpb24gb2YgdGhlIA0KICAgICAgUlRQIFNl bmRlci9SZWNlaXZlciBlbnRpdGllcyBtYXkgaW1wYWN0IGEgc2V0IG9mIG1lYW5pbmdmdWwgbWV0 cmljcy4gIiANCiAgICAgIDxCUj4mZ3Q7Jmd0OyBiLiBXaGVyZSB0byBnYXRoZXIgb3IgbWVhc3Vy ZSBtZXRyaWNzIGNhbiBiZSBpbmRpY2F0ZWQgYnkgdGhlIA0KICAgICAgZGVmaW5pdGlvbiBvZiBU cmFuc3BvcnQgbWV0cmljcywgRW5kIHN5c3RlbSBtZXRyaWNzIGFuZCBhcHBsaWNhdGlvbiBsZXZl bCANCiAgICAgIG1ldHJpY3MuPEJSPiZndDsmZ3Q7IGMuIFNlY3Rpb24gMy4zIHNlZW1zIHRvIGRp c2N1c3Mgd2hlcmUgdG8gZ2F0aGVyIHdoYXQgDQogICAgICBtZXRyaWNzLiBSZWNvbW1lbmRhdGlv biBJVFUtVCBHLjEwODEgaGF2ZSBhbHJlYWR5IGRlZmluZWQgZml2ZSBtb25pdG9yaW5nIA0KICAg ICAgcG9pbnRzIDxCUj4mZ3Q7Jmd0OyZuYnNwOyB3aGVyZSB0aGUgcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnRzIGNhbiBiZSANCiAgICAgIG1hZGUuPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyZndDsg SSB0aGluayB0aGUgZGVmaW5pdGlvbiBvZiBhcHBsaWNhdGlvbiANCiAgICAgIGxldmVsIG1ldHJp Y3MgaGFzIGFscmVhZHkgY2xhcmlmaWVkIHRoYXQmbmJzcDsgYXBwbGljYXRpb24gbGV2ZWwgbWV0 cmljcyANCiAgICAgIGlzIG5vcm1hbGx5IGdhdGhlcmVkIGZyb20gdXNlciBlbmRwb2ludC4gPEJS PiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBOby4gV2UgDQogICAgICBkaWQgZGlzY3VzcyB0aGlzIGFs cmVhZHkgZXh0ZW5zaXZlbHkuPEJSPiZndDsmZ3Q7IEFuIFJUUCBtZWRpYSB0cmFuc2xhdG9yIA0K ICAgICAgY291bGQgcHJvdmlkZSBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGJlY2F1c2UgZS5n LiB0ZXJtaW5hdGluZyB0aGUgDQogICAgICBhcHBsaWNhdGlvbiBwcm90b2NvbCBsYXllci48QlI+ Jmd0OyZndDsgU3VjaCBhbiBSVFAgdG9wb2xvZ3kgaXMgTk9UIA0KICAgICAgbG9jYXRlZCBpbiBh biB1c2VyIGVuZHBvaW50ITxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgW1Fpbl06IFNvcnJ5LCBJ IA0KICAgICAgc2hvdWxkIGNvcnJlY3QgbWUgdG8gc2F5IFFvRSBtZXRyaWMgaXMgdXN1c2FsbHkg bWVhc3VyZWQgYXQgdGhlIHVzZXIgDQogICAgICBlbmRwb2ludC48QlI+Jmd0OyZndDsgPEJSPiZn dDsmZ3Q7IFJlZ2FyZHMsPEJSPiZndDsmZ3Q7IA0KICAgICAgQWxicmVjaHQ8QlI+Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyZndDsgW0RhdGUgDQogICAg ICBQcmV2XVtEYXRlIE5leHRdW1RocmVhZCBQcmV2XVtUaHJlYWQgTmV4dF1bRGF0ZSBJbmRleF1b VGhyZWFkIEluZGV4XSANCiAgICAgIDxCUj4mZ3Q7Jmd0OyBSZTogW0FWVENPUkVdIFN1YmplY3Q6 IEFEIHJldmlldyBvZiANCiAgICAgIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzPEJSPiZn dDsmZ3Q7IA0KICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyZn dDsgPEJSPiZndDsmZ3Q7ICogVG86IFJvYmVydCANCiAgICAgIFNwYXJrcyAmbHQ7cmpzcGFya3Mg YXQgPEEgaHJlZj0iaHR0cDovL25vc3RydW0uY29tIj5ub3N0cnVtLmNvbTwvQT4mZ3Q7LCANCiAg ICAgIElFVEYgQVZUQ29yZSBXRyAmbHQ7YXZ0IGF0IDxBIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyI+ aWV0Zi5vcmc8L0E+Jmd0OywgDQogICAgICAmbHQ7ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gg YXQgPEEgDQogICAgICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciPnRvb2xzLmlldGYub3Jn PC9BPiZndDs8QlI+Jmd0OyZndDsgKiBTdWJqZWN0OiANCiAgICAgIFJlOiBbQVZUQ09SRV0gU3Vi amVjdDogQUQgcmV2aWV3IG9mIA0KICAgICAgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTM8 QlI+Jmd0OyZndDsgKiBGcm9tOiBRaW4gV3UgJmx0O2JpbGwud3UgYXQgPEEgDQogICAgICBocmVm PSJodHRwOi8vaHVhd2VpLmNvbSI+aHVhd2VpLmNvbTwvQT4mZ3Q7PEJSPiZndDsmZ3Q7ICogRGF0 ZTogRnJpLCAxOCANCiAgICAgIE1heSAyMDEyIDE4OjM3OjU2ICswODAwPEJSPiZndDsmZ3Q7ICog RGVsaXZlcmVkLXRvOiBhdnQgYXQgPEEgDQogICAgICBocmVmPSJodHRwOi8vaWV0ZmEuYW1zbC5j b20iPmlldGZhLmFtc2wuY29tPC9BPjxCUj4mZ3Q7Jmd0OyAqIA0KICAgICAgTGlzdC1hcmNoaXZl OiAmbHQ7PEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2F2dCIg DQogICAgICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9hdnQ8L0E+Jmd0OzxCUj4mZ3Q7Jmd0OyANCiAgICAgICogTGlzdC1oZWxwOiAmbHQ7bWFpbHRv OjxBIGhyZWY9Im1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZyIgDQogICAgICB5bWFpbHRvPSJt YWlsdG86YXZ0LXJlcXVlc3RAaWV0Zi5vcmciPmF2dC1yZXF1ZXN0QGlldGYub3JnPC9BPj9zdWJq ZWN0PWhlbHAmZ3Q7PEJSPiZndDsmZ3Q7IA0KICAgICAgKiBMaXN0LWlkOiBBdWRpby9WaWRlbyBU cmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZSAmbHQ7PEEgDQogICAgICBocmVmPSJodHRwOi8vYXZ0 LmlldGYub3JnIj5hdnQuaWV0Zi5vcmc8L0E+Jmd0OzxCUj4mZ3Q7Jmd0OyAqIExpc3QtcG9zdDog DQogICAgICAmbHQ7bWFpbHRvOjxBIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciIA0KICAgICAg eW1haWx0bz0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9BPiZndDs8QlI+Jmd0 OyZndDsgKiANCiAgICAgIExpc3Qtc3Vic2NyaWJlOiAmbHQ7PEEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQiIA0KICAgICAgdGFyZ2V0PV9ibGFuaz5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvQT4mZ3Q7LCANCiAgICAgICZs dDttYWlsdG86PEEgaHJlZj0ibWFpbHRvOmF2dC1yZXF1ZXN0QGlldGYub3JnIiANCiAgICAgIHlt YWlsdG89Im1haWx0bzphdnQtcmVxdWVzdEBpZXRmLm9yZyI+YXZ0LXJlcXVlc3RAaWV0Zi5vcmc8 L0E+P3N1YmplY3Q9c3Vic2NyaWJlJmd0OzxCUj4mZ3Q7Jmd0OyANCiAgICAgICogTGlzdC11bnN1 YnNjcmliZTogJmx0OzxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vb3B0aW9u cy9hdnQiIA0KICAgICAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L29wdGlvbnMvYXZ0PC9BPiZndDssIA0KICAgICAgJmx0O21haWx0bzo8QSBocmVmPSJtYWlsdG86 YXZ0LXJlcXVlc3RAaWV0Zi5vcmciIA0KICAgICAgeW1haWx0bz0ibWFpbHRvOmF2dC1yZXF1ZXN0 QGlldGYub3JnIj5hdnQtcmVxdWVzdEBpZXRmLm9yZzwvQT4/c3ViamVjdD11bnN1YnNjcmliZSZn dDs8QlI+Jmd0OyZndDsgDQogICAgICAqIFJlZmVyZW5jZXM6ICZsdDs0RkIyRTMyMy4zMDkwNDA2 IGF0IDxBIA0KICAgICAgaHJlZj0iaHR0cDovL25vc3RydW0uY29tIj5ub3N0cnVtLmNvbTwvQT4m Z3Q7PEJSPiZndDsmZ3Q7IA0KICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IA0KICAgICAgSGksUm9iZXJ0OjxCUj4mZ3Q7Jmd0OyBU aGFuayBmb3IgeW91ciB2YWx1YWJsZSByZXZpZXcuIHBsZWFzZSBzZWUgbXkgDQogICAgICByZXBs aWVzIGlubGluZSBiZWxvd3MuIFJlZ2FyZHMhPEJSPiZndDsmZ3Q7IC1RaW48QlI+Jmd0OyZndDsg LS0tLS0gDQogICAgICBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDxCUj4mZ3Q7Jmd0OyBGcm9tOiAi Um9iZXJ0IFNwYXJrcyIgJmx0O3Jqc3BhcmtzIGF0IA0KICAgICAgPEEgaHJlZj0iaHR0cDovL25v c3RydW0uY29tIj5ub3N0cnVtLmNvbTwvQT4mZ3Q7PEJSPiZndDsmZ3Q7IFRvOiAiSUVURiANCiAg ICAgIEFWVENvcmUgV0ciICZsdDthdnQgYXQgPEEgaHJlZj0iaHR0cDovL2lldGYub3JnIj5pZXRm Lm9yZzwvQT4mZ3Q7OyANCiAgICAgICZsdDtkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhdCA8 QSANCiAgICAgIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyI+dG9vbHMuaWV0Zi5vcmc8L0E+ Jmd0OzxCUj4mZ3Q7Jmd0OyBTZW50OiANCiAgICAgIFdlZG5lc2RheSwgTWF5IDE2LCAyMDEyIDc6 MTMgQU08QlI+Jmd0OyZndDsgU3ViamVjdDogW0FWVENPUkVdIFN1YmplY3Q6IEFEIA0KICAgICAg cmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTEzICZndDsgU3VtbWFyeTogVGhl cmUgYXJlIGlzc3VlcyB0byANCiAgICAgIHJlc29sdmUgd2l0aCBhIHJldmlzZWQgSUQgYmVmb3Jl IDxCUj4mZ3Q7Jmd0OyZndDsgcHJvZ3Jlc3NpbmcgdG8gSUVURiANCiAgICAgIExDLjxCUj4mZ3Q7 Jmd0OyZndDsgPEJSPiZndDsmZ3Q7Jmd0OyBJdCdzIGEgc3RydWdnbGUgdG8gc2VlIHRoZSANCiAg ICAgIF9hcmNoaXRlY3R1cmVfIHRoaXMgZG9jdW1lbnQgaXMgc3VwcG9zZWQgdG8gPEJSPiZndDsm Z3Q7Jmd0OyBkZXNjcmliZS4gSSANCiAgICAgIHN1c3BlY3QgbW9zdCBvZiB0aGUgd29ya2luZyBn cm91cCBlbmVyZ3kgd2VudCBpbnRvIFNlY3Rpb24gNSANCiAgICAgIDxCUj4mZ3Q7Jmd0OyZndDsg KHRoZSBndWlkZWxpbmVzIGZvciB3cml0aW5nIFhSIGJsb2NrIGRlZmluaXRpb25zKSAtIHRoZSAN CiAgICAgIHJlc3Qgb2YgdGhlIDxCUj4mZ3Q7Jmd0OyZndDsgZG9jdW1lbnQgbmVlZHMgYSBzaW1p bGFyIGxldmVsIG9mIGF0dGVudGlvbiANCiAgICAgIHRvIGRldGFpbC48QlI+Jmd0OyZndDsmZ3Q7 IDxCUj4mZ3Q7Jmd0OyZndDsgVGhlcmUgYXJlIHR3byBtYWpvciBpc3N1ZXMgDQogICAgICB0aGF0 IEkndmUgdGFnZ2VkIHdpdGggYSAoKikuIEkgZm9sbG93ZWQgYSA8QlI+Jmd0OyZndDsmZ3Q7IG1v c3RseSANCiAgICAgIGRvY3VtZW50LW9yZGVyIGZsb3cgaW5zdGVhZCBvZiBncm91cGluZyB0aGUg bWFqb3IgaXNzdWVzIGF0IHRoZSANCiAgICAgIHRvcC48QlI+Jmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7 Jmd0OyZndDsgKCopIEdpdmVuIHRoZSBkb2N1bWVudCdzIHRpdGxlLCBpdCANCiAgICAgIHNob3Vs ZCBiZSB2ZXJ5IGVhc3kgdG8gYW5zd2VyICJXaGF0IDxCUj4mZ3Q7Jmd0OyZndDsgaXMgdGhlIG1v bml0b3JpbmcgDQogICAgICBhcmNoaXRlY3R1cmU/IiBmb3IgcGVvcGxlIHdobyBhcmUgcmVhZGlu ZyB0aGlzIGRyYWZ0IDxCUj4mZ3Q7Jmd0OyZndDsgZm9yIA0KICAgICAgdGhlIGZpcnN0IHRpbWUu PEJSPiZndDsmZ3Q7Jmd0OyBUaGUga2V5IG1lc3NhZ2UgaXMgdGhhdCB0aGUgbW9uaXRvcmluZyAN CiAgICAgIGFyY2hpdGVjdHVyZSBjb25zaXN0cyBvZiBNb25pdG9ycyA8QlI+Jmd0OyZndDsmZ3Q7 IHRoYXQgZXhjaGFuZ2UgDQogICAgICBpbmZvcm1hdGlvbiB1c2luZyBSVENQIE1ldHJpYyBCbG9j a3MuIFtRaW5dOiBBZ3JlZS4gJmd0O1RoZSB0ZXh0IHNob3VsZCANCiAgICAgIHNheSA8QlI+Jmd0 OyZndDsmZ3Q7IHRoYXQuIFtRaW5dOiBPa2F5LiAmZ3Q7IFRoZXJlIGlzIGEgbG90IG9mIHByb3Nl IGluIA0KICAgICAgc2VjdGlvbiAzIGFuZCB2aXN1YWwgZGV0YWlsIGluIHRoZSA8QlI+Jmd0OyZn dDsmZ3Q7IGRpYWdyYW0gaW4gRmlndXJlIDEgDQogICAgICB0aGF0IG1ha2VzIHRoYXQgZXh0cmVt ZWx5IGRpZmZpY3VsdCB0byBzZWUuIDxCUj4mZ3Q7Jmd0OyZndDsgU2ltcGxpZnlpbmcgDQogICAg ICB0aGUgZmlndXJlIGJ5IHJlbW92aW5nIHRoZSBkZXRhaWxzIGFib3V0IGFwcGxpY2F0aW9ucyBh bmQgPEJSPiZndDsmZ3Q7Jmd0OyANCiAgICAgIHRyYW5zcG9ydHMsIG9yIGF0IGxlYXN0IG1vdmlu ZyB0aGVtIHRvIGEgc2Vjb25kIGZpZ3VyZSwgbWFraW5nIHRoZSANCiAgICAgIDxCUj4mZ3Q7Jmd0 OyZndDsgTW9uaXRvciBib3hlcyBzdGFuZCBvdXQsIGFuZCBtYWtpbmcgdGhlIHR5cGVzIG9mIA0K ICAgICAgaW5mb3JtYXRpb24gZmxvd3MgKHRoZSA8QlI+Jmd0OyZndDsmZ3Q7IGFycm93cykgdmlz dWFsbHkgZGlzdGluY3RpdmUgd291bGQgDQogICAgICBoZWxwLiBTaW1wbGlmeSB0aGUgcHJvc2Ug KG11Y2ggb2YgaXQgPEJSPiZndDsmZ3Q7Jmd0OyBjb3VsZCBiZSByZW1vdmVkKSB0byANCiAgICAg IGZvY3VzIG9uIHRoYXQga2V5IG1lc3NhZ2UuIFtRaW5dOiBBZ3JlZSwgSSBwcm9wb3NlIHRvIHJl bW92ZSB0aGUgZmlndXJlIDEgDQogICAgICBhbmQgc3F1ZWV6ZSB0aGUgc2VjdGlvbiAzLjEgYXMg Zm9sbG93czogIiAzLjEuIE92ZXJ2aWV3IFRoZSBSVFAgbW9uaXRvcmluZyANCiAgICAgIGFyY2hp dGVjdHVyZSBjb21wcmlzZXMgdGhlIGZvbGxvd2luZyB0d28ga2V5IGZ1bmN0aW9uYWwgY29tcG9u ZW50cyBzaG93biANCiAgICAgIGJlbG93OiBvIFJUUCBNb25pdG9yIG8gUlRQIE1ldHJpYyBCbG9j ayBTdHJ1Y3R1cmUgUlRQIE1vbml0b3IgaXMgdGhlIA0KICAgICAgZnVuY3Rpb25hbCBjb21wb25l bnQgZGVmaW5lZCBpbiB0aGUgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCANCiAgICAgIFtS RkMzNTUwXS4gSXQgYWN0cyBhcyBhIHNvdXJjZSBvZiBpbmZvcm1hdGlvbiBnYXRoZXJlZCBmb3Ig bW9uaXRvcmluZyANCiAgICAgIHB1cnBvc2VzIGFuZCBleGNoYW5nZXMgaW5mb3JtYXRpb24gd2l0 aCB0aGUgb3RoZXIgUlRQIG1vbml0b3JzIHVzaW5nIFJUQ1AgDQogICAgICBNZXRyaWMgQmxvY2tz LiBBY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gb2YgbW9uaXRvciBpbiB0aGUgUlRQIFByb3Rv Y29sIA0KICAgICAgW1JGQzM1NTBdLCB0aGUgZW5kIHN5c3RlbSB0aGF0IHJ1bnMgYW4gYXBwbGlj YXRpb24gcHJvZ3JhbSB0aGF0IHNlbmRzIG9yIA0KICAgICAgcmVjZWl2ZXMgUlRQIGRhdGEgcGFj a2V0cywgYW4gaW50ZXJtZWRpYXRlLSBzeXN0ZW0gdGhhdCBmb3J3YXJkcyBSVFAgDQogICAgICBw YWNrZXRzIHRvIEVuZC1kZXZpY2VzIG9yIGEgdGhpcmQgcGFydHkgdGhhdCBvYnNlcnZlcyB0aGUg UlRQIGFuZCBSVENQIA0KICAgICAgdHJhZmZpYyBidXQgZG9lcyBub3QgbWFrZSBpdHNlbGYgdmlz aWJsZSB0byB0aGUgUlRQIFNlc3Npb24gcGFydGljaXBhbnRzIA0KICAgICAgKGkuZS4sIHRoZSB0 aGlyZCBwYXJ0eSBtb25pdG9yIGRlcGljdGVkIGluIGZpZ3VyZSAxKSBjYW4gYWN0IGFzIA0KICAg ICAgdGhlPEJSPiZndDsmZ3Q7IFJUUCBtb25pdG9yLiBUaGUgdGhpcmQgcGFydHkgbW9uaXRvciBz aG91bGQgYmUgcGxhY2VkIG9uIA0KICAgICAgdGhlIFJUUC9SVENQIHBhdGhzIGJldHdlZW4gdGhl IHNlbmRlciwgaW50ZXJtZWRpYXRlIGFuZCB0aGUgcmVjZWl2ZXIuIFRoZSANCiAgICAgIFJUUCBt b25pdG9yIGFsc28gZXhwb3NlcyByZWFsIHRpbWUgQXBwbGljYXRpb24gUW9TL1FvRSBtZXRyaWMg aW5mb3JtYXRpb24gDQogICAgICBpbiB0aGUgYXBwcm9wcmlhdGUgcmVwb3J0IGJsb2NrIGZvcm1h dCAoZS5nLixSVENQIFhSIG9yIG90aGUgbm9uLVJUUCANCiAgICAgIG1lYW5zKSB0byB0aGUgbWFu YWdlbWVudCBzeXN0ZW0uIFN1Y2ggaW5mb3JtYXRpb24gY2FuIGJlIGZvcm11bGF0ZWQgYXMgDQog ICAgICBkaWZmZXJlbnQgbWV0cmljIHR5cGVzLCBlLmcuLGFwcGxpY2F0aW9uIGxldmVsIG1ldHJp YywgdHJhbnNwb3J0IGxldmVsIA0KICAgICAgbWV0cmljLCBlbmQgc3lzdGVtIG1ldHJpYywgaW50 ZXJ2YWwgbWV0cmljLCBjdW11bGF0aXZlIG1ldHJpYywgc2FtcGxlZCANCiAgICAgIG1ldHJpYywg ZGlyZWN0IG1ldHJpYywgY29tcG9zZWQgbWV0cmljLGV0Yy4gQm90aCB0aGUgUlRDUCBvciBSVENQ IFhSIGNhbiANCiAgICAgIGJlIGV4dGVuZGVkIHRvIGNvbnZleSB0aGVzZSBtZXRyaWNzLiBUaGUg ZGV0YWlscyBvbiB0cmFuc3BvcnQgcHJvdG9jb2xzIA0KICAgICAgZm9yIHRoZXNlIG1ldHJpYyBh cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLiBSVFAgbWF5IGJlIHVzZWQgdG8gDQogICAgICBt dWx0aWNhc3QgZ3JvdXBzLCBib3RoIEFueSBTb3VyY2UgTXVsdGljYXN0IChBU00pIGFuZCBTb3Vy Y2UgU3BlY2lmaWMgDQogICAgICBNdWx0aWNhc3QgKFNTTSkuIFRoZXNlIGdyb3VwcyBjYW4gYmUg bW9uaXRvcmVkIHVzaW5nIFJUQ1AuIEluIHRoZSBBU00gDQogICAgICBjYXNlLCB0aGUgbW9uaXRv ciBpcyBhIG1lbWJlciBvZiB0aGUgbXVsdGljYXN0IGdyb3VwIGFuZCBsaXN0ZW5zIHRvIFJUQ1Ag DQogICAgICBYUiByZXBvcnRzIGZyb20gYWxsIG1lbWJlcnMgb2YgdGhlIEFTTTxCUj4mZ3Q7Jmd0 OyBncm91cC4gSW4gdGhlIFNTTSBjYXNlLCANCiAgICAgIHRoZXJlIGlzIGEgdW5pY2FzdCBmZWVk YmFjayB0YXJnZXQgdGhhdCByZWNlaXZlcyBSVENQIGZlZWRiYWNrIGZyb20gDQogICAgICByZWNl aXZlcnMgYW5kIGRpc3RyaWJ1dGVzIGl0IHRvIG90aGVyIG1lbWJlcnMgb2YgdGhlIFNTTSBncm91 cCAoc2VlIGZpZ3VyZSANCiAgICAgIDEgb2YgUkZDNTc2MCkuIFRoZSBtb25pdG9yIHdpbGwgbmVl ZCB0byBiZSBjby1sb2NhdGVkIHdpdGggdGhlIGZlZWRiYWNrIA0KICAgICAgdGFyZ2V0IHRvIHJl Y2VpdmUgYWxsIGZlZWRiYWNrIGZyb20gdGhlIHJlY2VpdmVycyAodGhpcyBtYXkgYWxzbyBiZSBh biANCiAgICAgIGludGVybWVkaWF0ZSBzeXN0ZW0pLiBJbiBib3RoIEFTTSBhbmQgU1NNIHNjZW5h cmlvcywgcmVjZWl2ZXJzIGNhbiBzZW5kIA0KICAgICAgUlRDUCBYUiByZXBvcnRzIHRvIGVuaGFu Y2UgdGhlIHJlY2VwdGlvbiBxdWFsaXR5IHJlcG9ydGluZy4gIiAmZ3Q7IEluIHRoZSANCiAgICAg IGRlZmluaXRpb24gb2YgQ29tcG9zZWQgbWV0cmljcywgdGhlIHNlbnRlbmNlICJBbiBleGFtcGxl IGlzIGEgDQogICAgICA8QlI+Jmd0OyZndDsmZ3Q7IG1ldHJpYyBjYWxjdWxhdGVkIGJhc2VkIG9u IGRlcml2ZWQgbWV0cmljcyB0aGF0IGhhdmUgYmVlbiANCiAgICAgIG1lYXN1cmVkLiIgPEJSPiZn dDsmZ3Q7Jmd0OyBtYWtlcyBsaXR0bGUgc2Vuc2UuIFtRaW5dIFRoZSBkZXJpdmVkIG1ldHJpY3Mg DQogICAgICBpbiB0aGUgc2VudGVuY2Ugc2hvdWxkIGJlZW4gY29ycmVjdGVkIGFzICJkaXJlY3Qg bWV0cmljIi4gJmd0O0RpZCB5b3UgbWVhbiANCiAgICAgIHNvbWV0aGluZyBsaWtlICJBbiBleGFt cGxlIGlzIGEgbWV0cmljIDxCUj4mZ3Q7Jmd0OyZndDsgZGVyaXZlZCBieSANCiAgICAgIGFsZ29y aXRobWljYWxseSBjb21iaW5pbmcgbWVhc3VyZWQgbWV0cmljcy4iPyBbUWluXTpJIGFncmVlIHdp dGggeW91ciANCiAgICAgIHN1Z2dlc3RlZCB0ZXh0IGFuZCBsaWtlIHRvIGFkb3B0IHlvdXIgc3Vn Z2VzdGlvbi4gJmd0OyBUaGUgZGVmaW5pdGlvbnMgb2YgDQogICAgICBJbnRlcnZhbCwgQ3VtdWxh dGl2ZSwgYW5kIFNhbXBsZWQgbWV0cmljcyBhcmUgbm90IGNsZWFyLiBbUWluXTogSSBhZ3JlZSAN CiAgICAgIHRoZSBkZWZpbml0aW9uIGZvciB0aGVzZSB0aHJlZSBtZXRyaWNzIG5lZWQgdG8gYmUg bW9yZSBjbGVhZXIsIEkgcHJvcG9zZXMgDQogICAgICB0byBkbyB0aGUgZm9sbG93aW5nIGNoYW5n ZXM6IE5FVyBUZXh0OiAiIEludGVydmFsIG1ldHJpY3MgTWV0cmljcyBvZiB3aGljaCANCiAgICAg IHRoZSByZXBvcnRlZCB2YWx1ZXMgYXJlIG1lYXN1cmVkIGluIHRoZSBtb3N0IHJlY2VudCBtZWFz dXJlbWVudCBpbnRlcnZhbCANCiAgICAgIGR1cmF0aW9uIGJldHdlZW4gc3VjY2Vzc2l2ZSBtZXRy aWNzIHJlcG9ydHMuIFN1Y2ggbWVhc3VyZW1lbnQgaW50ZXJ2YWwgaXMgDQogICAgICBlcXVhbCB0 byBvbmUgUlRDUCByZXBvcnQgaW50ZXJ2YWwgKFJGQzM1NTAsU2VjdGlvbiA2LjIpLiBDdW11bGF0 aXZlIA0KICAgICAgbWV0cmljcyBNZXRyaWNzIG9mIHdoaWNoIHRoZSByZXBvcnRlZCB2YWx1ZXMg YXBwbHkgdG8gdGhlIGFjY3VtdWxhdGlvbiANCiAgICAgIHBlcmlvZCBjaGFyYWN0ZXJpc3RpYyBv ZiBjdW11bGF0aXZlIG1lYXN1cmVtZW50cy4gVGhlIHJlcG9ydGVkIHZhbHVlcyBhcmUgDQogICAg ICBtZWFzdXJlZCBkdXJpbmcgdGhlIGFjY3VtdWxhdGlvbiBwZXJpb2QuIFRoZSBhY2N1bXVsYXRp b24gcGVyaW9kIHNwYW5zIA0KICAgICAgb3ZlciBtb3JlIHRoYW4gb25lIFJUQ1AgcmVwb3J0IGlu dGVydmFscy4gU2FtcGxlZCBtZXRyaWNzIE1ldHJpY3Mgb2Ygd2hpY2ggDQogICAgICB0aGUgcmVw b3J0ZWQgdmFsdWVzIG9ubHkgYXBwbHkgdG8gdGhlIHZhbHVlIG9mIGEgY29udGludW91c2x5IG1l YXN1cmVkIA0KICAgICAgb3I8QlI+Jmd0OyZndDsgY2FsY3VsYXRlZCBtZXRyaWMgdGhhdCBoYXMg YmVlbiBzYW1wbGVkIGF0IGFueSBnaXZlbiANCiAgICAgIGluc3RhbmNlIG9mIHRoZSBSVENQIHJl cG9ydCBpbnRlcnZhbC4gT25lIGV4YW1wbGUgb2Ygc3VjaCBtZXRyaWMgaXMgdGhlIA0KICAgICAg aW50ZXItYXJyaXZhbCBqaXR0ZXIgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIDYuNC4xIG9mIFJG QzM1NTAuICIgJmd0OyBJZiANCiAgICAgIHRoZSBkaXNjdXNzaW9uIGF0IHRoZSBlbmQgb2Ygc2Vj dGlvbiAzLjEgaXMga2VwdCwgdGhlIHJlZmVyZW5jZSB0byANCiAgICAgIDxCUj4mZ3Q7Jmd0OyZn dDsgUkZDNTc2MCBzaG91bGQgYmUgYSByZWFsIHJlZmVyZW5jZSwgYW5kIFJGQzU3NjAgc2hvdWxk IA0KICAgICAgYXBwZWFyIGluIHRoZSA8QlI+Jmd0OyZndDsmZ3Q7IHJlZmVyZW5jZSBzZWN0aW9u LiBbUWluXTogT2theS4gJmd0OyBUaGUgDQogICAgICBwb2ludCBvZiBzZWN0aW9uIDMuMiBpcyBu b3Qgb2J2aW91cy4gSG93IGRvZXMgaXQgY29udHJpYnV0ZSB0byB0aGUgDQogICAgICA8QlI+Jmd0 OyZndDsmZ3Q7IGRlc2NyaXB0aW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUuIEl0IG1peGVzIHRhbGtp bmcgYWJvdXQgDQogICAgICB3aGF0IHJlcG9ydCA8QlI+Jmd0OyZndDsmZ3Q7IGJsb2NrcyBhcmUg d2l0aCBvY2Nhc2lvbmFsbHkgbmVlZGluZyB0byBzZW5kIA0KICAgICAgdGhlbSBtb3JlIGZyZXF1 ZW50bHkuIFRob3NlIDxCUj4mZ3Q7Jmd0OyZndDsgcG9pbnRzIGNvdWxkIGJlIG1hZGUgDQogICAg ICBzZXBhcmF0ZWx5IGFuZCBtb3JlIHNpbXBseS4gW1Fpbl06IE9rYXkuIEkgbGlrZSB0byBpbmNv cnBvcmF0ZSB0aGUga2V5IA0KICAgICAgcG9pbnRzIGluIHRoZSBzZWN0aW9uIDMuMiBpbnRvIHNl Y3Rpb24gMy4xICZndDsgU2VjdGlvbiAzLjMgaXMgbm90IGNsZWFyIC0gDQogICAgICBpdCBzdGFy dHMgb2ZmIHNheWluZyB0aGF0IHRoZSBsb2NhdGlvbiBvZiB0aGUgPEJSPiZndDsmZ3Q7Jmd0OyBz ZW5kZXIgYW5kIA0KICAgICAgcmVjZWl2ZXIgbWF5IGNoYW5nZSB3aGF0IG1ldHJpY3MgYXJlIG1l YW5pbmdmdWwuIEl0J3Mgbm90IDxCUj4mZ3Q7Jmd0OyZndDsgDQogICAgICBjbGVhciB3aGF0IHlv dSBtZWFuIGJ5IGxvY2F0aW9uLiBZb3UgY2VydGFpbmx5IGRvbid0IG1lYW4gZ2Vvc3BhdGlhbCAN CiAgICAgIDxCUj4mZ3Q7Jmd0OyZndDsgY29vcmRpbmF0ZXMuIERvIHlvdSBtZWFuIGFueXRoaW5n IG90aGVyIHRoYW4gd2hldGhlciB0aGUgDQogICAgICBlbGVtZW50IGlzIDxCUj4mZ3Q7Jmd0OyZn dDsgdHJ1c3RlZCBvciB1bnRydXN0ZWQgYnkgdGhlIG9wZXJhdGlvbnMgDQogICAgICBuZXR3b3Jr PyBJZiBzbywgc2F5IHRoYXQuIFRoZSA8QlI+Jmd0OyZndDsmZ3Q7IHJlc3Qgb2YgdGhlIHBhcmFn cmFwaCBvbmx5IA0KICAgICAgc3BlYWtzIHRvIHdoYXQgZWxlbWVudCBjb2xsZWN0cyB0aGUgbWV0 cmljcy4gW1Fpbl0gU2VjdGlvbiAzLjMgaXMgb25seSANCiAgICAgIHVzZWQgdG8gZGVzY3JpYmUg d2hlcmUgb3IgZnJvbSB3aGljaCBSVFAgZW50aXR5IHRvIGdhdGhlciB0aGUgbWV0cmljcyANCiAg ICAgIChpLmUuLCBtZWFzdXJlbWVudCBwb2ludCkgaW4gdGhlIHBoeXNpY2FsIG5ldHdvcmsgYW5k IGlzIG5vdCBmb2N1cyBvZiB0aGlzIA0KICAgICAgZG9jdW1lbnQuIFNlY29uZGx5LCBJIHRoaW5r IHRoZSBkZWZpbml0aW9uIG9mIGFwcGxpY2F0aW9uIGxldmVsIG1ldHJpY3MgDQogICAgICBoYXMg YWxyZWFkeSBjbGFyaWZpZWQgdGhhdCBhcHBsaWNhdGlvbiBsZXZlbCBtZXRyaWNzIGlzIG5vcm1h bGx5IGdhdGhlcmVkIA0KICAgICAgZnJvbSB1c2VyIGVuZHBvaW50LiAmZ3Q7IEl0J3Mgbm90IGNs ZWFyIHRoYXQgdGhlIHNldCBvZiBtZWFuaW5nZnVsIG1ldHJpY3MgDQogICAgICBpcyBjaGFuZ2Vk IGF0IGFsbCAtIDxCUj4mZ3Q7Jmd0OyZndDsganVzdCB3aGVyZSB5b3UgY29sbGVjdCB0aGVtLiBJ ZiB0aGUgDQogICAgICBzZXQgb2YgbWVhbmluZ2Z1bCBtZXRyaWNzIGRvZXMgaW4gPEJSPiZndDsm Z3Q7Jmd0OyBmYWN0IGNoYW5nZSwgdGhlcmUgDQogICAgICBuZWVkcyB0byBiZSBhZGRpdGlvbmFs IGRpc2N1c3Npb24gaGVyZS4gW1Fpbl06IFRoZSBtZXRyaWNzIGFjdHVhbGx5IA0KICAgICAgZG9l c24ndCBjaGFuZ2UuU2luY2UgdGhlIGRlZmluaXRpb24gb2YgYXBwbGljYXRpb24gbGV2ZWwgbWV0 cmljcyBIYXZlIA0KICAgICAgYWxyZWFkeSBjb252ZXllZCB0aGUgbWVhbmluZyBvZiB3aGF0IHNl Y3Rpb24gMy4zIHdhbnRzIHRvIGRlc2NyaWJlLCBJIA0KICAgICAgcHJvcG9zZSB0byByZW1vdmUg dGhpcyBzZWN0aW9uLiAmZ3Q7IFNlY3Rpb24gNCdzIGZpcnN0IHBhcmFncmFwaDogSXMgDQogICAg ICAicHJvYmFibHkiIHRoZSBiZXN0IHRoZSB3b3JraW5nIGdyb3VwIDxCUj4mZ3Q7Jmd0OyZndDsg Y2FuIHNheT8gW1Fpbl06Tm8sIA0KICAgICAgd2lsbCByZW1vdmUgdGhpcyB3b3JkLiAmZ3Q7IFRo ZSBsYXN0IHR3byBzZW50ZW5jZXMgb2YgdGhlIHNlY29uZCBidWxsZXQgaW4gDQogICAgICBzZWN0 aW9uIDQgZG8gbm90IHBhcnNlLiA8QlI+Jmd0OyZndDsmZ3Q7IFBsZWFzZSBzaW1wbGlmeSB0aGVt LiBbUWluXTogDQogICAgICBPa2F5LCBob3cgYWJvdXQgY2hhbmdlIHRoZW0gYXMgZm9sbG93czog TkVXIFRleHQ6ICIgV2l0aCB0aGVzZSBtaW5pbWFsIA0KICAgICAgbnVtYmVyIG9mIFJUQ1Agc3Rh dGlzdGljcyBwYXJhbWV0ZXJzIG1hcHBlZCB0byBub24tUlRDUCBtZWFzdXJlbWVudHMsIGl0IA0K ICAgICAgaXMgaGFyZCB0byBwcm92aWRlIGFjY3VyYXRlIG1lYXN1cmVzIG9mIHJlYWwgdGltZSBh cHBsaWNhdGlvbiANCiAgICAgIHF1YWxpdHksY29uZHVjdCBkZXRhaWxlZCBkYXRhIGFuYWx5c2lz IGFuZCBjcmVhdGVzIGFsZXJ0cyB0aW1seSB0byB0aGUgDQogICAgICB1c2Vycy4gVGhlcmVmb3Jl IGNvcnJlbGF0aW9uIGJldHdlZW4gUlRDUCBYUiBhbmQgbm9uLVJUUCBkYXRhIHNob3VsZCBiZSAN CiAgICAgIHByb3ZpZGVkLiAiICZndDsgVGhlIGZpcnN0IGZ1bGwgc2VudGVuY2Ugb2YgdGhlIHRo aXJkIGJ1bGxldCBpbiBzZWN0aW9uIDQgDQogICAgICBkb2VzIG5vdCBtYWtlIDxCUj4mZ3Q7Jmd0 OyZndDsgc2Vuc2UuIFRoZSB3aG9sZSBidWxsZXQgY291bGQgYmUgY2xhcmlmaWVkLiANCiAgICAg IFtRaW5dOiBBZ3JlZSBhbmQgd2lsbCByZW1vdmUgdGhlIGZpcnN0IHNlbnRlbmNlLiAmZ3Q7IFRo ZSBmb3VydGggYnVsbGV0IGluIA0KICAgICAgc2VjdGlvbiA0IGFuZCBzZWN0aW9uIDUuNSBzaG91 bGQgY2FsbCBvdXQgdGhhdCA8QlI+Jmd0OyZndDsmZ3Q7IFJGQzM2MTEgDQogICAgICBhbHJlYWR5 IHNldCBCbG9jayBUeXBlIDI1NSBhc2lkZSBmb3IgZnV0dXJlIGV4dGVuc2lvbnMsIDxCUj4mZ3Q7 Jmd0OyZndDsgDQogICAgICBhbnRpY2lwYXRpbmcgdGhlIHBvdGVudGlhbCBuZWVkIHRvIGV4dGVu ZCB0aGUgYmxvY2sgdHlwZSBzcGFjZS4gW1Fpbl06IA0KICAgICAgT2theSwgSG93IGFib3V0IHJl dmlzaW5nIHRoZSBzZWN0aW9uIDQsYnVsbGV0IDQgYXMgZm9sbG93czogIiBDb25zdW1wdGlvbiAN CiAgICAgIG9mIFhSIGJsb2NrIGNvZGUgcG9pbnRzLiBUaGUgUlRDUCBYUiBibG9jayBuYW1lc3Bh Y2UgaXMgbGltaXRlZCBieSB0aGUgDQogICAgICA4LWJpdCBibG9jayB0eXBlIGZpZWxkIGluIHRo ZSBSVENQIFhSIGhlYWRlci4gU3BhY2UgZXhoYXVzdGlvbiBtYXkgYmUgYSANCiAgICAgIGNvbmNl cm4gaW4gdGhlIGZ1dHVyZS4gQW50aWNpcGF0aW5nIHRoZSBwb3RlbnRpYWwgbmVlZCB0byBleHRl bmQgdGhlIGJsb2NrIA0KICAgICAgdHlwZSBzcGFjZSwgaXQgaXMgbm90ZWQgaW4gW1JGQzM2MTFd IHRoYXQgQmxvY2sgVHlwZSAyNTUgaXMgcmVzZXJ2ZWQgZm9yIA0KICAgICAgZnV0dXJlIGV4dGVu c2lvbnMsICIgJmd0OyBJbiBzZWN0aW9uIDUsIGNvbnNpZGVyIG5hbWluZyB0aGUgc3Vic2VjdGlv bnMgDQogICAgICB3aXRoIHRoZSBhY3R1YWwgZ3VpZGVsaW5lIDxCUj4mZ3Q7Jmd0OyZndDsgaW5z dGVhZCBvZiB0aGUgcHJvYmxlbSB0aGUgDQogICAgICBndWlkZWxpbmUgaXMgdHJ5aW5nIHRvIGFk ZHJlc3MuPEJSPiZndDsmZ3Q7Jmd0OyA1LjEuIE1ldHJpYyBibG9ja3Mgc2hvdWxkIA0KICAgICAg Y29udGFpbiBhIHNpbmdsZSBtZXRyaWMgW1Fpbl06IEkgc3VnZ2VzdCB0byBjaGFuZ2UgaXQgYXMg IkNvbnRhaW4gdGhlIA0KICAgICAgc2luZ2xlIG1ldHJpY3MgaW4gdGhlIG1ldHJpYyBibG9jayIg Jmd0OyA1LjIuIEluY2x1ZGUgdGhlIHBheWxvYWQgdHlwZSBhbmQgDQogICAgICBmb3JtYXQgcGFy YW1ldGVycyBpbiB0aGUgbWV0cmljIGJsb2NrIFtRaW5dOiBPa2F5LiAmZ3Q7IDUuMy4gVXNlIFJU Q1AgU0RFUyANCiAgICAgIHRvIGNvcnJlbGF0ZSBYUiByZXBvcnRzIHdpdGggbm9uLVJUUCBkYXRh IFtRaW5dOiBPa2F5LiAmZ3Q7IDUuNC4gRG9uJ3QgDQogICAgICByZXBlYXQgbWVhc3VyZW1lbnQg aW5mb3JtYXRpb24gYWNyb3NzIG1ldHJpYyBibG9ja3M8QlI+Jmd0OyZndDsmZ3Q7IA0KICAgICAg PEJSPiZndDsmZ3Q7IFtRaW5dOiBJdCBpcyBub3QgcG9zc2libGUgY29tcGxldGVseSB0byBhdm9p ZCBtZWFzdXJlbWVudCANCiAgICAgIGluZm9ybWF0aW9uIHJlcGVhdGl0aW9uLiBlLmcuLCBmb3Ig cGFja2V0IGxvc3Mgcm9idXN0bmVzcyBpZiB0aGUgcmVwb3J0IA0KICAgICAgYmxvY2tzIGZvciB0 aGUgc2FtZSBpbnRlcnZhbCBzcGFuIG92ZXIgbW9yZSB0aGFuIG9uZSBSVENQIHBhY2tldCB0aGVu IGVhY2ggDQogICAgICBtdXN0IGhhdmUgdGhlIHNhbWUgbWVhc3VyZW1lbnQgaWRlbnRpdHkgaW5m b3JtYXRpb24gU28gSSBzdWdnZXN0IHRvIGNoYW5nZSANCiAgICAgIGl0IGFzOiAicmVkdWNlIG1l YXN1cmVtZW50IGluZm9ybWF0aW9uIGFjcm9zcyBtZXRyaWMgYmxvY2tzIiAmZ3Q7IFRoaXMgDQog ICAgICBwb2ludHMgb3V0IGEgc3RydWN0dXJhbCBwcm9ibGVtIHdpdGggdGhlIHNlY3Rpb24uIFdo eSBpcyA1LjUgaGVyZT8gDQogICAgICA8QlI+Jmd0OyZndDsmZ3Q7IEl0J3Mgbm90IGEgZ3VpZGVs aW5lLiBbUWluXTogQWdyZWUgYW5kIGFsc28gYXMgDQogICAgICBkaXNjdXNzZWQsU3BhY2UgZXho YXVzdGlvbiBpcyBub3QgYmlnIGlzc3VlLiBIb3cgYWJvdXQgcmVtb3ZlIHRoaXMgDQogICAgICBz ZWN0aW9uPyAmZ3Q7ICgqKSBBbmQgaXQgcmFpc2VzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUg ZG9jdW1lbnQgaXMgDQogICAgICB0cnlpbmcgdG8gPEJSPiZndDsmZ3Q7Jmd0OyBhY2hpZXZlIHdp dGggc2VjdGlvbiA1LjQuIFRoYXQgc2VjdGlvbiBjbGFpbXMgDQogICAgICB0aGUgZG9jdW1lbnQg aXMgcHJvcG9zaW5nIDxCUj4mZ3Q7Jmd0OyZndDsgYSBuZXcgWFIgYmxvY2sgdHlwZSB0byBoZWxw IA0KICAgICAgYXZvaWQgZHVwbGljYXRpb24sIGJ1dCBpdCBkb2Vzbid0IGFjdHVhbGx5IDxCUj4m Z3Q7Jmd0OyZndDsgZGVmaW5lIHRoZSBuZXcgDQogICAgICBibG9jayB0eXBlLiBJcyB0aGUgZ3Vp ZGVsaW5lIHNheWluZyBzaW1wbHkgZG9uJ3QgcmVwZWF0IDxCUj4mZ3Q7Jmd0OyZndDsgDQogICAg ICBtZWFzdXJlbWVudHMgb3IgaXRzIHRoZSBndWlkZWxpbmUgc2F5aW5nICJ1c2UgdGhpcyBuZXcg WFIgYmxvY2sgdHlwZSB3ZSANCiAgICAgIDxCUj4mZ3Q7Jmd0OyZndDsgaGF2ZW4ndCBkZWZpbmVk IHlldCI/IFtRaW5dOiBKdXN0IHRvIGNsYXJpZnksIHdlIGhhdmUgDQogICAgICBhbHJlYWR5IGRl ZmluZWQgb25lIG5ldyBYUiBCbG9jayB0eXBlIHRvIGhlbHAgYXZvaWQgb3IgcmVkdWNlIGR1cGxp Y2F0aW9uLiANCiAgICAgIEl0IGlzIG1lYXN1cmVtZW50IGluZm9ybWF0aW9uIGJsb2NrLiBUaGUg cmVsZXZhbnQgZHJhZnQgaXMgYXZhaWxhYmxlIGF0OiANCiAgICAgIDxBIA0KICAgICAgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbWVh cy1pZGVudGl0eS0wNiIgDQogICAgICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLW1lYXMtaWRlbnRpdHktMDY8L0E+IA0K ICAgICAgJmd0O1RoZSBzZWN0aW9uIG5lZWRzIG1vcmUgY2xhcml0eS4gSWYgaXQgcmVhbGx5IGlz IDxCUj4mZ3Q7Jmd0OyZndDsgDQogICAgICB0cnlpbmcgdG8gZGVmaW5lIGEgbmV3IHR5cGUsIHRo ZXJlJ3MgbW9yZSB3b3JrIHRvIGJlIGRvbmUuIFtRaW5dOiBJbiBvcmRlciANCiAgICAgIHRvIGF2 b2lkIHN1Y2ggY29uZnVzaW9uLCBJIHByb3Bvc2VkIHRvIGRvIHRoZSBmb2xsb3dpbmcgY2hhbmdl IHRvIHRoZSANCiAgICAgIHNlY3Rpb24gNS40OiBPTEQgVGV4dDogIiBUaGlzIG1lbW8gcHJvcG9z ZXMgdG8gZGVmaW5lIGEgbmV3IFhSIEJsb2NrIHRoYXQgDQogICAgICB3aWxsIGJlIHVzZWQgdG8g Y29udmV5IHRoZSBjb21tb24gdGltZSBwZXJpb2QgYW5kIHRoZSBudW1iZXIgb2YgcGFja2V0cyAN CiAgICAgIHNlbnQgZHVyaW5nIHRoaXMgcGVyaW9kLiAiIE5ldyB0ZXh0OiAiIFRoaXMgbWVtbyBw cm9wb3NlcyB0byBkZWZpbmUgYSBuZXcgDQogICAgICBYUiBCbG9jayAoaS5lLiwgdGhlIE1lYXN1 cmVtZW50IGluZm9ybWF0aW9uIA0KICAgICAgYmxvY2tbSS5ELWlldGYteHJibG9jay1ydGNwLXhy LW1lYXMtaWRlbnRpdHldKSB0aGF0IHdpbGwgYmUgdXNlZCB0byBjb252ZXkgDQogICAgICB0aGUg Y29tbW9uIHRpbWUgcGVyaW9kIGFuZCB0aGUgbnVtYmVyIG9mIHBhY2tldHMgc2VudCBkdXJpbmcg dGhpcyBwZXJpb2QuIA0KICAgICAgIiAmZ3Q7IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uLCBwYXJ0aWN1bGFybHkgdGhlIHRoaXJkIA0KICAgICAgcGFyYWdyYXBoLCA8QlI+Jmd0 OyZndDsmZ3Q7IG5lZWRzIHRvIGJlIGNsZWFyZXIuIFdoYXQgZXhhY3RseSBkbyB5b3UgbWVhbiAN CiAgICAgIGJ5ICJtb25pdG9yaW5nIHNob3VsZCBiZSA8QlI+Jmd0OyZndDsmZ3Q7IHByb2hpYml0 ZWQiLCBhbmQgaG93IGlzIHRoZSBmYWN0IA0KICAgICAgdGhhdCB0aGlyZCBwYXJ0eSBtb25pdG9y cyBkb24ndCBzZW5kIDxCUj4mZ3Q7Jmd0OyZndDsgUlRDUCByZWxldmFudD8gRGlkIA0KICAgICAg eW91IGludGVuZCB0aG9zZSB0byBiZSBzZXBhcmF0ZSBwb2ludHM/IFtRaW5dOiBZZXMsIHRoZXkg YXJlIG9uIHRoZSANCiAgICAgIGRpZmZlcmVudCBwb3J0LiBTdWNoIG1vbml0b3IgbWF5IHJlY2Vp dmUgUlRQIHBhY2tldCBidXQgZG9lcyBub3Qgc2VuZCBSVENQIA0KICAgICAgcGFja2V0LiAmZ3Q7 IEVkaXRvcmlhbCBOaXRzIGFuZCBTdWdnZXN0aW9uczo8QlI+Jmd0OyZndDsmZ3Q7IA0KICAgICAg PEJSPiZndDsmZ3Q7Jmd0OyBUaGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBpbnRyb2R1Y3Rpb24g aXMgb3Zlcmx5IA0KICAgICAgY29tcGxleCwgYW5kIHdvbid0IGFnZSA8QlI+Jmd0OyZndDsmZ3Q7 IHdlbGwuIEkgc3VnZ2VzdCByZXBsYWNpbmcgaXQgd2l0aDogDQogICAgICAiTXVsdGltZWRpYSBz ZXJ2aWNlcyB1c2luZyB0aGUgPEJSPiZndDsmZ3Q7Jmd0OyBSZWFsLVRpbWUgUHJvdG9jb2wgKFJU UCkgDQogICAgICBhcmUgc2VlaW5nIGluY3JlYXNlZCB1c2UuIFN0YW5kYXJkIG1ldGhvZHMgZm9y IDxCUj4mZ3Q7Jmd0OyZndDsgZ2F0aGVyaW5nIA0KICAgICAgUlRQIHBlcmZvcm1hbmNlIG1ldHJp Y3MgZnJvbSB0aGVzZSBhcHBsaWNhdGlvbnMgYXJlIG5lZWRlZCB0byANCiAgICAgIDxCUj4mZ3Q7 Jmd0OyZndDsgbWFuYWdlIHVuY2VydGFpbnRpZXMgaW4gdGhlIGJlaGF2aW9yIGFuZCBhdmFpbGFi aWxpdHkgb2YgDQogICAgICB0aGVpciA8QlI+Jmd0OyZndDsmZ3Q7IHNlcnZpY2VzLiIgVGhlbiBy ZXBsYWNlICJUaGVzZSByYXBpZGx5IGVtZXJnaW5nIA0KICAgICAgc3RhbmRhcmRzLCIgd2l0aCA8 QlI+Jmd0OyZndDsmZ3Q7ICJTdGFuZGFyZHMiLiBbUWluXTogT2theS4gJmd0OyANCiAgICAgIElu dHJvZHVjdGlvbiBwYXJhZ3JhcGggMyBzZW50ZW5jZSAyIHNob3VsZCBzdGFydCAiVGhlIFJUQ1Ag R3VpZGVsaW5lcyANCiAgICAgIDxCUj4mZ3Q7Jmd0OyZndDsgW1JGQzU5NjhdIi4gSXQgd291bGQg YmUgZXZlbiBiZXR0ZXIgdG8gdXNlIHRoZSBmdWxsIHRpdGxlIA0KICAgICAgZnJvbSA1OTY4OiA8 QlI+Jmd0OyZndDsmZ3Q7ICdUaGUgIkd1aWRlbGluZXMgZm9yIEV4dGVuZGluZyB0aGUgUlRQIENv bnRyb2wgDQogICAgICBQcm90b2NvbCAoUlRDUCkiIFtSRkM1OTY4XScgW1Fpbl06IE9rYXkuICZn dDsgVGhpcyBtYXkgYmVjb21lIG1vb3QgYXMgDQogICAgICBzZWN0aW9uIDMgaXMgbW9kaWZpZWQg dG8gbWFrZSBpdHMgbWFpbiBwb2ludCA8QlI+Jmd0OyZndDsmZ3Q7IG1vcmUgDQogICAgICBvYnZp b3VzLCBidXQgUkZDMzU1MCBkb2VzIG5vdCBjaGFyYWN0ZXJpemUgTW9uaXRvcnMgYXMgImEgc291 cmNlIG9mIA0KICAgICAgPEJSPiZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbiIuIFRoYXQgY291bGQg YmUgbWlzdW5kZXJzdG9vZC4gUGxlYXNlIGNob29zZSANCiAgICAgIGFub3RoZXIgd29yZC4gPEJS PiZndDsmZ3Q7Jmd0OyBQZXJoYXBzICJyZXBvc2l0b3J5Ij8gW1Fpbl06IE9rYXksIA0KICAgICAg cmVwb3NpdG9yeSBsb29rcyBnb29kIHRvIG1lLiAmZ3Q7IEluIGJ1bGxldCBsaXN0cywgc3RhcnRp bmcgYW4gZW50cnkgd2l0aCANCiAgICAgICJvciIgb3IgImFuZCIgaXMgdW5uZWNlc3NhcnkuIEl0 IDxCUj4mZ3Q7Jmd0OyZndDsgc2hvdWxkIGJlIGNsZWFyIGZyb20gdGhlIA0KICAgICAgaW50cm9k dWN0aW9uIHRvIHRoZSBsaXN0IHdoZXRoZXIgdGhlIGluZGl2aWR1YWwgPEJSPiZndDsmZ3Q7Jmd0 OyBlbnRyaWVzIA0KICAgICAgc2hvdWxkIGJlIGNvbWJpbmVkIG9yIHNlbGVjdGVkIGZyb20uIFtR aW5dOiBPa2F5LiAmZ3Q7IEluIHNlY3Rpb24gMy4xIA0KICAgICAgd2hlcmUgeW91IHNheSAiUlRQ IG1heSBiZSB1c2VkIHRvIG11bHRpY2FzdCBncm91cHMiIGRpZCA8QlI+Jmd0OyZndDsmZ3Q7IA0K ICAgICAgeW91IG1lYW4gIlJUUCBtYXkgYmUgc2VudCB0byBtdWx0aWNhc3QgZ3JvdXBzIiBvciAi UlRQIG1heSBiZSB1c2VkIHdpdGggDQogICAgICA8QlI+Jmd0OyZndDsmZ3Q7IG11bHRpY2FzdCBn cm91cHMiPyBbUWluXTogSSB0aGluayBpdCBzaG91bGQgYmUgdGhlIGxhdHRlciANCiAgICAgIGNh c2UsaS5lLiwiIFJUUCBtYXkgYmUgdXNlZCB3aXRoIDxCUj4mZ3Q7Jmd0OyBtdWx0aWNhc3QgZ3Jv dXBzIi4gJmd0OyANCiAgICAgIDxCUj4mZ3Q7Jmd0OyZndDsgSW4gc2VjdGlvbiAzLjIgIlRoZSBm b2xsb3dpbmcgYXJlIGZvdXIgdXNlIGNhc2VzIGJ1dCBhcmUgDQogICAgICBub3QgbGltaXRlZCA8 QlI+Jmd0OyZndDsmZ3Q7IHRvOiIgZG9lcyBub3QgcGFyc2UuIFRoZSBidWxsZXRzIGFyZW4ndCAN CiAgICAgIHJlYWxseSB1c2UgY2FzZXMgYXMgbXVjaCBhcyB0aGV5IDxCUj4mZ3Q7Jmd0OyZndDsg YXJlIG1lY2hhbmlzbXMuIFdvdWxkIGl0IA0KICAgICAgbWFrZSBtb3JlIHNlbnNlIHRvIHNheSAi SGVyZSBhcmUgZm91ciA8QlI+Jmd0OyZndDsmZ3Q7IG1lY2hhbmlzbXMgdGhhdCANCiAgICAgIGhh dmUgYmVlbiBjcmVhdGVkIHRvIGFkZHJlc3MgdGhlIG5lZWQgZm9yIG1vcmUgZnJlcXVlbnQgPEJS PiZndDsmZ3Q7Jmd0OyANCiAgICAgIHJlcG9ydGluZy4gVGhpcyBsaXN0IGlzIG5vdCBpbnRlbmRl ZCB0byBiZSBleGhhdXN0aXZlLiIgVGhlIHRoaXJkIGJ1bGxldCANCiAgICAgIDxCUj4mZ3Q7Jmd0 OyZndDsgaW4gdGhhdCBsaXN0IHNob3VsZCBzYXkgIlJUQ1AgYW5kIFJUQ1AgWFIgYXJlIiBpbnN0 ZWFkIG9mIA0KICAgICAgIlJUQ1Agb3IgUlRDUCA8QlI+Jmd0OyZndDsmZ3Q7IFhSIGlzIi4gW1Fp bl06IE9rYXksIGJ1dCBJIGhhdmUgDQogICAgICBpbmNvcnBvcmF0ZWQgdGhlIGtleXBvaW50cyBv ZiBzZWN0aW9uIDMuMiBpbnRvIHNlY3Rpb24gMy4xLiAmZ3Q7IFRoZSANCiAgICAgIGJ1bGxldHMg aW4gc2VjdGlvbiA0IHdvdWxkIGJlIGJldHRlciBhcyBzdWJzZWN0aW9ucyB3aXRoIHRpdGxlcyAN CiAgICAgIDxCUj4mZ3Q7Jmd0OyZndDsgKHRha2VuIGZyb20gdGhlIGZpcnN0IHBocmFzZSBvZiB0 aGUgYnVsbGV0KS4gW1Fpbl06IE9rYXkuIA0KICAgICAgJmd0OyBJIHN1Z2dlc3QgdGhpcyBhbHRl cm5hdGl2ZSBmb3IgdGhlIGZpcnN0IGZ1bGwgc2VudGVuY2UgaW4gdGhlIGZpcnN0IA0KICAgICAg PEJSPiZndDsmZ3Q7Jmd0OyBidWxsZXQgb2Ygc2VjdGlvbiA0IDogIkEgY29tcG91bmQgbWV0cmlj cyBibG9jayBpcyANCiAgICAgIGRlc2lnbmVkIHRvIGNvbnRhaW4gYSA8QlI+Jmd0OyZndDsmZ3Q7 IGxhcmdlIG51bWJlciBvZiBwYXJhbWV0ZXJzIGZyb20gDQogICAgICBkaWZmZXJlbnQgY2xhc3Nl cyBmb3IgYSBzcGVjaWZpYyA8QlI+Jmd0OyZndDsmZ3Q7IGFwcGxpY2F0aW9uIGluIGEgc2luZ2xl IA0KICAgICAgYmxvY2suIiBbUWluXTogT2theS4gJmd0OyBTZWN0aW9uIDUncyB0aXRsZSBzaG91 bGQgYmUgIkd1aWRlbGluZXMgZm9yIA0KICAgICAgcmVwb3J0aW5nIiBpbnN0ZWFkIG9mIDxCUj4m Z3Q7Jmd0OyZndDsgIkd1aWRlbGluZSBmb3IgcmVwb3J0aW5nIiBbUWluXTogDQogICAgICBPa2F5 LiAmZ3Q7IEluIHNlY3Rpb24gNS4xIEkgc3VnZ2VzdCAianVzdGlmeSB0aGUgb3ZlcmhlYWQsIiBp bnN0ZWFkIG9mIA0KICAgICAgImp1c3RpZnkgdGhlIDxCUj4mZ3Q7Jmd0OyZndDsgb3ZlcmhlYWRz LCIgW1Fpbl06IE9rYXkuICZndDsgU2VjdGlvbiA3IC0gDQogICAgICB0aGUgbGFzdCBzZW50ZW5j ZSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIGRvZXMgbm90IHBhcnNlLiBUaGUgDQogICAgICA8QlI+ Jmd0OyZndDsmZ3Q7IHNlY29uZCBwYXJhZ3JhcGggKHdoaWNoIGlzIGEgc2luZ2xlIHNlbnRlbmNl KSBzaG91bGQgYmUgDQogICAgICBjbGFyaWZpZWQgLSBhbiA8QlI+Jmd0OyZndDsmZ3Q7IE1DVSBp cyBub3QgYSB0b3BvbG9neS4gW1Fpbl06IE9rYXkuIEhvdyANCiAgICAgIGFib3V0IHJldmlzaW5n IHRoZW0gYXMgZm9sbG93czogT0xEIFRleHQ6ICIgVGhlIHRvcG9sb2dpZXMgaW4gdGhpcyANCiAg ICAgIGNhdGVnb3J5IGFyZSBUb3BvLVZpZGVvLVN3aXRjaC1NQ1UgYW5kIFRvcG8tUlRDUC10ZXJt aW5hdGluZy1NQ1UuIFN1Y2ggDQogICAgICB0b3BvbG9naWVzIGJhc2VkIG9uIHN5c3RlbXMgZG8g bm90IGJlaGF2ZSBhY2NvcmRpbmcgdG8gdGhlIFJUUCBwcm90b2NvbCANCiAgICAgIFtSRkMzNTUw XS4gQ29uc2lkZXJpbmcgdGhlIE1DVSBhbmQgdHJhbnNsYXRvciBhcmUgdHdvIHR5cGljYWwgdG9w b2xvZ2llcyANCiAgICAgIGluIHRoZSB0d28gY2F0ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRo aXMgZG9jdW1lbnQgd2lsbCB0YWtlIHRoZW0gYXMgdHdvIA0KICAgICAgdHlwaWNhbCBleGFtcGxl cyB0byBleHBsYWluIGhvdyBSVENQIFhSIHJlcG9ydCB3b3JrcyBpbiBkaWZmZXJlbnQgUkZDNTEx NyANCiAgICAgIHRvcG9sb2dpZXMuICIgTkVXIFRleHQ6ICIgVGhlIHRvcG9sb2dpZXMgaW4gdGhp cyBjYXRlZ29yeSBhcmUgDQogICAgICBUb3BvLVZpZGVvLVN3aXRjaC1NQ1UgYW5kIFRvcG8tUlRD UC10ZXJtaW5hdGluZy1NQ1UuIFN1Y2ggdG9wb2xvZ2llcyBiYXNlZCANCiAgICAgIG9uIHN5c3Rl bXMgKGUuZy4sTUNVKSBkbyBub3QgYmVoYXZlIGFjY29yZGluZyB0byB0aGUgUlRQIHByb3RvY29s IA0KICAgICAgW1JGQzM1NTBdLiBDb25zaWRlcmluZyB0aGUgTUNVIGFuZCB0cmFuc2xhdG9yIGFy ZSB0d28gdHlwaWNhbCBpbnRlcm1lZGlhcnkgDQogICAgICBzeXN0ZW1zIGluIHRoZSB0d28gY2F0 ZWdvcmllcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1lbnQgd2lsbCB0YWtlIA0KICAgICAg dGhlbSBhcyB0d28gdHlwaWNhbCBleGFtcGxlcyB0byBleHBsYWluIGhvdyBSVENQIFhSIHJlcG9y dCB3b3JrcyBpbiANCiAgICAgIGRpZmZlcmVudCBSRkM1MTE3IHRvcG9sb2dpZXMuICIgJmd0OyBU aGUgbGFzdCB0d28gc2VudGVuY2VzIG9mIHRoZSANCiAgICAgIGZpcnN0PEJSPiZndDsmZ3Q7IHBh cmFncmFwaCBvZiB0aGUgc2VjdXJpdHkgPEJSPiZndDsmZ3Q7Jmd0OyANCiAgICAgIGNvbnNpZGVy YXRpb25zIHNlY3Rpb24gYWRkIG5vdGhpbmcgdG8gdGhlIGRvY3VtZW50LiBJIHN1Z2dlc3QgZGVs ZXRpbmcgDQogICAgICB0aGVtLiBbUWluXTogT2theS4gJmd0OyANCiAgICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsmZ3Q7Jmd0OyANCiAg ICAgIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlPEJSPiZndDsmZ3Q7Jmd0 OyBhdnQgYXQgPEEgDQogICAgICBocmVmPSJodHRwOi8vaWV0Zi5vcmciPmlldGYub3JnPC9BPjxC Uj4mZ3Q7Jmd0OyZndDsgPEEgDQogICAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2F2dCIgDQogICAgICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PC9BPiANCiAgICAgICZndDs8QlI+Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IA0K ICAgICAgKiBSZWZlcmVuY2VzOiA8QlI+Jmd0OyZndDsgKiBbQVZUQ09SRV0gU3ViamVjdDogQUQg cmV2aWV3IG9mIA0KICAgICAgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMgPEJSPiZndDsm Z3Q7ICogRnJvbTogUm9iZXJ0IA0KICAgICAgU3BhcmtzPEJSPiZndDsmZ3Q7ICogUHJldiBieSBE YXRlOiBbQVZUQ09SRV0gUHJvdG9jb2wgQWN0aW9uOiAnRXhwbGljaXQgDQogICAgICBDb25nZXN0 aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBmb3IgUlRQIG92ZXIgPEJSPiZndDsmZ3Q7IFVEUCcgdG8g UHJvcG9zZWQgDQogICAgICBTdGFuZGFyZCAoZHJhZnQtaWV0Zi1hdnRjb3JlLWVjbi1mb3ItcnRw LTA4LnR4dCkgPEJSPiZndDsmZ3Q7ICogUHJldmlvdXMgDQogICAgICBieSB0aHJlYWQ6IFtBVlRD T1JFXSBTdWJqZWN0OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTMg DQogICAgICA8QlI+Jmd0OyZndDsgKiBOZXh0IGJ5IHRocmVhZDogW0FWVENPUkVdIFByb3RvY29s IEFjdGlvbjogJ0V4cGxpY2l0IA0KICAgICAgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikg Zm9yIFJUUCBvdmVyIDxCUj4mZ3Q7Jmd0OyBVRFAnIHRvIFByb3Bvc2VkIA0KICAgICAgU3RhbmRh cmQgKGRyYWZ0LWlldGYtYXZ0Y29yZS1lY24tZm9yLXJ0cC0wOC50eHQpIDxCUj4mZ3Q7Jmd0OyAq IEluZGV4KGVzKTogDQogICAgICA8QlI+Jmd0OyZndDsgKiBEYXRlPEJSPiZndDsmZ3Q7ICogVGhy ZWFkPEJSPiZndDsmZ3Q7IA0KICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188QlI+Jmd0OyZndDsgQXVkaW8vVmlkZW8gDQogICAgICBUcmFuc3BvcnQg Q29yZSBNYWludGVuYW5jZTxCUj4mZ3Q7Jmd0OyA8QSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3Jn IiANCiAgICAgIHltYWlsdG89Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT48 QlI+Jmd0OyZndDsgPEEgDQogICAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2F2dCIgDQogICAgICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0PC9BPjxCUj4mZ3Q7IA0KICAgICAgPEJSPiZndDsgPEJSPiZn dDsgPEJSPiZndDsgLS0gPEJSPiZndDsgQ29saW4gUGVya2luczxCUj4mZ3Q7IDxBIA0KICAgICAg aHJlZj0iaHR0cDovL2NzcGVya2lucy5vcmcvIiANCiAgICAgIHRhcmdldD1fYmxhbms+aHR0cDov L2NzcGVya2lucy5vcmcvPC9BPjxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KICAgICAgPEJSPjxCUj48QlI+ PEJSPi0tIDxCUj5Db2xpbiBQZXJraW5zPEJSPjxBIGhyZWY9Imh0dHA6Ly9jc3BlcmtpbnMub3Jn LyIgDQogICAgICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly9jc3BlcmtpbnMub3JnLzwvQT48QlI+PEJS PjxCUj48QlI+PEJSPjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9ESVY+PC9E SVY+PC9CTE9DS1FVT1RFPjwvRElWPjxCUj4NCiAgPERJViBhcHBsZS1jb250ZW50LWVkaXRlZD0i dHJ1ZSI+PFNQQU4gDQogIHN0eWxlPSJXSURPV1M6IDI7IFRFWFQtVFJBTlNGT1JNOiBub25lOyBU RVhULUlOREVOVDogMHB4OyBCT1JERVItQ09MTEFQU0U6IHNlcGFyYXRlOyBGT05UOiA5cHggQXJp YWw7IFdISVRFLVNQQUNFOiBub3JtYWw7IE9SUEhBTlM6IDI7IExFVFRFUi1TUEFDSU5HOiBub3Jt YWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC1ib3JkZXIt aG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwIiANCiAg Y2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj48U1BBTiANCiAgc3R5bGU9IldJRE9XUzogMjsgVEVYVC1U UkFOU0ZPUk06IG5vbmU7IFRFWFQtSU5ERU5UOiAwcHg7IEJPUkRFUi1DT0xMQVBTRTogc2VwYXJh dGU7IEZPTlQ6IDlweCAnTHVjaWRhIFNhbnMgVHlwZXdyaXRlcic7IFdISVRFLVNQQUNFOiBub3Jt YWw7IE9SUEhBTlM6IDI7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDAp OyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRl Y29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiIA0KICBjbGFzcz1BcHBsZS1zdHlsZS1z cGFuPjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhULVRSQU5TRk9STTogbm9uZTsgVEVY VC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBhcmF0ZTsgRk9OVDogOXB4ICdMdWNp ZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQSEFOUzogMjsgTEVU VEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4 OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXIt dmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0 OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG8iIA0KICBjbGFzcz1BcHBsZS1z dHlsZS1zcGFuPjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhULVRSQU5TRk9STTogbm9u ZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBhcmF0ZTsgRk9OVDogOXB4 ICdMdWNpZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQSEFOUzog MjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lO RzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1i b3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4t ZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG8iIA0KICBjbGFzcz1B cHBsZS1zdHlsZS1zcGFuPjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhULVRSQU5TRk9S TTogbm9uZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBhcmF0ZTsgRk9O VDogOXB4ICdMdWNpZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQ SEFOUzogMjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQt U1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdl YmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlv bnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG8iIA0KICBj bGFzcz1BcHBsZS1zdHlsZS1zcGFuPg0KICA8RElWPjxCUiBjbGFzcz1BcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lPjxCUiANCiAgY2xhc3M9a2h0bWwtYmxvY2stcGxhY2Vob2xkZXI+PC9ESVY+DQog IDxESVY+LS0mbmJzcDs8L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj5Db2xpbiBQZXJraW5z PC9ESVY+DQogIDxESVY+PEEgDQogIGhyZWY9Imh0dHA6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cDov L2NzcGVya2lucy5vcmcvPC9BPjwvRElWPjwvU1BBTj48L1NQQU4+PC9TUEFOPjxCUiANCiAgY2xh c3M9QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZT48L1NQQU4+PEJSIA0KICBjbGFzcz1BcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lPjwvU1BBTj48L0RJVj48QlI+PC9ESVY+DQogIDxQPg0KICA8SFI+ DQoNCiAgPFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPnhyYmxvY2sgbWFpbGluZyANCiAgbGlzdDxCUj54cmJsb2NrQGlldGYub3JnPEJSPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8veHJibG9jazxCUj48L0JMT0NLUVVP VEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_006D_01CD3B1E.9777A230-- From magnus.westerlund@ericsson.com Mon May 28 02:32:42 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B14321F84D5 for ; Mon, 28 May 2012 02:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 gZ5DfwYrKdO0 for ; Mon, 28 May 2012 02:32:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0C93F21F84A1 for ; Mon, 28 May 2012 02:32:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-fd-4fc34637c254 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 29.B9.00702.73643CF4; Mon, 28 May 2012 11:32:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Mon, 28 May 2012 11:32:39 +0200 Message-ID: <4FC34637.1050501@ericsson.com> Date: Mon, 28 May 2012 11:32:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvra6F22F/g3krWSxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqxVOgWNfBUXmg8wNzBu4+5i5OSQEDCROHXjJzOELSZx4d56 ti5GLg4hgVOMElcfH2KGcJYzSpyfeIsFpIpXQFvi/epvTCA2i4CqxIk7k1lBbDYBC4mbPxrZ QGxRgWCJF3uusELUC0qcnPkErFdEQElix6RtYEOFBZoZJaZ9Xc4KsVpS4uC/a+wgNrOAnsSU qy2MELa8RPPW2WDnCQEtbmjqYJ3AyD8LydxZSFpmIWlZwMi8ilE4NzEzJ73cXC+1KDO5uDg/ T684dRMjMNAObvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTBW8f84sJTzVnVAj/esTebbTjXe2/liumpqM0daRpMhX2rphkRXF78/Z7+dP334Wql2wTb1 thmHH9mGi1tJB+w5fiw1a4bIojCjI4dObVnhsvrC9JmaXkYvfqgkiSV0LD9dUHPGYAnHabVJ ZdbtFQprC6z+lirWns1Q+T77Z5Sy4xXz+0siFbSVWIozEg21mIuKEwGmOg60AgIAAA== Subject: [AVTCORE] Errata on RFC 4771 - "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 09:32:42 -0000 WG, Although not produced by this WG, as we are responsible for SRTP it might be of interest for this community to know that there has been field an errata on RFC 4771 - "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)" http://www.rfc-editor.org/errata_search.php?eid=3233 Errata ID: 3233 Status: Reported Type: Technical Reported By: Mats Näslund Date Reported: 2012-05-28 Section 2 says: When the receiver receives an SRTP packet, it processes the packet according to RFC 3711 except that during authentication processing ROC_local is replaced by ROC_sender (retrieved from the packet). It should say: When the receiver receives an SRTP packet, it processes the packet according to RFC 3711 except that during replay check and authentication processing ROC_local is replaced by ROC_sender (retrieved from the packet). Notes: While this is typo, it has the unfortunate side effect of creating a possibility for a replay attack where the attacker injects a previous message, possibly causing the receiver to loose synch on the ROC value. This is prevented if the receiver uses ROC_sender in place of ROC_local during both authentication _and_ replay check. We thank David McGrew for spotting this error. -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Mon May 28 05:46:46 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F135A21F8532 for ; Mon, 28 May 2012 05:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 DPtA5Y7FPJ7s for ; Mon, 28 May 2012 05:46:45 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6421F84CD for ; Mon, 28 May 2012 05:46:45 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SYzLQ-0004Pi-XD; Mon, 28 May 2012 12:46:44 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> Date: Mon, 28 May 2012 13:46:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98B4B634-5EC7-4822-A180-8C1F4258AFE2@csperkins.org> References: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> To: Roni Even X-Mailer: Apple Mail (2.1278) Cc: avt@ietf.org Subject: Re: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 12:46:46 -0000 On 23 May 2012, at 15:31, Roni Even wrote: > At last IETF meeting as part of the discussion on IDMS is was agreed = that support for leap seconds in RTP session is relevant to RFC3550 and = not only to IDMS. > We would like to take a new milestone for AVTcore >=20 > Nov 2012 - Submit support for leap seconds for RTP session as = Proposed Standard > This will be an update to RFC 3550. >=20 > We would also like to adopt = http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a = starting point for this goal. >=20 > There are two questions to the WGs >=20 > 1. Do you support the new milestone that will update RFC3550 > 2. Do you think that we should adopt the above individual draft = as an initial document I support the milestone, and that draft seems like a reasonable starting = point. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 28 05:51:22 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132D21F848A for ; Mon, 28 May 2012 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.121 X-Spam-Level: X-Spam-Status: No, score=-103.121 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, 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 2hrbypKliF+n for ; Mon, 28 May 2012 05:51:22 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id E9F0B21F847F for ; Mon, 28 May 2012 05:51:21 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SYzPs-0004h1-an; Mon, 28 May 2012 12:51:20 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4fbc94b3.c460b40a.6179.40b8@mx.google.com> Date: Mon, 28 May 2012 13:51:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4fbc94b3.c460b40a.6179.40b8@mx.google.com> To: Roni Even X-Mailer: Apple Mail (2.1278) Cc: 'Magnus Westerlund' , avt@ietf.org Subject: Re: [AVTCORE] adopting draft-williams-avtcore-clksrc-00 as a WG document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 12:51:22 -0000 On 23 May 2012, at 08:39, Roni Even wrote: > AVTcore have the following milestone: > Nov 2012 - Submit RTP Clock Source Signaling as Proposed Standard > =20 > The chairs propose to adopt = http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the = initial document to address this milestone. > =20 > The document will also be reviewed by the SDP directorate. > =20 > There are no other documents addressing this milestone so please let = the chairs know if you support this action by June 6th This is an important problem, and a real gap in the current standard. I = support the work, and this is a reasonable starting draft. --=20 Colin Perkins http://csperkins.org/ From marshall.eubanks@gmail.com Mon May 28 07:05:44 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C221F8619 for ; Mon, 28 May 2012 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 puf2Xrb7KX-G for ; Mon, 28 May 2012 07:05:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0017A21F8498 for ; Mon, 28 May 2012 07:05:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2251064lbb.31 for ; Mon, 28 May 2012 07:05:42 -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:content-transfer-encoding; bh=VkxTH/Fn2KjZE7Pw0Oa5CWDdd7+WDxa7T8gxRycHHOY=; b=JWIak1KqUKmQ2GBqA7gRrJ09daIHGmm2ZqVebL8f/ichZMonWHYBWHlp/L0xrWZ/nj 5l2DQylL7XXtEjYRRQwag1mGGk1jC5TaI1vNwe4JWgtXOY+hYvzRYvjw71Oylkn0G6Ak +sl7fMWPi332sW4JI3yLz10FtQQ9r5hexCXXtzDnmwnkgT1yfvPnE1+lvL5aheOH9FOf 0iTQ5clR8plI/my5Gf4bfC7Ubh43eIDQ/1K90Qk9yJLzJKHqcmYcSnaiMGCEY/BQPZdG Aty2Rs7wyVRs6l2qrU0N+X6oxvYDrpaGnNvjZCODMsZ6XjsE5QCVjzto5lf3cNxrgGdc wUQw== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr8661803lab.9.1338213941828; Mon, 28 May 2012 07:05:41 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Mon, 28 May 2012 07:05:41 -0700 (PDT) In-Reply-To: References: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> Date: Mon, 28 May 2012 10:05:41 -0400 Message-ID: From: Marshall Eubanks To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 14:05:44 -0000 On Wed, May 23, 2012 at 10:41 AM, Marshall Eubanks wrote: > On Wed, May 23, 2012 at 10:31 AM, Roni Even wrot= e: >> Hi, >> >> At last IETF meeting as part of the discussion on IDMS is was agreed tha= t >> support for leap seconds in RTP session is relevant to RFC3550 and not o= nly >> to IDMS. >> >> We would like to take a new milestone for AVTcore >> >> >> >> Nov 2012 - Submit support for leap seconds for RTP session =A0as Propose= d >> Standard >> >> This will be an update to RFC 3550. >> >> >> >> We would also like to adopt >> http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a start= ing >> point for this goal. >> >> >> >> There are two questions to the WGs >> >> >> >> 1.=A0=A0=A0=A0=A0=A0 Do you support the new milestone that will update R= FC3550 >> > > Support. > >> 2.=A0=A0=A0=A0=A0=A0 Do you think that we should adopt the above individ= ual draft as an >> initial document >> > > Need to read it first. It just came out. Having read it, I support its adoption. Note : Section 3 : When they occur, leap seconds are scheduled at the end of the last day of December and/or June each year. That is not what the standard says, although it has been the practice. In no more than a century, if leap seconds continue, there will _have_ to be more frequent updates. >From the USNO. http://www.usno.navy.mil/USNO/time/master-clock/leap-seconds "According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. Since the system was introduced in 1972, only dates in June and December have been used. " I think that CCIR Recommendation 460-4 (1986) should be added as a reference, and the above text be changed to When they occur, leap seconds are preferentially scheduled at the end of the last day of December and/or June each year, although they could also occur at the end of March or September. Regards Marshall > > Marshall > >> >> >> >> >> Please respond by June 6th >> >> >> >> Thanks >> >> Roni Even >> >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> From kevin.gross@avanw.com Mon May 28 08:16:42 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0088021F8625 for ; Mon, 28 May 2012 08:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 M6DSS-vYGatg for ; Mon, 28 May 2012 08:16:40 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 8635C21F8613 for ; Mon, 28 May 2012 08:16:40 -0700 (PDT) Received: (qmail 27921 invoked by uid 0); 28 May 2012 15:16:39 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 28 May 2012 15:16:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=bqCfLpB8qgFN0p7Tm0zBV0sXNLyeJGZUgZwbN29AHng=; b=dvnMpJe+BaYRbSZ77nt08wXPCyLiS3629bv6SiE5aS7ER3y5bGv0OOWCCRrjnftCG+opSumM9/uZEzWSODfMvhIbl55MNFEjFzPtZZsJqABOBWdhExmF+kb7KYTn/PFM; Received: from mail-wg0-f44.google.com ([74.125.82.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SZ1gU-0008GD-UT for avt@ietf.org; Mon, 28 May 2012 09:16:39 -0600 Received: by wgbdr13 with SMTP id dr13so2091422wgb.13 for ; Mon, 28 May 2012 08:16:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.196.91 with SMTP id q69mr4893080wen.185.1338218197435; Mon, 28 May 2012 08:16:37 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Mon, 28 May 2012 08:16:37 -0700 (PDT) In-Reply-To: References: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> Date: Mon, 28 May 2012 09:16:37 -0600 Message-ID: From: Kevin Gross To: Marshall Eubanks Content-Type: multipart/alternative; boundary=0016e6de00ac4a45da04c11a344c X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Cc: avt@ietf.org Subject: Re: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 15:16:42 -0000 --0016e6de00ac4a45da04c11a344c Content-Type: text/plain; charset=ISO-8859-1 Thank you for your comments. We will incorporate your suggestions. Kevin Gross On Mon, May 28, 2012 at 8:05 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Wed, May 23, 2012 at 10:41 AM, Marshall Eubanks > wrote: > > On Wed, May 23, 2012 at 10:31 AM, Roni Even > wrote: > >> Hi, > >> > >> At last IETF meeting as part of the discussion on IDMS is was agreed > that > >> support for leap seconds in RTP session is relevant to RFC3550 and not > only > >> to IDMS. > >> > >> We would like to take a new milestone for AVTcore > >> > >> > >> > >> Nov 2012 - Submit support for leap seconds for RTP session as Proposed > >> Standard > >> > >> This will be an update to RFC 3550. > >> > >> > >> > >> We would also like to adopt > >> http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a > starting > >> point for this goal. > >> > >> > >> > >> There are two questions to the WGs > >> > >> > >> > >> 1. Do you support the new milestone that will update RFC3550 > >> > > > > Support. > > > >> 2. Do you think that we should adopt the above individual draft > as an > >> initial document > >> > > > > Need to read it first. It just came out. > > Having read it, I support its adoption. > > Note : > > Section 3 : > > When > they occur, leap seconds are scheduled at the end of the last day of > December and/or June each year. > > That is not what the standard says, although it has been the practice. > In no more than a century, if leap seconds continue, there > will _have_ to be more frequent updates. > > From the USNO. > http://www.usno.navy.mil/USNO/time/master-clock/leap-seconds > > "According to the CCIR Recommendation, first preference is given to > the opportunities at the end of December and June, and second > preference to those at the end of March and September. Since the > system was introduced in 1972, only dates in June and December have > been used. " > > I think that CCIR Recommendation 460-4 (1986) should be added as a > reference, and the above text be changed to > > When > they occur, leap seconds are preferentially scheduled at the end of > the last day of > December and/or June each year, although they could also occur at > the end of March or September. > > Regards > Marshall > > > > > > > Marshall > > > >> > >> > >> > >> > >> Please respond by June 6th > >> > >> > >> > >> Thanks > >> > >> Roni Even > >> > >> > >> > >> > >> _______________________________________________ > >> Audio/Video Transport Core Maintenance > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > >> > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --0016e6de00ac4a45da04c11a344c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for your comments. We will incorporate your suggestions.


Kevin Gross

On M= on, May 28, 2012 at 8:05 AM, Marshall Eubanks <marshall.eubanks@g= mail.com> wrote:
On Wed, May 23, 2012 at 10= :41 AM, Marshall Eubanks
<marshall.eubanks@gmail.co= m> wrote:
> On Wed, May 23, 2012 at 10:31 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
>> Hi,
>>
>> At last IETF meeting as part of the discussion on IDMS is was agre= ed that
>> support for leap seconds in RTP session is relevant to RFC3550 and= not only
>> to IDMS.
>>
>> We would like to take a new milestone for AVTcore
>>
>>
>>
>> Nov 2012 - Submit support for leap seconds for RTP session =A0as P= roposed
>> Standard
>>
>> This will be an update to RFC 3550.
>>
>>
>>
>> We would also like to adopt
>> http://www.ietf.org/id/draft-gross-avtcore-leap-s= econd-00.txt as a starting
>> point for this goal.
>>
>>
>>
>> There are two questions to the WGs
>>
>>
>>
>> 1.=A0=A0=A0=A0=A0=A0 Do you support the new milestone that will up= date RFC3550
>>
>
> Support.
>
>> 2.=A0=A0=A0=A0=A0=A0 Do you think that we should adopt the above i= ndividual draft as an
>> initial document
>>
>
> Need to read it first. It just came out.

Having read it, I support its adoption.

Note :

Section 3 :

When
=A0 they occur, leap seconds are scheduled at the end of the last day of =A0 December and/or June each year.

That is not what the standard says, although it has been the practice.
In no more than a century, if leap seconds continue, there
will _have_ to be more frequent updates.

>From the USNO. http://www.usno.navy.mil/USNO/time/master-cl= ock/leap-seconds

"According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second
preference to those at the end of March and September. Since the
system was introduced in 1972, only dates in June and December have
been used. "

I think that =A0CCIR Recommendation 460-4 (1986) should be added as a
reference, and the above text be changed to

=A0 When
=A0 they occur, leap seconds are preferentially scheduled at the end of the last day of
=A0 December and/or June each year, although they could also occur at
the end of March or September.

Regards
Marshall



>
> Marshall
>
>>
>>
>>
>>
>> Please respond by June 6th
>>
>>
>>
>> Thanks
>>
>> Roni Even
>>
>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--0016e6de00ac4a45da04c11a344c-- From internet-drafts@ietf.org Mon May 28 19:25:57 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3702921F87A4; Mon, 28 May 2012 19:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, 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 UiM3rPOgIRiJ; Mon, 28 May 2012 19:25:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C613221F855F; Mon, 28 May 2012 19:25:56 -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.02 Message-ID: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> Date: Mon, 28 May 2012 19:25:56 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 02:25:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architecture for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-14.txt Pages : 27 Date : 2012-05-28 This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guidelines established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ From bill.wu@huawei.com Mon May 28 19:37:13 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79F921F8767 for ; Mon, 28 May 2012 19:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 7ebkq6pdpBLT for ; Mon, 28 May 2012 19:37:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14CDA21F8740 for ; Mon, 28 May 2012 19:37:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGP80051; Mon, 28 May 2012 22:37:12 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 19:35:22 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 19:35:23 -0700 Received: from w53375 (10.138.41.149) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 29 May 2012 10:35:21 +0800 Message-ID: From: Qin Wu To: Roni Even , References: <4fbcf53c.0387cd0a.095f.ffff9ffa@mx.google.com> Date: Tue, 29 May 2012 10:35:20 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01CD3D86.BF608C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] New mile stone on support for leap seconds in RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 02:37:13 -0000 ------=_NextPart_000_0127_01CD3D86.BF608C20 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFJvbmkgRXZlbiANCiAg VG86IGF2dEBpZXRmLm9yZyANCiAgU2VudDogV2VkbmVzZGF5LCBNYXkgMjMsIDIwMTIgMTA6MzEg UE0NCiAgU3ViamVjdDogW0FWVENPUkVdIE5ldyBtaWxlIHN0b25lIG9uIHN1cHBvcnQgZm9yIGxl YXAgc2Vjb25kcyBpbiBSVFAgc2Vzc2lvbnMNCg0KDQogIEhpLA0KDQogIEF0IGxhc3QgSUVURiBt ZWV0aW5nIGFzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gb24gSURNUyBpcyB3YXMgYWdyZWVkIHRo YXQgc3VwcG9ydCBmb3IgbGVhcCBzZWNvbmRzIGluIFJUUCBzZXNzaW9uIGlzIHJlbGV2YW50IHRv IFJGQzM1NTAgYW5kIG5vdCBvbmx5IHRvIElETVMuDQoNCiAgV2Ugd291bGQgbGlrZSB0byB0YWtl IGEgbmV3IG1pbGVzdG9uZSBmb3IgQVZUY29yZQ0KDQogICANCg0KICBOb3YgMjAxMiAtIFN1Ym1p dCBzdXBwb3J0IGZvciBsZWFwIHNlY29uZHMgZm9yIFJUUCBzZXNzaW9uICBhcyBQcm9wb3NlZCBT dGFuZGFyZA0KDQogIFRoaXMgd2lsbCBiZSBhbiB1cGRhdGUgdG8gUkZDIDM1NTAuDQoNCiAgIA0K DQogIFdlIHdvdWxkIGFsc28gbGlrZSB0byBhZG9wdCBodHRwOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWdyb3NzLWF2dGNvcmUtbGVhcC1zZWNvbmQtMDAudHh0IGFzIGEgc3RhcnRpbmcgcG9pbnQg Zm9yIHRoaXMgZ29hbC4NCg0KICAgDQoNCiAgVGhlcmUgYXJlIHR3byBxdWVzdGlvbnMgdG8gdGhl IFdHcw0KDQogICANCg0KICAxLiAgICAgICBEbyB5b3Ugc3VwcG9ydCB0aGUgbmV3IG1pbGVzdG9u ZSB0aGF0IHdpbGwgdXBkYXRlIFJGQzM1NTANCg0KW1Fpbl06IFN1cHBvcnQuDQoNCiAgMi4gICAg ICAgRG8geW91IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGFkb3B0IHRoZSBhYm92ZSBpbmRpdmlkdWFs IGRyYWZ0IGFzIGFuIGluaXRpYWwgZG9jdW1lbnQNCg0KDQoNCltRaW5dOkl0IGlzIG9uIHRoZSBy aWdodCB0cmFjay4NCg0KICAgDQoNCiAgIA0KDQogIFBsZWFzZSByZXNwb25kIGJ5IEp1bmUgNnRo DQoNCiAgIA0KDQogIFRoYW5rcw0KDQogIFJvbmkgRXZlbg0KDQogICANCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCiAg YXZ0QGlldGYub3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 DQo= ------=_NextPart_000_0127_01CD3D86.BF608C20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkyMjIi Pg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYW1icmlhIE1hdGg7DQp9DQpA Zm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9u MSB7c2l6ZTogOC41aW4gMTEuMGluOyBtYXJnaW46IDEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47 IH0NClAuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIkNh bGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAxMXB0DQp9DQpMSS5Nc29Ob3JtYWwgew0K CU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYi OyBGT05ULVNJWkU6IDExcHQNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAw cHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBt c28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJs dWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9 DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5l OyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsN CglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXBy aW9yaXR5OiA5OQ0KfQ0KUFJFIHsNCglNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTog IkNvdXJpZXIgTmV3IjsgRk9OVC1TSVpFOiAxMHB0OyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5OyBt c28tc3R5bGUtbGluazogIkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiDQp9DQpQLk1zb0xpc3RQYXJh Z3JhcGggew0KCU1BUkdJTjogMGluIDBpbiAwcHQgMC41aW47IEZPTlQtRkFNSUxZOiAiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQ7IG1zby1zdHlsZS1wcmlvcml0eTogMzQN Cn0NCkxJLk1zb0xpc3RQYXJhZ3JhcGggew0KCU1BUkdJTjogMGluIDBpbiAwcHQgMC41aW47IEZP TlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQ7IG1zby1z dHlsZS1wcmlvcml0eTogMzQNCn0NCkRJVi5Nc29MaXN0UGFyYWdyYXBoIHsNCglNQVJHSU46IDBp biAwaW4gMHB0IDAuNWluOyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9O VC1TSVpFOiAxMXB0OyBtc28tc3R5bGUtcHJpb3JpdHk6IDM0DQp9DQpTUEFOLkVtYWlsU3R5bGUx NyB7DQoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiB3aW5kb3d0 ZXh0OyBtc28tc3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KU1BBTi5IVE1MUHJlZm9y bWF0dGVkQ2hhciB7DQoJRk9OVC1GQU1JTFk6ICJDb3VyaWVyIE5ldyI7IG1zby1zdHlsZS1wcmlv cml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiSFRNTCBQcmVmb3JtYXR0ZWQiOyBtc28tc3R5bGUt bmFtZTogIkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiDQp9DQouTXNvQ2hwRGVmYXVsdCB7DQoJbXNv LXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5DQp9DQpESVYuV29yZFNlY3Rpb24xIHsNCglwYWdlOiBX b3JkU2VjdGlvbjENCn0NCk9MIHsNCglNQVJHSU4tQk9UVE9NOiAwaW4NCn0NClVMIHsNCglNQVJH SU4tQk9UVE9NOiAwaW4NCn0NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvSEVBRD4NCjxCT0RZIGxhbmc9RU4tVVMgbGluaz1ibHVlIGJn Q29sb3I9I2ZmZmZmZiB2TGluaz1wdXJwbGU+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1S SUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3Ozsg QkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAg PEEgdGl0bGU9cm9uLmV2ZW4udGx2QGdtYWlsLmNvbSBocmVmPSJtYWlsdG86cm9uLmV2ZW4udGx2 QGdtYWlsLmNvbSI+Um9uaSANCiAgRXZlbjwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWF2dEBpZXRmLm9yZyAN CiAgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9BPiA8L0RJVj4NCiAg PERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBXZWRu ZXNkYXksIE1heSAyMywgMjAxMiAxMDozMSBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFtBVlRDT1JFXSBOZXcgbWlsZSBz dG9uZSBvbiBzdXBwb3J0IA0KICBmb3IgbGVhcCBzZWNvbmRzIGluIFJUUCBzZXNzaW9uczwvRElW Pg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1Xb3JkU2VjdGlvbjE+DQogIDxQIGNs YXNzPU1zb05vcm1hbD5IaSw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkF0 IGxhc3QgSUVURiBtZWV0aW5nIGFzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gb24gSURNUyBpcyAN CiAgd2FzIGFncmVlZCB0aGF0IHN1cHBvcnQgZm9yIGxlYXAgc2Vjb25kcyBpbiBSVFAgc2Vzc2lv biBpcyByZWxldmFudCB0byBSRkMzNTUwIA0KICBhbmQgbm90IG9ubHkgdG8gSURNUy48bzpwPjwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPldlIHdvdWxkIGxpa2UgdG8gdGFrZSBhIG5l dyBtaWxlc3RvbmUgZm9yIA0KICBBVlRjb3JlPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPk5vdiAy MDEyIC0gU3VibWl0IHN1cHBvcnQgZm9yIGxlYXAgc2Vjb25kcyBmb3IgUlRQIHNlc3Npb24gDQog ICZuYnNwO2FzIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD5UaGlzIHdpbGwgYmUgYW4gdXBkYXRlIHRvIFJGQyAzNTUwLjxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD5XZSB3b3VsZCBhbHNvIGxpa2UgdG8gYWRvcHQgPEEgDQogIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ3Jvc3MtYXZ0Y29yZS1sZWFwLXNlY29uZC0wMC50eHQi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ3Jvc3MtYXZ0Y29yZS1sZWFwLXNlY29uZC0w MC50eHQ8L0E+IA0KICBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGlzIGdvYWwuPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPlRoZXJlIGFyZSB0d28gcXVlc3Rpb25zIHRvIHRoZSBXR3M8bzpwPjwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPjwhW2lm ICFzdXBwb3J0TGlzdHNdPg0KICA8UCBzdHlsZT0iVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1s aXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PFNQQU4gc3R5 bGU9Im1zby1saXN0OiBJZ25vcmUiPjEuPFNQQU4gDQogIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVz IE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9T UEFOPjwvU1BBTj48IVtlbmRpZl0+PFNQQU4gZGlyPWx0cj48L1NQQU4+RG8geW91IHN1cHBvcnQg dGhlIG5ldyBtaWxlc3RvbmUgDQogIHRoYXQgd2lsbCB1cGRhdGUgUkZDMzU1MDwvUD48L0RJVj48 L0JMT0NLUVVPVEU+DQo8UCBzdHlsZT0iVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1saXN0OiBs MCBsZXZlbDEgbGZvMSIgDQpjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxGT05UIHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiANClN1cHBvcnQuPC9GT05UPjwvUD48IVtpZiAhc3Vw cG9ydExpc3RzXT4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJw eCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxF RlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8UCBzdHlsZT0iVEVYVC1JTkRFTlQ6IC0w LjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogIGNsYXNzPU1zb0xpc3RQYXJhZ3Jh cGg+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPjIuPFNQQU4gDQogIHN0eWxlPSJGT05U OiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCiAgPC9TUEFOPjwvU1BBTj48IVtlbmRpZl0+PFNQQU4gZGlyPWx0cj48L1NQQU4+RG8g eW91IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGFkb3B0IA0KICB0aGUgYWJvdmUgaW5kaXZpZHVhbCBk cmFmdCBhcyBhbiBpbml0aWFsIGRvY3VtZW50PC9QPg0KICA8UCBzdHlsZT0iVEVYVC1JTkRFTlQ6 IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgDQogIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+Jm5ic3A7PC9QPjwvQkxPQ0tRVU9URT4NCjxQIHN0eWxlPSJURVhULUlOREVOVDogLTAu MjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiANCmNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+ PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1Fpbl06SXQgaXMgb24gdGhlIA0K cmlnaHQgdHJhY2suPC9GT05UPjwvUD4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZU OiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBw eDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPlBsZWFzZSByZXNwb25kIGJ5IEp1 bmUgNjxTVVA+dGg8L1NVUD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD5Sb25pIEV2ZW48bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UD4NCiAgPEhSPg0K DQogIDxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxCUj5BdWRpby9WaWRlbyANCiAgVHJhbnNwb3J0IENvcmUgDQogIE1haW50ZW5hbmNlPEJSPmF2 dEBpZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDxC Uj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0127_01CD3D86.BF608C20-- From magnus.westerlund@ericsson.com Wed May 30 06:49:08 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3769021F8699 for ; Wed, 30 May 2012 06:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 YC1LnZN1GM7W for ; Wed, 30 May 2012 06:49:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3055121F8687 for ; Wed, 30 May 2012 06:49:06 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-b9-4fc62551de45 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4C.AC.11869.15526CF4; Wed, 30 May 2012 15:49:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Wed, 30 May 2012 15:49:05 +0200 Message-ID: <4FC62550.7000707@ericsson.com> Date: Wed, 30 May 2012 15:49:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , Colin Perkins , albrechtschwarz@yahoo.de References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> In-Reply-To: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvrW6g6jF/gyuzLC1WnTvIaPGyZyW7 xfKXJxgdmD2m3b/P5rFkyU8mjwk3HjMGMEdx2aSk5mSWpRbp2yVwZSz/d4694Kxoxf2VLSwN jI2CXYwcHBICJhJzT8l2MXICmWISF+6tZ+ti5OIQEjjFKLGmuw/KWc4ocXRZHyNIFa+AtsTX D9+ZQGwWAVWJbdu/gMXZBCwkbv5oZAOxRQWCJV7sucIKUS8ocXLmExYQW0QgSaLtwVIwW1jA SuL8t11g9UICDhKLXlwBm8kp4Chxq+UzI8RFkhIH/11jB7GZBfQkplxtYYSw5SWat85mhujV lmho6mCdwCg4C8m6WUhaZiFpWcDIvIpRODcxMye93EgvtSgzubg4P0+vOHUTIzB8D275rbqD 8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgbA2a0HU82TK7plHm mO22NXNfKW5wOr/MtHPzmtKLV7pkPQK2uX9+x559zoXzuAiXsGDuvxsea1PndYXk/Xu+rMxz 6smPl4+UfJk+6ZewqvY38XldN9cmH1e16rR6OHHF5IjHUW4GgbrLpt1wdDye65ycwP5B1D34 w7+j5elTj19U2XjmhEWDqRJLcUaioRZzUXEiALqm/VYtAgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 13:49:08 -0000 WG, Colin and Albrecht, Please check if you think the changes in this version are appropriate. Cheers Magnus On 2012-05-29 04:25, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Monitoring Architecture for RTP > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-14.txt > Pages : 27 > Date : 2012-05-28 > > This memo proposes an architecture for extending RTP Control Protocol > (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to > report new metrics regarding media transmission or reception quality, > following RTCP guidelines established in RFC5968. This memo suggests > that a new block should contain a single metric or a small number of > metrics relevant to a single parameter of interest or concern, rather > than containing a number of metrics which attempt to provide full > coverage of all those parameters of concern to a specific > application. Applications may then "mix and match" to create a set > of blocks which covers their set of concerns. Where possible, a > specific block should be designed to be re-usable across more than > one application, for example, for all of voice, streaming audio and > video. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed May 30 07:28:17 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7721F85CC for ; Wed, 30 May 2012 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.208 X-Spam-Level: X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 JQUI8tbWW6Op for ; Wed, 30 May 2012 07:28:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1397421F86B1 for ; Wed, 30 May 2012 07:28:15 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-3e-4fc62e7eb6ee Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E2.6D.00702.E7E26CF4; Wed, 30 May 2012 16:28:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Wed, 30 May 2012 16:28:14 +0200 Message-ID: <4FC62E7D.30402@ericsson.com> Date: Wed, 30 May 2012 16:28:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> <4FC62550.7000707@ericsson.com> In-Reply-To: <4FC62550.7000707@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VrdO75i/Qe97PYuXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsevAM7aCa9IVKy48YWpg/CLaxcjJISFgIjH122s2CFtM4sK9 9UA2F4eQwClGiR9LL7NDOMsZJbo3toFV8QpoSrxrng1mswioStx4OY8FxGYTsJC4+aMRLC4q ECzxYs8VVoh6QYmTM5+A1YgICEis2P4XzBYWcJF4v+E1YxcjB9CCBIk3P6xBwpwCOhKNN74z QRwkKXHw3zV2EJtZQE9iytUWRghbXqJ562xmEFtIQFuioamDdQKj4Cwk22YhaZmFpGUBI/Mq RuHcxMyc9HJzvdSizOTi4vw8veLUTYzAsDy45bfBDsZN98UOMUpzsCiJ8+qp7vcXEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwHj0/Zap7o+ubkh75rPjqBfTu9KVVVqftPcmLlFYpvvXLqR+ t/2ZbZ1/DJvsXx6/bRq4aMU3h7xZurp9JrL22dfU2zUZvr14nrTJslBrye2Fausrt7Ydfqb3 csNf87lV02SuSZsd3725yETh2R6xF2acL587HtgfO6m9Tm7GBqu04y8fn+J7Z35fiaU4I9FQ i7moOBEAGNDVoBkCAAA= Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 14:28:17 -0000 WG, My individual review of the changes are the following. 1. I think section 3 would really benefit from a figure of the possible locations of RTP monitors. I think it should focus on the location rather than the full flow of the collected information. Thus become simpler than the removed figure. 2. I also wonder if we shouldn't really remove the word architecture from this document and instead have the title be "Guidelines for the RTP Monitoring Framework" 3. In some sense I wished we could keep the old figure 1 somewhere in the document. But I guess it would require even more discussion around the management system. Cheers Magnus On 2012-05-30 15:49, Magnus Westerlund wrote: > WG, Colin and Albrecht, > > Please check if you think the changes in this version are appropriate. > > Cheers > > Magnus > > On 2012-05-29 04:25, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. >> >> Title : Monitoring Architecture for RTP >> Author(s) : Qin Wu >> Geoff Hunt >> Philip Arden >> Filename : draft-ietf-avtcore-monarch-14.txt >> Pages : 27 >> Date : 2012-05-28 >> >> This memo proposes an architecture for extending RTP Control Protocol >> (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to >> report new metrics regarding media transmission or reception quality, >> following RTCP guidelines established in RFC5968. This memo suggests >> that a new block should contain a single metric or a small number of >> metrics relevant to a single parameter of interest or concern, rather >> than containing a number of metrics which attempt to provide full >> coverage of all those parameters of concern to a specific >> application. Applications may then "mix and match" to create a set >> of blocks which covers their set of concerns. Where possible, a >> specific block should be designed to be re-usable across more than >> one application, for example, for all of voice, streaming audio and >> video. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From albrechtschwarz@yahoo.de Wed May 30 09:34:54 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B93B21F864C for ; Wed, 30 May 2012 09:34:54 -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 0TIXSfnLyQr7 for ; Wed, 30 May 2012 09:34:52 -0700 (PDT) Received: from nm23-vm4.bullet.mail.ukl.yahoo.com (nm23-vm4.bullet.mail.ukl.yahoo.com [217.146.176.134]) by ietfa.amsl.com (Postfix) with SMTP id 65B0021F864A for ; Wed, 30 May 2012 09:34:52 -0700 (PDT) Received: from [217.146.183.215] by nm23.bullet.mail.ukl.yahoo.com with NNFMP; 30 May 2012 16:34:46 -0000 Received: from [217.146.183.169] by tm8.bullet.mail.ukl.yahoo.com with NNFMP; 30 May 2012 16:34:46 -0000 Received: from [127.0.0.1] by omp1010.mail.ukl.yahoo.com with NNFMP; 30 May 2012 16:34:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 615964.10342.bm@omp1010.mail.ukl.yahoo.com Received: (qmail 50951 invoked by uid 60001); 30 May 2012 16:34:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1338395686; bh=xbRpukqFGhRZnCLC8XqueiwDVymNbHNaRONtrSUFegg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h/WU9eINZ/m/7YdpWYOdyLdKWZU8dw2QYFPhdL8buvV8aNq4v5rJ8kiYIW9CpxFE5/a14Ext1abG6Skcw0gFS8cTqcqYDB5GlAvN3a6RZSTM/7OWyKn7+YqybXBC7HyL1XAjD4fN7yCv7oxe/F2NdRaGPQdkj+cytsQAco6OwfI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r8CpdP4rF+lWD+RXDO4WqSDEL808TyTmGTejT5Emfrk7ychNrsthud8cIXGDOzM8FHSMqQOJJXJlBVAUUhoI3Ounkk4Jmp8R0Czq5dSjJCp8VBHRQBv8MD17wS5uM87/CSX1WBTOp9lS8dnUcZCR3LxaHjsvyxI20wXYtgsdvN8=; X-YMail-OSG: zgntGJUVM1lhM9QztnzefkyCGzD5eFF3xWSApvcuffdcRHT lYbu8KMF4C_WxogtRLEOMBQKz2jJjS2F9yxlW7.n4sCsdAF_TsAV8avOgGXl DtqZbeJXXNKjYLYnZ1KKllcjT1pRL8GQ0lmM3nufwZOcp4ecKu4_JBsICnP6 KOaY8O607IWNpmT3pO9iUnNThnW_P3UhztTJBkyNs7Z0dGTdXOhZICggPWuT 8USCNNTk9BMCvlpoo5zgexM3LJ1iIW0REaHbn1ESYKHxdlyUPaK355Q2UdO1 DD9B1z73eux4IDvXlm2hUni1pQ7QsfuVPga0t1bVLFHSmMFUFDeUOB4viPEn 3jkBkkUBo6xTZbEOV.Dh7UA.OzTabizTkWZcOxhlH4UQ5LROB6tUx6bmxycg FizLv4emwXHVcTlhg3jxArkggVP2YMv0VeBpwyWUa8b1aNvjcvQ-- Received: from [95.115.240.167] by web171006.mail.ukl.yahoo.com via HTTP; Wed, 30 May 2012 17:34:46 BST X-Mailer: YahooMailWebService/0.8.118.349524 References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> <4FC62550.7000707@ericsson.com> Message-ID: <1338395686.39740.YahooMailNeo@web171006.mail.ukl.yahoo.com> Date: Wed, 30 May 2012 17:34:46 +0100 (BST) From: Albrecht Schwarz To: Magnus Westerlund , IETF AVTCore WG , Colin Perkins In-Reply-To: <4FC62550.7000707@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Albrecht Schwarz List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 16:34:54 -0000 OK for me.=0A-Albrecht=0A=0A=0A=0A----- Urspr=FCngliche Message -----=0A> V= on: Magnus Westerlund =0A> An: IETF AVTCore= WG ; Colin Perkins ; albrechtschwarz@yaho= o.de=0A> CC: =0A> Gesendet: 15:49 Mittwoch, 30.Mai 2012=0A> Betreff: Re: I-= D Action: draft-ietf-avtcore-monarch-14.txt=0A> =0A> WG, Colin and Albrecht= ,=0A> =0A> Please check if you think the changes in this version are approp= riate.=0A> =0A> Cheers=0A> =0A> Magnus=0A> =0A> On 2012-05-29 04:25, intern= et-drafts@ietf.org wrote:=0A>> =0A>> A New Internet-Draft is available fro= m the on-line Internet-Drafts =0A> directories. This draft is a work item o= f the Audio/Video Transport Core =0A> Maintenance Working Group of the IETF= .=0A>> =0A>> =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Monitoring Architecture= for RTP=0A>> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Qin Wu=0A>> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Geoff Hunt=0A>> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Philip Arden=0A>> =A0=A0=A0 Filename= =A0 =A0 =A0 =A0 : draft-ietf-avtcore-monarch-14.txt=0A>> =A0=A0=A0 Pages= =A0 =A0 =A0 =A0 =A0 : 27=0A>> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 201= 2-05-28=0A>> =0A>> =A0 =A0 This memo proposes an architecture for extending= RTP Control Protocol=0A>> =A0 =A0 (RTCP) with a new RTCP Extended Reports = (XR) (RFC3611) block type to=0A>> =A0 =A0 report new metrics regarding medi= a transmission or reception quality,=0A>> =A0 =A0 following RTCP guidelines= established in RFC5968.=A0 This memo suggests=0A>> =A0 =A0 that a new bloc= k should contain a single metric or a small number of=0A>> =A0 =A0 metrics = relevant to a single parameter of interest or concern, rather=0A>> =A0 =A0 = than containing a number of metrics which attempt to provide full=0A>> =A0 = =A0 coverage of all those parameters of concern to a specific=0A>> =A0 =A0 = application.=A0 Applications may then "mix and match" to create =0A> a set= =0A>> =A0 =A0 of blocks which covers their set of concerns.=A0 Where possib= le, a=0A>> =A0 =A0 specific block should be designed to be re-usable across= more than=0A>> =A0 =A0 one application, for example, for all of voice, str= eaming audio and=0A>> =A0 =A0 video.=0A>> =0A>> =0A>> A URL for this Inter= net-Draft is:=0A>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-= monarch-14.txt=0A>> =0A>> Internet-Drafts are also available by anonymous = FTP at:=0A>> ftp://ftp.ietf.org/internet-drafts/=0A>> =0A>> This Internet= -Draft can be retrieved at:=0A>> ftp://ftp.ietf.org/internet-drafts/draft-= ietf-avtcore-monarch-14.txt=0A>> =0A>> The IETF datatracker page for this = Internet-Draft is:=0A>> https://datatracker.ietf.org/doc/draft-ietf-avtcor= e-monarch/=0A>> =0A>> _______________________________________________=0A>>= I-D-Announce mailing list=0A>> I-D-Announce@ietf.org=0A>> https://www.i= etf.org/mailman/listinfo/i-d-announce=0A>> Internet-Draft directories: htt= p://www.ietf.org/shadow.html=0A>> or ftp://ftp.ietf.org/ietf/1shadow-sites= .txt=0A>> =0A>> =0A> =0A> =0A> -- =0A> =0A> Magnus Westerlund=0A> =0A> ----= ------------------------------------------------------------------=0A> Mult= imedia Technologies, Ericsson Research EAB/TVM=0A> ------------------------= ----------------------------------------------=0A> Ericsson AB=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | Phone=A0 +46 10 7148287=0A> F=E4r=F6gatan 6=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079=0A> SE-164 80 Stockholm, Sw= eden| mailto: magnus.westerlund@ericsson.com=0A> --------------------------= --------------------------------------------=0A> From bill.wu@huawei.com Wed May 30 19:06:33 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FC321F869E for ; Wed, 30 May 2012 19:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 kvcGfBSou9OL for ; Wed, 30 May 2012 19:06:32 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF421F869D for ; Wed, 30 May 2012 19:06:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGS30915; Wed, 30 May 2012 22:06:31 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 May 2012 19:03:28 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 May 2012 19:03:32 -0700 Received: from w53375 (10.138.41.149) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 31 May 2012 10:03:25 +0800 Message-ID: <114BEA37E68543458F3F22DFC709324E@china.huawei.com> From: Qin Wu To: Magnus Westerlund , References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com><4FC62550.7000707@ericsson.com> <4FC62E7D.30402@ericsson.com> Date: Thu, 31 May 2012 10:03:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 02:06:33 -0000 SGksIE1hZ251czoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiTWFnbnVz IFdlc3Rlcmx1bmQiIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpUbzogPGF2dEBp ZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDMwLCAyMDEyIDEwOjI4IFBNDQpTdWJqZWN0 OiBSZTogW0FWVENPUkVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE0 LnR4dA0KDQoNCldHLA0KDQpNeSBpbmRpdmlkdWFsIHJldmlldyBvZiB0aGUgY2hhbmdlcyBhcmUg dGhlIGZvbGxvd2luZy4NCg0KMS4gSSB0aGluayBzZWN0aW9uIDMgd291bGQgcmVhbGx5IGJlbmVm aXQgZnJvbSBhIGZpZ3VyZSBvZiB0aGUgcG9zc2libGUNCmxvY2F0aW9ucyBvZiBSVFAgbW9uaXRv cnMuIEkgdGhpbmsgaXQgc2hvdWxkIGZvY3VzIG9uIHRoZSBsb2NhdGlvbg0KcmF0aGVyIHRoYW4g dGhlIGZ1bGwgZmxvdyBvZiB0aGUgY29sbGVjdGVkIGluZm9ybWF0aW9uLiBUaHVzIGJlY29tZQ0K c2ltcGxlciB0aGFuIHRoZSByZW1vdmVkIGZpZ3VyZS4NCg0KW1Fpbl06IEkgdGhvdWdodCB0aGUg ZmlndXJlIDEgaGFzIGFscmVhZHkgYmVlbiBpbmNvcG9yYXRlZCBpbnRvIHNldGlvbiAzIGFuZCBy ZXBsYWNlZCBieSB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIHNlY3Rpb24gMy4NCkJhc2VkIG9uIHlv dXIgY29tbWVudCwgSSBjYW4gcHJvcG9zZSB0byBoYXZlIHRoZSBmb2xsb3dpbmcgZmlndXJlDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tfA0KICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAg ICAgfCAgICAgICAgICAgICAgICAgIHwgTWFuYWdlbWVudCB8ICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICBTeXN0ZW0gICA8LS0tLS0gICAgICAgICAg ICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgIHwgICAg ICAgICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICstLS0tLS1eLS0tLS0rICAg IHwgICAgICAgICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsgIHwgICAgICAgICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgfA0KICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCBUaGlyZCBQYXJ0eSAgIHwgIHwgICAgICAgICAgICAgfA0KICAgICAgICAg fCAgICAgICAgICAgICAgICAgfCBSVFAgTW9uaXRvciAgIHwgIHwgICAgICAgICAgICAgfA0KICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAg fA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwgICAgICAg ICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgfA0KICstLS0tLS0tfC0tLS0tLS0rICAgICAgICAgK0ludGVybWVkaWF0ZSAt LSsgIHwgICAgKy0tLS0tLS0tfC0tLS0tLSsNCiB8UlRQIFNlbmRlciAgICAgfCAgICAgICAgIHwg UlRQIFN5c3RlbSAgICB8ICB8ICAgIHxSVFAgUmVjZWl2ZXIgICB8DQogfCAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgICAgfC0tLSAgICB8ICAgICAgICAgICAgICAgfA0KIHwg Ky0tLS0tLS0tLS0tKyB8ICAgICAgICAgfCArLS0tLS0tLS0tLS0rIHwgICAgICAgfCArLS0tLS0t LS0tLS0rIHwNCiB8IHxSVFAgTW9uaXRvcnwgfCAgUlRQICAgIHwgfFJUUCBNb25pdG9yfCB8IFJU UCAgIHwgfFJUUCBNb25pdG9yfCB8DQogfCArLS0tLS0tLS0tLS0rIHwgU3RyZWFtICB8ICstLS0t LS0tLS0tLSsgfFN0cmVhbSB8ICstLS0tLS0tLS0tLSsgfA0KIHwgICAgICAgICAgICAgICB8LS0t LS0tLS0+fCAgICAgICAgICAgICAgIHwtLS0tLS0+fCAgICAgICAgICAgICAgIHwNCiB8ICAgICAg ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAg ICB8DQogKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAr LS0tLS0tLS0tLS0tLS0tKw0KSXMgdGhpcyBmaWd1cmUgd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9y Pw0KDQoyLiBJIGFsc28gd29uZGVyIGlmIHdlIHNob3VsZG4ndCByZWFsbHkgcmVtb3ZlIHRoZSB3 b3JkIGFyY2hpdGVjdHVyZQ0KZnJvbSB0aGlzIGRvY3VtZW50IGFuZCBpbnN0ZWFkIGhhdmUgdGhl IHRpdGxlIGJlICJHdWlkZWxpbmVzIGZvciB0aGUgUlRQDQpNb25pdG9yaW5nIEZyYW1ld29yayIN Cg0KW1Fpbl06IEFyZSB5b3UgcHJvcG9zaW5nIHRvIHJlcGxhY2UgdGhlIHdvcmQgImFyY2hpdGVj dHVyZSIgd2l0aCAiZnJhbWV3b3JrIj8NCg0KMy4gSW4gc29tZSBzZW5zZSBJIHdpc2hlZCB3ZSBj b3VsZCBrZWVwIHRoZSBvbGQgZmlndXJlIDEgc29tZXdoZXJlIGluDQp0aGUgZG9jdW1lbnQuIEJ1 dCBJIGd1ZXNzIGl0IHdvdWxkIHJlcXVpcmUgZXZlbiBtb3JlIGRpc2N1c3Npb24gYXJvdW5kDQp0 aGUgbWFuYWdlbWVudCBzeXN0ZW0uDQoNCltRaW5dOiBNYW5hZ2VtZW50IHN5c3RlbSBtYXkgbm90 IGhhdmUgUlRQIGZ1bmN0aW9uYWxpdHkuIFRoZXJlZm9yZSBzaG91bGRuJ3QgaXQgYmUNCmJleW9u ZCBzY29wZSBvZiB0aGUgUlRQIG1vbml0b3JpbmcgYXJjaGl0ZWN0dXJlPyBJbiB0aGUgY3VycmVu dCBkcmFmdCwgd2UgaGF2ZSBicmllZmx5IA0KZGlzY3Vzc2VkIGludGVyYWN0aW9uIGJldHdlZW4g UlRQIG1vbml0b3IgYW5kIG1hbmFnZW1lbnQgc3lzdGVtIHdpdGggdGhlIGZvbGxvd2luZw0KZGVz Y3JpcHRpb246DQoiDQpUaGUgUlRQIG1vbml0b3IgYWxzbyBleHBvc2VzIHJlYWwgdGltZSBBcHBs aWNhdGlvbiBRb1MvUW9FIG1ldHJpYw0KICAgaW5mb3JtYXRpb24gaW4gdGhlIGFwcHJvcHJpYXRl IHJlcG9ydCBibG9jayBmb3JtYXQgKGUuZy4sUlRDUCBYUiBvcg0KICAgb3RoZXIgbm9uLVJUUCBt ZWFucykgdG8gdGhlIG1hbmFnZW1lbnQgc3lzdGVtLiANCiINCg0KQ2hlZXJzDQoNCk1hZ251cw0K DQpPbiAyMDEyLTA1LTMwIDE1OjQ5LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4gV0csIENv bGluIGFuZCBBbGJyZWNodCwNCj4gDQo+IFBsZWFzZSBjaGVjayBpZiB5b3UgdGhpbmsgdGhlIGNo YW5nZXMgaW4gdGhpcyB2ZXJzaW9uIGFyZSBhcHByb3ByaWF0ZS4NCj4gDQo+IENoZWVycw0KPiAN Cj4gTWFnbnVzDQo+IA0KPiBPbiAyMDEyLTA1LTI5IDA0OjI1LCBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgd3JvdGU6DQo+Pg0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5j ZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4NCj4+IFRpdGxlICAgICAgICAgICA6IE1v bml0b3JpbmcgQXJjaGl0ZWN0dXJlIGZvciBSVFANCj4+IEF1dGhvcihzKSAgICAgICA6IFFpbiBX dQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBHZW9mZiBIdW50DQo+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgIFBoaWxpcCBBcmRlbg0KPj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTQudHh0DQo+PiBQYWdlcyAgICAgICAgICAgOiAyNw0KPj4g RGF0ZSAgICAgICAgICAgIDogMjAxMi0wNS0yOA0KPj4NCj4+ICAgIFRoaXMgbWVtbyBwcm9wb3Nl cyBhbiBhcmNoaXRlY3R1cmUgZm9yIGV4dGVuZGluZyBSVFAgQ29udHJvbCBQcm90b2NvbA0KPj4g ICAgKFJUQ1ApIHdpdGggYSBuZXcgUlRDUCBFeHRlbmRlZCBSZXBvcnRzIChYUikgKFJGQzM2MTEp IGJsb2NrIHR5cGUgdG8NCj4+ICAgIHJlcG9ydCBuZXcgbWV0cmljcyByZWdhcmRpbmcgbWVkaWEg dHJhbnNtaXNzaW9uIG9yIHJlY2VwdGlvbiBxdWFsaXR5LA0KPj4gICAgZm9sbG93aW5nIFJUQ1Ag Z3VpZGVsaW5lcyBlc3RhYmxpc2hlZCBpbiBSRkM1OTY4LiAgVGhpcyBtZW1vIHN1Z2dlc3RzDQo+ PiAgICB0aGF0IGEgbmV3IGJsb2NrIHNob3VsZCBjb250YWluIGEgc2luZ2xlIG1ldHJpYyBvciBh IHNtYWxsIG51bWJlciBvZg0KPj4gICAgbWV0cmljcyByZWxldmFudCB0byBhIHNpbmdsZSBwYXJh bWV0ZXIgb2YgaW50ZXJlc3Qgb3IgY29uY2VybiwgcmF0aGVyDQo+PiAgICB0aGFuIGNvbnRhaW5p bmcgYSBudW1iZXIgb2YgbWV0cmljcyB3aGljaCBhdHRlbXB0IHRvIHByb3ZpZGUgZnVsbA0KPj4g ICAgY292ZXJhZ2Ugb2YgYWxsIHRob3NlIHBhcmFtZXRlcnMgb2YgY29uY2VybiB0byBhIHNwZWNp ZmljDQo+PiAgICBhcHBsaWNhdGlvbi4gIEFwcGxpY2F0aW9ucyBtYXkgdGhlbiAibWl4IGFuZCBt YXRjaCIgdG8gY3JlYXRlIGEgc2V0DQo+PiAgICBvZiBibG9ja3Mgd2hpY2ggY292ZXJzIHRoZWly IHNldCBvZiBjb25jZXJucy4gIFdoZXJlIHBvc3NpYmxlLCBhDQo+PiAgICBzcGVjaWZpYyBibG9j ayBzaG91bGQgYmUgZGVzaWduZWQgdG8gYmUgcmUtdXNhYmxlIGFjcm9zcyBtb3JlIHRoYW4NCj4+ ICAgIG9uZSBhcHBsaWNhdGlvbiwgZm9yIGV4YW1wbGUsIGZvciBhbGwgb2Ygdm9pY2UsIHN0cmVh bWluZyBhdWRpbyBhbmQNCj4+ICAgIHZpZGVvLg0KPj4NCj4+DQo+PiBBIFVSTCBmb3IgdGhpcyBJ bnRlcm5ldC1EcmFmdCBpczoNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE0LnR4dA0KPj4NCj4+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pg0KPj4gVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4g YmUgcmV0cmlldmVkIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xNC50eHQNCj4+DQo+PiBUaGUgSUVURiBkYXRhdHJh Y2tlciBwYWdlIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gvDQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+IEludGVybmV0LURy YWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQo+PiBvciBm dHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4NCj4+DQo+IA0KPiAN Cg0KDQotLSANCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTXVsdGltZWRp YSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpG5HL2 Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgw IFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ= From magnus.westerlund@ericsson.com Wed May 30 23:41:31 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9749311E80E5 for ; Wed, 30 May 2012 23:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 rnpvGRes9HC0 for ; Wed, 30 May 2012 23:41:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3770811E8093 for ; Wed, 30 May 2012 23:41:29 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-59-4fc7129843e8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 90.14.11869.89217CF4; Thu, 31 May 2012 08:41:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Thu, 31 May 2012 08:41:28 +0200 Message-ID: <4FC71297.6080800@ericsson.com> Date: Thu, 31 May 2012 08:41:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Qin Wu References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> <4FC62550.7000707@ericsson.com> <4FC62E7D.30402@ericsson.com> <114BEA37E68543458F3F22DFC709324E@china.huawei.com> In-Reply-To: <114BEA37E68543458F3F22DFC709324E@china.huawei.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvre4MoeP+Bov+61m87FnJbvF47gJW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx/OJD1oI1yhXr5jxkaWA8LtbFyMkhIWAi 0TXpADuELSZx4d56ti5GLg4hgVOMEvsXzmeFcJYzSvxY9IkVpIpXQFviyt4+ZhCbRUBVYtmr p4wgNpuAhcTNH41sILaoQLDEiz1XoOoFJU7OfMICYosIyEs0bL4LVM/BwSygKDGpXRIkLCzg IvF+w2tGiF2bGCW6LyxmAklwCjhI7Jv5mxXiOkmJg/+ugV3KLKAnMeVqCyOELS/RvHU22D1C QLc1NHWwTmAUmoVk9SwkLbOQtCxgZF7FKJybmJmTXm6kl1qUmVxcnJ+nV5y6iREYxAe3/Fbd wXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEqfXc0n+/2ki7z8 dzbZs3uenis8ZDhrs+umOXdat+ZF7WFy6WTkbPjIrSm17up1Le/KTx+2u13VSc6flF764MR0 w4On+l/Wi5qUuZbf/tzhK//UTdLLKOaXwFQ2F1brwh7/P38LFrI6/LeXmOTroXZzVbHPRqXt YermHVet1wYcfWSUX9r0SImlOCPRUIu5qDgRAM2Rm5EwAgAA Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 06:41:31 -0000 On 2012-05-31 04:03, Qin Wu wrote: > > [Qin]: I thought the figure 1 has already been incoporated into setion 3 and replaced by the description in the section 3. > Based on your comment, I can propose to have the following figure > > +------------| > ------------------>| |<------------------ > | | Management | | > | | System <----- | > | | | | | > | +------^-----+ | | > | | | | > | | | | > | +---------------+ | | > | | | | | > | | Third Party | | | > | | RTP Monitor | | | > | | | | | > | +---------------+ | | > | | | > +-------|-------+ +Intermediate --+ | +--------|------+ > |RTP Sender | | RTP System | | |RTP Receiver | > | | | |--- | | > | +-----------+ | | +-----------+ | | +-----------+ | > | |RTP Monitor| | RTP | |RTP Monitor| | RTP | |RTP Monitor| | > | +-----------+ | Stream | +-----------+ |Stream | +-----------+ | > | |-------->| |------>| | > | | | | | | > +---------------+ +---------------+ +---------------+ > Is this figure what you are looking for? Mostly. I don't know if we need to have the Management system in the picture. What I was looking for was the lower part. The one thing I think is poorly covered in the above figure is how a third party monitor gets to the information it monitors. To my understanding it exists in two flavors. A passive monitor that sees the RTP/RTCP stream pass it, or a system that gets sent RTCP reports but not RTP and uses that to collect information. > > 2. I also wonder if we shouldn't really remove the word architecture > from this document and instead have the title be "Guidelines for the RTP > Monitoring Framework" > > [Qin]: Are you proposing to replace the word "architecture" with "framework"? No, you will have to be a bit more intelligent in selecting words. But Architecture implies an explanation of how things are supposed to fit to together in total. I don't see this document reaching this bar. That was why I suggested a new title. Based on that title one can remove the use of architecture with calling it description of the frame work like for section 3 and Guidelines for the framework for section 5. What to replace architecture with depends on the context. > > 3. In some sense I wished we could keep the old figure 1 somewhere in > the document. But I guess it would require even more discussion around > the management system. > > [Qin]: Management system may not have RTP functionality. Therefore shouldn't it be > beyond scope of the RTP monitoring architecture? In the current draft, we have briefly > discussed interaction between RTP monitor and management system with the following > description: > " > The RTP monitor also exposes real time Application QoS/QoE metric > information in the appropriate report block format (e.g.,RTCP XR or > other non-RTP means) to the management system. > " In reality I think a RTP monitoring architecture do need to discuss the management side of things. But this document isn't up to the task. It describes the RTP side of the monitoring. That is why I think calling it a framework might be better and not imply that all pieces are present. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Thu May 31 01:40:15 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB43621F8630 for ; Thu, 31 May 2012 01:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.479 X-Spam-Level: X-Spam-Status: No, score=-4.479 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 JaysqiG6MYst for ; Thu, 31 May 2012 01:40:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8A21F8633 for ; Thu, 31 May 2012 01:40:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGS56422; Thu, 31 May 2012 04:40:14 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 31 May 2012 01:35:29 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 31 May 2012 01:35:34 -0700 Received: from w53375 (10.138.41.149) by szxeml419-hub.china.huawei.com (10.82.67.158) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 31 May 2012 16:35:29 +0800 Message-ID: From: Qin Wu To: Magnus Westerlund References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com><4FC62550.7000707@ericsson.com> <4FC62E7D.30402@ericsson.com><114BEA37E68543458F3F22DFC709324E@china.huawei.com> <4FC71297.6080800@ericsson.com> Date: Thu, 31 May 2012 16:35:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 08:40:15 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYWdudXMgV2VzdGVybHVuZCIg PG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NClRvOiAiUWluIFd1IiA8YmlsbC53dUBo dWF3ZWkuY29tPg0KQ2M6IDxhdnRAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgTWF5IDMxLCAy MDEyIDI6NDEgUE0NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1hdnRjb3JlLW1vbmFyY2gtMTQudHh0DQoNCg0KT24gMjAxMi0wNS0zMSAwNDowMywgUWluIFd1 IHdyb3RlOg0KDQo+IA0KPiBbUWluXTogSSB0aG91Z2h0IHRoZSBmaWd1cmUgMSBoYXMgYWxyZWFk eSBiZWVuIGluY29wb3JhdGVkIGludG8gc2V0aW9uIDMgYW5kIHJlcGxhY2VkIGJ5IHRoZSBkZXNj cmlwdGlvbiBpbiB0aGUgc2VjdGlvbiAzLg0KPiBCYXNlZCBvbiB5b3VyIGNvbW1lbnQsIEkgY2Fu IHByb3Bvc2UgdG8gaGF2ZSB0aGUgZm9sbG93aW5nIGZpZ3VyZQ0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS18DQo+ICAgICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tLT58ICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICAgICAgfCAgICAg ICAgICAgICAgICAgIHwgTWFuYWdlbWVudCB8ICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgfCAgIFN5c3RlbSAgIDwtLS0tLSAgICAgICAgICAgICB8DQo+ ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICB8ICAgICAgICAg ICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgICAgICAgICAgICstLS0tLS1eLS0tLS0rICAgIHwg ICAgICAgICAgICAgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgICAgICB8DQo+ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwgICAgICAgICAgICAgfA0KPiAgICAgICAgICB8ICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICB8DQo+ICAgICAgICAg IHwgICAgICAgICAgICAgICAgIHwgVGhpcmQgUGFydHkgICB8ICB8ICAgICAgICAgICAgIHwNCj4g ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCBSVFAgTW9uaXRvciAgIHwgIHwgICAgICAgICAg ICAgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgfCAg ICAgICAgICAgICB8DQo+ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rICB8ICAgICAgICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfA0KPiAgKy0tLS0tLS18LS0tLS0tLSsgICAgICAg ICArSW50ZXJtZWRpYXRlIC0tKyAgfCAgICArLS0tLS0tLS18LS0tLS0tKw0KPiAgfFJUUCBTZW5k ZXIgICAgIHwgICAgICAgICB8IFJUUCBTeXN0ZW0gICAgfCAgfCAgICB8UlRQIFJlY2VpdmVyICAg fA0KPiAgfCAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgfC0tLSAgICB8 ICAgICAgICAgICAgICAgfA0KPiAgfCArLS0tLS0tLS0tLS0rIHwgICAgICAgICB8ICstLS0tLS0t LS0tLSsgfCAgICAgICB8ICstLS0tLS0tLS0tLSsgfA0KPiAgfCB8UlRQIE1vbml0b3J8IHwgIFJU UCAgICB8IHxSVFAgTW9uaXRvcnwgfCBSVFAgICB8IHxSVFAgTW9uaXRvcnwgfA0KPiAgfCArLS0t LS0tLS0tLS0rIHwgU3RyZWFtICB8ICstLS0tLS0tLS0tLSsgfFN0cmVhbSB8ICstLS0tLS0tLS0t LSsgfA0KPiAgfCAgICAgICAgICAgICAgIHwtLS0tLS0tLT58ICAgICAgICAgICAgICAgfC0tLS0t LT58ICAgICAgICAgICAgICAgfA0KPiAgfCAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfA0KPiAgKy0tLS0tLS0tLS0tLS0tLSsg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0KPiBJcyB0 aGlzIGZpZ3VyZSB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3I/DQoNCk1vc3RseS4gSSBkb24ndCBr bm93IGlmIHdlIG5lZWQgdG8gaGF2ZSB0aGUgTWFuYWdlbWVudCBzeXN0ZW0gaW4gdGhlDQpwaWN0 dXJlLiBXaGF0IEkgd2FzIGxvb2tpbmcgZm9yIHdhcyB0aGUgbG93ZXIgcGFydC4gVGhlIG9uZSB0 aGluZyBJDQp0aGluayBpcyBwb29ybHkgY292ZXJlZCBpbiB0aGUgYWJvdmUgZmlndXJlIGlzIGhv dyBhIHRoaXJkIHBhcnR5IG1vbml0b3INCmdldHMgdG8gdGhlIGluZm9ybWF0aW9uIGl0IG1vbml0 b3JzLiBUbyBteSB1bmRlcnN0YW5kaW5nIGl0IGV4aXN0cyBpbg0KdHdvIGZsYXZvcnMuIEEgcGFz c2l2ZSBtb25pdG9yIHRoYXQgc2VlcyB0aGUgUlRQL1JUQ1Agc3RyZWFtIHBhc3MgaXQsIG9yDQph IHN5c3RlbSB0aGF0IGdldHMgc2VudCBSVENQIHJlcG9ydHMgYnV0IG5vdCBSVFAgYW5kIHVzZXMg dGhhdCB0bw0KY29sbGVjdCBpbmZvcm1hdGlvbi4NCg0KW1Fpbl06IFlvdSBhcmUgcmlnaHQsIGFj dHVhbGx5IHRoZXNlIHR3byBmbGF2b3JzIGhhdmUgYmVlbiBkZXNjcmliZWQgaW4gdGhlIGZpZ3Vy IDEgb2YgcHJldmlvdXMgdmVyc2lvbiAtMTMuDQpJIGNhbiBmaXggdGhlIGZpZ3VyZSBJIHByb3Bv c2VkIGFib3ZlIHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2U6DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICB8LS0+fCBUaGlyZCBQYXJ0 eSAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwgUlRQIE1vbml0b3IgICB8DQogICAg ICAgICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg ICAgICAgICB8ICAgKy0tLS0tLS0tLXwtLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgfE1l dHJpYyBSZXBvcnR8DQogICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICBSVFAgU3RyZWFtDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNZXRyaWMNCistLS0tLS0tIC0tLS0tLS0rIE1ldHJpYyAg K0ludGVybWVkaWF0ZSAtLStSZXBvcnQgKy0tLS0tLS0tLS0tLS0tLSsNCnxSVFAgU2VuZGVyICAg ICB8IFJlcG9ydCAgfCBSVFAgU3lzdGVtICAgIHwgICAgICAgfFJUUCBSZWNlaXZlciAgIHwNCnwg Ky0tLS0tLS0tLS0tKyB8ICAgICAgICAgfCArLS0tLS0tLS0tLS0rIHwgICAgICAgfCArLS0tLS0t LS0tLS0rIHwNCnwgfFJUUCBNb25pdG9yfDwtLS0tLS0tLS0tLS18UlRQIE1vbml0b3J8PC0tLS0t LS0tLS18UlRQIE1vbml0b3J8IHwNCnwgKy0tLS0tLS0tLS0tKyB8ICAgICAgICAgfCArLS0tLS0t LS0tLS0rIHwgICAgICAgfCArLS0tLS0tLS0tLS0rIHwNCnwgICAgICAgICAgICAgICB8ICBSVFAg ICAgfCAgICAgICAgICAgICAgIHwgUlRQICAgfCAgICAgICAgICAgICAgIHwNCnwgICAgICAgICAg ICAgICB8IFN0cmVhbSAgfCAgICAgICAgICAgICAgIHxTdHJlYW0gfCAgICAgICAgICAgICAgIHwN CnwgICAgICAgICAgICAgICB8LS0tLS0tLS0+fCAgICAgICAgICAgICAgIHwtLS0tLS0+fCAgICAg ICAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tLS0rICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCg0KPiANCj4gMi4gSSBhbHNvIHdvbmRlciBpZiB3ZSBz aG91bGRuJ3QgcmVhbGx5IHJlbW92ZSB0aGUgd29yZCBhcmNoaXRlY3R1cmUNCj4gZnJvbSB0aGlz IGRvY3VtZW50IGFuZCBpbnN0ZWFkIGhhdmUgdGhlIHRpdGxlIGJlICJHdWlkZWxpbmVzIGZvciB0 aGUgUlRQDQo+IE1vbml0b3JpbmcgRnJhbWV3b3JrIg0KPiANCj4gW1Fpbl06IEFyZSB5b3UgcHJv cG9zaW5nIHRvIHJlcGxhY2UgdGhlIHdvcmQgImFyY2hpdGVjdHVyZSIgd2l0aCAiZnJhbWV3b3Jr Ij8NCg0KTm8sIHlvdSB3aWxsIGhhdmUgdG8gYmUgYSBiaXQgbW9yZSBpbnRlbGxpZ2VudCBpbiBz ZWxlY3Rpbmcgd29yZHMuIEJ1dA0KQXJjaGl0ZWN0dXJlIGltcGxpZXMgYW4gZXhwbGFuYXRpb24g b2YgaG93IHRoaW5ncyBhcmUgc3VwcG9zZWQgdG8gZml0IHRvDQp0b2dldGhlciBpbiB0b3RhbC4g SSBkb24ndCBzZWUgdGhpcyBkb2N1bWVudCByZWFjaGluZyB0aGlzIGJhci4gVGhhdCB3YXMNCndo eSBJIHN1Z2dlc3RlZCBhIG5ldyB0aXRsZS4gQmFzZWQgb24gdGhhdCB0aXRsZSBvbmUgY2FuIHJl bW92ZSB0aGUgdXNlDQpvZiBhcmNoaXRlY3R1cmUgd2l0aCBjYWxsaW5nIGl0IGRlc2NyaXB0aW9u IG9mIHRoZSBmcmFtZSB3b3JrIGxpa2UgZm9yDQpzZWN0aW9uIDMgYW5kIEd1aWRlbGluZXMgZm9y IHRoZSBmcmFtZXdvcmsgZm9yIHNlY3Rpb24gNS4gV2hhdCB0bw0KcmVwbGFjZSBhcmNoaXRlY3R1 cmUgd2l0aCBkZXBlbmRzIG9uIHRoZSBjb250ZXh0Lg0KDQpbUWluXTogQWdyZWUuDQoNCj4gDQo+ IDMuIEluIHNvbWUgc2Vuc2UgSSB3aXNoZWQgd2UgY291bGQga2VlcCB0aGUgb2xkIGZpZ3VyZSAx IHNvbWV3aGVyZSBpbg0KPiB0aGUgZG9jdW1lbnQuIEJ1dCBJIGd1ZXNzIGl0IHdvdWxkIHJlcXVp cmUgZXZlbiBtb3JlIGRpc2N1c3Npb24gYXJvdW5kDQo+IHRoZSBtYW5hZ2VtZW50IHN5c3RlbS4N Cj4gDQo+IFtRaW5dOiBNYW5hZ2VtZW50IHN5c3RlbSBtYXkgbm90IGhhdmUgUlRQIGZ1bmN0aW9u YWxpdHkuIFRoZXJlZm9yZSBzaG91bGRuJ3QgaXQgYmUNCj4gYmV5b25kIHNjb3BlIG9mIHRoZSBS VFAgbW9uaXRvcmluZyBhcmNoaXRlY3R1cmU/IEluIHRoZSBjdXJyZW50IGRyYWZ0LCB3ZSBoYXZl IGJyaWVmbHkgDQo+IGRpc2N1c3NlZCBpbnRlcmFjdGlvbiBiZXR3ZWVuIFJUUCBtb25pdG9yIGFu ZCBtYW5hZ2VtZW50IHN5c3RlbSB3aXRoIHRoZSBmb2xsb3dpbmcNCj4gZGVzY3JpcHRpb246DQo+ ICINCj4gVGhlIFJUUCBtb25pdG9yIGFsc28gZXhwb3NlcyByZWFsIHRpbWUgQXBwbGljYXRpb24g UW9TL1FvRSBtZXRyaWMNCj4gICAgaW5mb3JtYXRpb24gaW4gdGhlIGFwcHJvcHJpYXRlIHJlcG9y dCBibG9jayBmb3JtYXQgKGUuZy4sUlRDUCBYUiBvcg0KPiAgICBvdGhlciBub24tUlRQIG1lYW5z KSB0byB0aGUgbWFuYWdlbWVudCBzeXN0ZW0uIA0KPiAiDQoNCkluIHJlYWxpdHkgSSB0aGluayBh IFJUUCBtb25pdG9yaW5nIGFyY2hpdGVjdHVyZSBkbyBuZWVkIHRvIGRpc2N1c3MgdGhlDQptYW5h Z2VtZW50IHNpZGUgb2YgdGhpbmdzLiBCdXQgdGhpcyBkb2N1bWVudCBpc24ndCB1cCB0byB0aGUg dGFzay4gSXQNCmRlc2NyaWJlcyB0aGUgUlRQIHNpZGUgb2YgdGhlIG1vbml0b3JpbmcuIFRoYXQg aXMgd2h5IEkgdGhpbmsgY2FsbGluZyBpdA0KYSBmcmFtZXdvcmsgbWlnaHQgYmUgYmV0dGVyIGFu ZCBub3QgaW1wbHkgdGhhdCBhbGwgcGllY2VzIGFyZSBwcmVzZW50Lg0KDQpbUWluXTogSSBzZWUu