From woohwankim@gmail.com Tue Jun 4 00:32:23 2013 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 E39E421E8136 for ; Tue, 4 Jun 2013 00:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh5QDyzg3zg1 for ; Tue, 4 Jun 2013 00:32:13 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7B421F9BB4 for ; Mon, 3 Jun 2013 23:35:02 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so1638776wev.22 for ; Mon, 03 Jun 2013 23:35:01 -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=iSKPKOOwVOCAlx3mYOLzG+4zYYv1RGWR9I5BV+RgT9U=; b=AwLc0UhrtjIvN1plt99qD6o0YQCi93dJLVOdtBQn5gYlSKyCrk1Oa6vjoh/8j84kcg p4nmcqujfJXZvYVBrecquqU8IwiTUOo3EOOGsXSvy8f/PU15Mo/0oC/VU7x+m5n0mf/x 4Ti2xy3bKUYWMY5DlOPyAP9MJN5Hx+XaHVmCvbbXC25BVt2ny3EnFV+pjavUwT+1gGLm sDEnypWrnbmn2NYEXK7+4TQVAcdsAisVdyynWXSlzOvto50KOfK+hx/jbMhxNXvBywgS gSBYxvi7VBD5ffXZ67kek4SYn05Vp7ywtOS0DkXI+SvzKzjDC+GhOcQbGnElAvKeKk/y QKpQ== MIME-Version: 1.0 X-Received: by 10.180.14.130 with SMTP id p2mr565087wic.32.1370327701713; Mon, 03 Jun 2013 23:35:01 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.216.192.133 with HTTP; Mon, 3 Jun 2013 23:35:01 -0700 (PDT) Date: Tue, 4 Jun 2013 15:35:01 +0900 X-Google-Sender-Auth: EawDv0bh_3-oQVD8O6oVsgO8GHU Message-ID: From: Woo-Hwan Kim To: Magnus Westerlund , avt@ietf.org Content-Type: multipart/alternative; boundary=f46d040f9f44e2f6c304de4e471a Cc: draft-ietf-avtcore-aria-srtp@tools.ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01 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, 04 Jun 2013 07:32:24 -0000 --f46d040f9f44e2f6c304de4e471a Content-Type: text/plain; charset=ISO-8859-1 First of all, we appreciate your helpful comment on the draft. >>2) Section 2.1 and 4: >> >>What are the security implications of using a 256 bit key length for the >>crypto but have as weak integrity protection as SAH1 32 bits? I think >>you need to discuss the implications of this, it doesn't appear to be >>particular balanced. We think that the key length and tag length should be treated separately. Though the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good, the statement of Section 7.5 in RFC 3711 still seems to be valid for 192/256 bit key block cipher. >From another point of view, even when the tag length is short, large key length provides more security against key recovery attacks. So we would like to define ARIA ciphersuites corresponding to AES ciphersuites such as AES_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose a proper ciphersuite depending on environments. >>3) Section 2.2: >> >> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >> of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM >> with SRTP is defined the same as that of AES-CCM and AES-GCM. >> >>Looking in AES-GCM it appears to define a generic AEAD procedures for >>SRTP cipher suits. Can you please be more explicit and clear on how you >>use that generic procedure? >> >> >>4) Section 2.1, 2.2: >> >>These procedures are define by reference to existing algorithms like >>these sentences: >> >> ARIA counter modes are >> defined in a similar manner, and are denoted by ARIA_128_CTR, >> ARIA_192_CTR and ARIA_256_CTR respectively, according to the key >> lengths. The plaintext inputs to the block cipher are formed as in >> AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs >> are processed as in AES-CTR. >> >> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >> of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM >> with SRTP is defined the same as that of AES-CCM and AES-GCM. >> >>I think using words as "similar" and not being very explicit about what >>procedures from the other specification that applies here provide some >>risk for misunderstanding. I hope you can be more explicit and clear on >>which procedures and usage are applicable. The only difference between ARIA ciphersuites and AES ciphersuites is whether to invoke ARIA or AES. There is no difference in modes of operation itself. Thus we think it is not necessary to define AEAD procedures and other modes of operations more explicitly in the draft if there are proper references. If the word "similar" is inappropriate, we'll replace it by the word "same". The below sentences can be added. - ARIA counter modes are defined in the same manner except that each invocation of AES is replaced by that of ARIA. - The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as that of AES-CCM and AES-GCM except that each invocation of AES is replaced by ARIA. We are following the AES-SRTP documents including draft-ietf-avtcore-srtp-aes-gcm. Section 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is used for CCM and it is written that the tag size for GCM is determined by the algorithm choice. But the tag size for CCM also can be determined by the algorithm choice and it is better to define CCM ciphersuites for each tag size. We submitted such opinion, but not accepted yet. For other comments ((1), (5) ~ 10)), I'll revise the old draft to reflect your comment. We'll update the draft soon. Sincerely, Woo-Hwan Kim --f46d040f9f44e2f6c304de4e471a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
First of all, we appreciate your helpful comment on t= he draft.

>>2) Section 2.1 and 4:
= >>
>>What are the security implications of using a 25= 6 bit key length for the
>>crypto but have as weak integrity protection as SAH1 32 bits? = I think
>>you need to discuss the implications of this, it = doesn't appear to be
>>particular balanced.

We think that the key length and tag length should be treate= d separately.
Though the security balance of ARIA-192/256 and HMA= C-SHA1_32 is not good,=A0
the statement of Section 7.5 in RFC 371= 1 still seems to be valid for 192/256
bit key block cipher.
From another point of view, even when = the tag length is short,
large key length provides more security = against key recovery attacks.
So we would like to define ARIA cip= hersuites corresponding to AES ciphersuites
such as AES_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choo= se a=A0
proper ciphersuite depending on environments.
<= br>
>>3) Section 2.2:
>>
>>= The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>> =A0 of AES-GCM and AES-CCM with SRTP. =A0The use of ARIA-CCM = and ARIA-GCM
>> =A0 with SRTP is defined the same as that o= f AES-CCM and AES-GCM.
>>
>>Looking in AES-= GCM it appears to define a generic AEAD procedures for
>>SRTP cipher suits. Can you please be more explicit and clear o= n how you
>>use that generic procedure?
>><= /div>
>>
>>4) Section 2.1, 2.2:
>>= ;
>>These procedures are define by reference to existing algorithm= s like
>>these sentences:
>>
>= > =A0 =A0ARIA counter modes are
>> =A0 defined in a simi= lar manner, and are denoted by ARIA_128_CTR,
>> =A0 ARIA_192_CTR and ARIA_256_CTR respectively, according to = the key
>> =A0 lengths. =A0The plaintext inputs to the bloc= k cipher are formed as in
>> =A0 AES-CTR(AES_CM, AES_192_CM= , AES_256_CM) and the block cipher outputs
>> =A0 are processed as in AES-CTR.
>>
>> =A0 The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes t= he use
>> =A0 of AES-GCM and AES-CCM with SRTP. =A0The use = of ARIA-CCM and ARIA-GCM
>> =A0 with SRTP is defined the same as that of AES-CCM and AES-= GCM.
>>
>>I think using words as "simi= lar" and not being very explicit about what
>>procedur= es from the other specification that applies here provide some
>>risk for misunderstanding. I hope you can be more explicit and= clear on
>>which procedures and usage are applicable.

The only difference between ARIA ciphersuites and AES = ciphersuites is=A0
whether to invoke ARIA or AES. There is no difference in modes of oper= ation itself.=A0
Thus we think it is not necessary to define AEAD= procedures and other modes of=A0
operations more explicitly in t= he draft if there are proper references.

If the word "similar" is inappropriate, we= 9;ll replace it by the word "same".=A0
The below senten= ces can be added.

- ARIA counter modes are defined= in the same manner except that each invocation of=A0
AES is replaced by that of ARIA.
- The use of ARIA-CCM and A= RIA-GCM with SRTP is defined the same as=A0
that of AES-CCM and A= ES-GCM except that each invocation of AES is replaced
by ARIA.

We are following the AES-SRTP documents including draft= -ietf-avtcore-srtp-aes-gcm.
Section 5.2 in the draft-ietf-avtcore= -srtp-aes-gcm, Tag_Size_Flag is used for CCM and
it is written th= at the tag size for GCM is determined by the algorithm choice.
But the tag size for CCM also can be determined by the algorithm choic= e and=A0
it is better to define CCM ciphersuites for each tag siz= e. We submitted such opinion,
but not accepted yet.

For other comments ((1), (5) ~ 10)), I'll revise th= e old draft to reflect your comment.
We'll update the draft s= oon.

Sincerely,
Woo-Hwan Kim=
--f46d040f9f44e2f6c304de4e471a-- From internet-drafts@ietf.org Wed Jun 5 08:55:38 2013 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 5D73B21F9007; Wed, 5 Jun 2013 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em+1h8SPGNoH; Wed, 5 Jun 2013 08:55:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1941D21F901F; Wed, 5 Jun 2013 08:55:31 -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.50 Message-ID: <20130605155530.11546.70082.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 08:55:30 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-02.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, 05 Jun 2013 15:55:38 -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 Maintenance Wo= rking 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-02.txt Pages : 32 Date : 2013-06-05 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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-aria-srtp-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=5870ac8b49=magnus.westerlund@ericsson.com Fri Jun 7 07:20:35 2013 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 02BF621F961B for ; Fri, 7 Jun 2013 07:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 kePhAblbSEkl for ; Fri, 7 Jun 2013 07:20:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C94E221F9638 for ; Fri, 7 Jun 2013 07:20:13 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-53-51b1ec1b88b2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6E.52.09795.B1CE1B15; Fri, 7 Jun 2013 16:20:12 +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.279.1; Fri, 7 Jun 2013 16:20:11 +0200 Message-ID: <51B1EC1F.6050200@ericsson.com> Date: Fri, 7 Jun 2013 16:20:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Woo-Hwan Kim References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvra7Mm42BBofXc1m87FnJbjF5soDF lt3nWByYPdb0JXssWfKTyePL5c9sAcxR3DZJiSVlwZnpefp2CdwZrRM/shd8U6349/oWewPj OrkuRk4OCQETic3LV7FD2GISF+6tZ+ti5OIQEjjFKPHw/hewhJDAMkaJe/PrQGxeAW2JxbOW MHUxcnCwCKhIfN1pChJmE7CQuPmjkQ3EFhUIljiyfTMLRLmgxMmZT8BsEQFViSdzGsFGMgvY Ssy+uJoZxBYWcJK43n6bEWSkkECAxJI2Z5Awp0CgxJc3v6BOk5TY8qIdqlVPYsrVFkYIW16i eetsZogrtSUamjpYJzAKzUKyeRaSlllIWhYwMq9iZM9NzMxJLzffxAgM3INbfhvsYNx0X+wQ ozQHi5I4rz7v4kAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBcfHVxzvNRMJ1Lx7Z8CmJ 0c9xyqXwA3Eqt64llYiK3D7ocjXdXd72zcawNpMVt2a3/k3dM2m777b5vdmMV2wPnZjzIysl OSH3b6pjbor/kajNa18av3JuC9P+F+9v8IB/Vs6mtexcaZtDtr+0P1t6Iuo4+/fJ3WcZstVv m622cnBnjP+xUCjgrRJLcUaioRZzUXEiAO+V6fYvAgAA Cc: draft-ietf-avtcore-aria-srtp@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01 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, 07 Jun 2013 14:20:35 -0000 Hi, Please see my replies inline. On 2013-06-04 08:35, Woo-Hwan Kim wrote: > First of all, we appreciate your helpful comment on the draft. > >>>2) Section 2.1 and 4: >>> >>>What are the security implications of using a 256 bit key length for the >>>crypto but have as weak integrity protection as SAH1 32 bits? I think >>>you need to discuss the implications of this, it doesn't appear to be >>>particular balanced. > > We think that the key length and tag length should be treated separately. > Though the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good, > the statement of Section 7.5 in RFC 3711 still seems to be valid for 192/256 > bit key block cipher. > From another point of view, even when the tag length is short, > large key length provides more security against key recovery attacks. > So we would like to define ARIA ciphersuites corresponding to AES > ciphersuites > such as AES_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose a > proper ciphersuite depending on environments. Okay, I don't see any significant issue with that, but please be explicit in the considerations that this combination is quite loop sided from a security perspective. > >>>3) Section 2.2: >>> >>> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >>> of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM >>> with SRTP is defined the same as that of AES-CCM and AES-GCM. >>> >>>Looking in AES-GCM it appears to define a generic AEAD procedures for >>>SRTP cipher suits. Can you please be more explicit and clear on how you >>>use that generic procedure? >>> >>> >>>4) Section 2.1, 2.2: >>> >>>These procedures are define by reference to existing algorithms like >>>these sentences: >>> >>> ARIA counter modes are >>> defined in a similar manner, and are denoted by ARIA_128_CTR, >>> ARIA_192_CTR and ARIA_256_CTR respectively, according to the key >>> lengths. The plaintext inputs to the block cipher are formed as in >>> AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs >>> are processed as in AES-CTR. >>> >>> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >>> of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM >>> with SRTP is defined the same as that of AES-CCM and AES-GCM. >>> >>>I think using words as "similar" and not being very explicit about what >>>procedures from the other specification that applies here provide some >>>risk for misunderstanding. I hope you can be more explicit and clear on >>>which procedures and usage are applicable. > > The only difference between ARIA ciphersuites and AES ciphersuites is > whether to invoke ARIA or AES. There is no difference in modes of > operation itself. > Thus we think it is not necessary to define AEAD procedures and other > modes of > operations more explicitly in the draft if there are proper references. > > If the word "similar" is inappropriate, we'll replace it by the word > "same". > The below sentences can be added. > > - ARIA counter modes are defined in the same manner except that each > invocation of > AES is replaced by that of ARIA. > - The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as > that of AES-CCM and AES-GCM except that each invocation of AES is replaced > by ARIA. Correct, I agree with reference procedures when they exist. But you need to be explicit about this. Same is better, but I haven't judged if that makes it obvious how you apply ARIA instead of AES. > > We are following the AES-SRTP documents including > draft-ietf-avtcore-srtp-aes-gcm. > Section 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is > used for CCM and > it is written that the tag size for GCM is determined by the algorithm > choice. > But the tag size for CCM also can be determined by the algorithm choice and > it is better to define CCM ciphersuites for each tag size. We submitted > such opinion, > but not accepted yet. Okay, if that discussion is from the AES-GCM last call, I think you need to re-raise this on the list as a focused email on that issue. I don't seem to be able to find any reply to those comments. So please remind the authors about this issue and lets see if we can come to a conclusion on it. 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 ray.vanbrandenburg@tno.nl Mon Jun 10 04:50:03 2013 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 4609321F8F15 for ; Mon, 10 Jun 2013 04:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 JpG9wl86jMW2 for ; Mon, 10 Jun 2013 04:49:56 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4143121F8EAE for ; Mon, 10 Jun 2013 04:49:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,836,1363129200"; d="scan'208";a="1606849" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 10 Jun 2013 13:49:47 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 13:49:47 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUA== Date: Mon, 10 Jun 2013 11:49:46 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVTCORE] FW: Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 11:50:03 -0000 Hi WG,=20 Below you will find the Gen-ART review of the IDMS draft, including my resp= onse to it. Since some of the comments in the review have to do with the relationship w= ith the ETSI spec, a topic which we have discussed in the WG earlier, I'm c= opying the WG here.=20 Best regards, Ray -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: maandag 10 juni 2013 12:22 To: Brandenburg, R. (Ray) van; General Area Review Team Cc: draft-ietf-avtcore-idms.all@tools.ietf.org; Roni Even (ron.even.tlv@gma= il.com) Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 Hi Ray, Thank you for the detailed answer.=20 See in-line.=20 Regards, Dan > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 11:33 AM > To: Romascanu, Dan (Dan); General Area Review Team > Cc: draft-ietf-avtcore-idms.all@tools.ietf.org; Roni Even > (ron.even.tlv@gmail.com) > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 > Hi Dan, >=20 > Many thanks for your very thorough review. >=20 > Before responding to your comments in detail, let me give you some=20 > background on how we handle the relationship with the ETSI document: > Exactly how we should deal with the existing ETSI spec has been=20 > discussed at length in AVTCORE, both on- and offlist. As you can see=20 > in the earlier versions of the draft, the document used to extend the=20 > ETSI document, referencing it where necessary and including sections=20 > that describe this relationship. In the end, the WG consensus was that=20 > the IETF draft should be the normative spec for the XR block and=20 > AVTCORE should have full change control over it. We therefore removed=20 > most references to the ETSI spec, and instead started a Work Item in=20 > ETSI to change TS 183 063 to point to the IETF draft and remove all=20 > normative statements (apart from extending the IETF-defined block with=20 > three new SPST values). >=20 [[DR]] Thank you for the clarification information. This is very useful. Ca= n you tell what is the status of the work item in ETSI?=20 > The current idea is therefore that since the ETSI spec will be=20 > referencing the IETF spec, instead of the other way around, that there=20 > is no need to describe this relationship in the IETF draft. The IETF=20 > spec is the normative 'base' spec, and ETSI is just describing a way=20 > to use it within an IPTV system, including three additional SPST=20 > values specific to that scenario. [[DR]] I disagree that there is no need to describe this relationship on th= e IETF draft. As control for the XR block was previously in ETSI and will n= ow be transferred to the IETF we should assume that there are implementers = and deployments who know about the older ETSI specification. You need a sec= tions that describes the relationship with the ETSI document, and describes= the changes relative to that version - same as would have been written if = there was an RFC that was updated or made obsolete by this document.=20 Moreover, the current document is not consistent, as it still keeps a norma= tive reference to the older (not even the latest version) ETSI document. Th= is will be not needed any longer, an informational reference would be suffi= cient. =20 >=20 > Personally, I agree with the WG consensus that this is the 'cleanest' > way to handle it, resulting in backwards compatibility with older=20 > versions of the ETSI document as well as have full change control in=20 > IETF. >=20 > Please see inline for your comments. >=20 > Best regards, >=20 > Ray >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: zondag 9 juni 2013 9:53 > To: General Area Review Team > Cc: draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 > (resending, I mis-spelled .all address at the first try) >=20 > I am the assigned Gen-ART reviewer for this draft. For background on=20 > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments=20 > you may receive. >=20 > Document: draft-ietf-avtcore-idms-09 > Reviewer: Dan Romascanu > Review Date: 6/6/13 > IETF LC End Date: 6/11/13 > IESG Telechat date: >=20 > Summary: >=20 > Not Ready >=20 > Major issues: >=20 > 1. This document is tightly connected with the ETSI specification TS=20 > 183 063. However this relation is mentioned only in a couple of places=20 > and does not describe the complexity of the relation. Moreover, the=20 > relation itself seems problematic. >=20 > The I-D uses some of the inter-destination media techniques described=20 > by ETSI TS 183 063. For example Section 7 replicates part of the=20 > content of Annex W of the ETSI document. It does it partially however,=20 > and with some modifications, as only the content definition and=20 > behavior of the transmitters and receivers for SPST=3D1 were taken from=20 > Annex W, while the content and behavior for SPST=3D2-4 are marked as=20 > 'defined by ETSI TISPAN'. The ETSI document details what happens with=20 > the fields when SPST=3D2-4. This will result in the RTCP XR block for=20 > IDMS to be defined in two places - part in this IETF document (if=20 > approved), the rest in the ETSI document (to be modified accordingly=20 > in the future). For some period of time the same fields will be=20 > defined in two places. This seems broken. >=20 > [Ray: See my comments above. The ETSI document will be changed to=20 > point to the IETF spec. Does this solve your issue? In addition, we=20 > could create an IANA registry for SPST values, although I personally=20 > believe this to not be necessary] >=20 [[DR]] Eventually it will solve the issue, but the situation is murky in th= e interim. I believe that creating a registry would be good, because it pro= vides a way to describe the interim situation, and also because we do not k= now yet for sure who may use the values 5-15 in the future.=20 > 2. The note to the RFC Editor in section 14.2 states: >=20 > 14.2. RTCP XR IDMS Report Block >=20 > This document assigns the block type value 12 in the IANA "RTCP XR > Block Type Registry" to the RTCP XR IDMS Report Block. >=20 > [Note to RFC Editor: this block type value is currently assigned to > [TS183063]. This document replaces [TS183063] as the normative > specification of the RTCP XR IDMS Report Block. Upon publication of > this document as RFC, [TS183063] will be changed to reflect this. >=20 > The first statement is not accurate. Value 12 is not a new assignment, > 12 was already assigned by ETSI, this document asks to change the=20 > assignment of value 12 from the RTCP XR Block Type for reporting IDMS=20 > information to the IETF defined RTCP XR IDMS Report Block. >=20 > [Ray: Hmm, I'm not sure. I checked with IANA and they don't see a=20 > problem in the current wording. I think this is fundamentally a=20 > question of describing the 'soll' situation versus describing the=20 > process of getting from 'ist' to 'soll'. Once the ETSI doc has been=20 > updated, your proposed sentence would no longer be necessary, right?] >=20 [[DR]] The phrase 'This document assigns ... ' is typically used for new as= signments, and may be misleading, especially in the interim. Describing exp= licitly the transfer of control is better IMO.=20 > This change is however partial as described previously, as the content=20 > of the fields and behavior for SPST =3D 2-4 remain under ETSI control. > Moreover, it is not clear who has further control for other new=20 > values, as SPST =3D 5-15 show as 'reserved for future use in both=20 > documents'. The IANA section does not define or refer an IANA registry=20 > and the policy for adding and approving new values for SPST. >=20 > This solution is not clean. Only one organization should have control=20 > upon the definition of one single RTCP XR block type. Either the IETF=20 > should make the overleaping parts of the document Informational and=20 > reflect the content of the ETSI document, or should take control over=20 > the whole block. >=20 > [Ray: See my earlier comments: IETF will have full control, ETSI will=20 > just be extending it.] >=20 [[DR]] a registry is better, it also avoids the need to make changes to thi= s document if new extensions are being defined by ETSI or other organizatio= ns.=20 > 3. The relation with the ETSI specification TS 183 063 should have=20 > been described clearly from the beginning of the document. >=20 > [Ray: See my earlier comment. Since the IETF draft will be that=20 > normative spec that ETSI will be referencing, I believe this=20 > relationship should be described in ETSI, not in IETF]. >=20 [[DR]] This is where we disagree. If there was no history of control, no pr= evious ETSI specification you would be right, but this is not the case.=20 > Minor issues: >=20 > 1. The version of the block definition is set to V=3D2 which is the same= =20 > as in the ETSI specification. Were versions 0 and 1 already used by=20 > ETSI? If this is the case a note should be made. >=20 > [Ray: This part of the header is defined by RFC3611, and is specified=20 > to be set to 2 to refer to the version of RTP] >=20 [[DR]] OK > 2. In Section 7: >=20 > Reserved bits (Resrv): 3 bits. These bits are reserved for future > definition. In the absence of such a definition, the bits in this > field MUST be set to zero and MUST be ignored by the receiver. >=20 > s/MUST be set to zero/MUST be set to zero at transmission/ >=20 > [Ray: Thanks, I will update the draft] >=20 > 3. In Section 7: >=20 > Reserved bits (Resrv): 25 bits. These bits are reserved for future > use and SHALL be set to 0. >=20 > s/ SHALL be set to 0/ MUST be set to zero at transmission and MUST be=20 > ignored by the receiver/ >=20 > [Ray: Thanks, I will update the draft] >=20 > 4. In Section 7: >=20 > When > reporting on an RTP packet which is one of several consecutive RTP > packets having equal timestamps, an SC SHOULD report on the RTP > packet it received with the lowest sequence number. >=20 > Why a SHOULD here and not a MUST? If there are any cases of exception=20 > they need to be detailed. >=20 > [Ray: Implementations might be optimized for specific scenarios by=20 > reporting on specific packets as indicated by e.g. an out-of-band=20 > signal] >=20 [[DR]] It would be good to clarify this in the text.=20 > 5. In Section 8: >=20 > Because RTP > timestamps do wrap around, the sender of this packet SHOULD use > recent values, i.e. choose NTP timestamps that reflect current time > and not too far in the future or in the past. >=20 > Why a SHOULD here and not a MUST? If there are any cases of exception=20 > they need to be detailed. >=20 > [Ray: I will check with my co-authors] >=20 > 6. In Section 8: >=20 > This SHOULD relate to the first > arriving RTP packet containing this particular RTP timestamp, in case > multiple RTP packets contain the same RTP timestamp. >=20 > Why a SHOULD here and not a MUST? If there are any cases of exception=20 > they need to be detailed. >=20 > [Ray: I will check with my co-authors] >=20 > 7. In Section 8: >=20 > The timestamp is formatted based on the NTP > timestamp format as specified in [RFC5905]. If this field is empty, > then it SHALL be set to 0. This field MAY be left empty if none or > only one of the receivers reported on presentation timestamps. >=20 > Why a MAY here? Especially for the case when none of the receivers=20 > reported, what content can be set there but 0 ? >=20 > [Ray: I believe it should be up to the implementation to decide how it=20 > wants to handle the case of there being only one receiver who reported=20 > on presentation timestamps]. >=20 [[DR]] OK, so the cases when none of the receivers reported and one receive= r only reported should be dealt with differently. This needs to be clarifie= d.=20 > 8: The reference: >=20 > [TS183063] > "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1", > June 2010. >=20 > V3.4.1 is not the latest release. Is this intentional? I found at=20 > least one more recent release dated 2011 and numbered 3.5.2 - I do not=20 > know if there is any diff in the relevant content, but pointing to the=20 > most updated review seems appropriate. >=20 > [Ray: Thanks for noticing, I will update the reference to the latest=20 > ETSI release]. >=20 > 9: Did this document undergo an SDP directorate review? If not I=20 > believe that one would be necessary, as a new SDP Attribute is being defi= ned. >=20 > [Ray: Yes, an SDP directorate review has been carried out]. >=20 > Nits/editorial comments: >=20 > 1. typo in the last paragraph of section 5 - s/nessecary/necessary/ >=20 > 2. in section 8 expand PT as Packet Type >=20 > 3. typo in the first paragraph of section 11 - s/mutli/multi/ >=20 > [Ray: Thanks, I will update the draft] >=20 > Regards, >=20 > Dan >=20 > [Ray: Again, many thanks for the thorough review!] >=20 >=20 >=20 > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/emaildisclaimer From ray.vanbrandenburg@tno.nl Mon Jun 10 05:46:36 2013 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 2055C21F84B1; Mon, 10 Jun 2013 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 wCbHefeuyeDW; Mon, 10 Jun 2013 05:46:29 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 223A821F843F; Mon, 10 Jun 2013 05:38:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,836,1363129200"; d="scan'208";a="9657969" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 10 Jun 2013 14:27:32 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 14:27:32 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBw Date: Mon, 10 Jun 2013 12:27:31 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> 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.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 12:46:36 -0000 Hi Dan, (I've cc'ed the AVTCORE list on Magnus' request) Please see my comments inline (I've shortened the message exchange somewhat= to only include the points of discussion). = Best regards, Ray > Before responding to your comments in detail, let me give you some = > background on how we handle the relationship with the ETSI document: > Exactly how we should deal with the existing ETSI spec has been = > discussed at length in AVTCORE, both on- and offlist. As you can see = > in the earlier versions of the draft, the document used to extend the = > ETSI document, referencing it where necessary and including sections = > that describe this relationship. In the end, the WG consensus was that = > the IETF draft should be the normative spec for the XR block and = > AVTCORE should have full change control over it. We therefore removed = > most references to the ETSI spec, and instead started a Work Item in = > ETSI to change TS 183 063 to point to the IETF draft and remove all = > normative statements (apart from extending the IETF-defined block with = > three new SPST values). > = [[DR]] Thank you for the clarification information. This is very useful. Ca= n you tell what is the status of the work item in ETSI? = [Ray] The current status is that the Work Item has been opened and the cont= ributions have been written and discussed. ETSI has postponed formally acce= pting the contributions until the IETF document is given an RFC number so t= hat they can reference it. = > The current idea is therefore that since the ETSI spec will be = > referencing the IETF spec, instead of the other way around, that there = > is no need to describe this relationship in the IETF draft. The IETF = > spec is the normative 'base' spec, and ETSI is just describing a way = > to use it within an IPTV system, including three additional SPST = > values specific to that scenario. [[DR]] I disagree that there is no need to describe this relationship on th= e IETF draft. As control for the XR block was previously in ETSI and will n= ow be transferred to the IETF we should assume that there are implementers = and deployments who know about the older ETSI specification. You need a sec= tions that describes the relationship with the ETSI document, and describes= the changes relative to that version - same as would have been written if = there was an RFC that was updated or made obsolete by this document. = Moreover, the current document is not consistent, as it still keeps a norma= tive reference to the older (not even the latest version) ETSI document. Th= is will be not needed any longer, an informational reference would be suffi= cient. = [Ray] I agree completely. This seems to be a relic and I will update the re= ference to make it informational. = > 1. This document is tightly connected with the ETSI specification TS > 183 063. However this relation is mentioned only in a couple of places = > and does not describe the complexity of the relation. Moreover, the = > relation itself seems problematic. > = > The I-D uses some of the inter-destination media techniques described = > by ETSI TS 183 063. For example Section 7 replicates part of the = > content of Annex W of the ETSI document. It does it partially however, = > and with some modifications, as only the content definition and = > behavior of the transmitters and receivers for SPST=3D1 were taken from = > Annex W, while the content and behavior for SPST=3D2-4 are marked as = > 'defined by ETSI TISPAN'. The ETSI document details what happens with = > the fields when SPST=3D2-4. This will result in the RTCP XR block for = > IDMS to be defined in two places - part in this IETF document (if = > approved), the rest in the ETSI document (to be modified accordingly = > in the future). For some period of time the same fields will be = > defined in two places. This seems broken. > = > [Ray: See my comments above. The ETSI document will be changed to = > point to the IETF spec. Does this solve your issue? In addition, we = > could create an IANA registry for SPST values, although I personally = > believe this to not be necessary] > = [[DR]] Eventually it will solve the issue, but the situation is murky in th= e interim. I believe that creating a registry would be good, because it pro= vides a way to describe the interim situation, and also because we do not k= now yet for sure who may use the values 5-15 in the future. = [Ray] As Roni mentioned, it is a chicken-egg problem. If there is consensus= in the WG to create a registry, I am happy to include one in the draft. = > 2. The note to the RFC Editor in section 14.2 states: > = > 14.2. RTCP XR IDMS Report Block > = > This document assigns the block type value 12 in the IANA "RTCP XR > Block Type Registry" to the RTCP XR IDMS Report Block. > = > [Note to RFC Editor: this block type value is currently assigned to > [TS183063]. This document replaces [TS183063] as the normative > specification of the RTCP XR IDMS Report Block. Upon publication of > this document as RFC, [TS183063] will be changed to reflect this. > = > The first statement is not accurate. Value 12 is not a new assignment, > 12 was already assigned by ETSI, this document asks to change the = > assignment of value 12 from the RTCP XR Block Type for reporting IDMS = > information to the IETF defined RTCP XR IDMS Report Block. > = > [Ray: Hmm, I'm not sure. I checked with IANA and they don't see a = > problem in the current wording. I think this is fundamentally a = > question of describing the 'soll' situation versus describing the = > process of getting from 'ist' to 'soll'. Once the ETSI doc has been = > updated, your proposed sentence would no longer be necessary, right?] > = [[DR]] The phrase 'This document assigns ... ' is typically used for new as= signments, and may be misleading, especially in the interim. Describing exp= licitly the transfer of control is better IMO. = [Ray] Fair enough. How about: 'This document asks to update the assignment = of value 12 from the RTCP XR Block Type for reporting IDMS = information to the RTCP XR IDMS Report Block defined in this document' ? > This change is however partial as described previously, as the content = > of the fields and behavior for SPST =3D 2-4 remain under ETSI control. > Moreover, it is not clear who has further control for other new = > values, as SPST =3D 5-15 show as 'reserved for future use in both = > documents'. The IANA section does not define or refer an IANA registry = > and the policy for adding and approving new values for SPST. > = > This solution is not clean. Only one organization should have control = > upon the definition of one single RTCP XR block type. Either the IETF = > should make the overleaping parts of the document Informational and = > reflect the content of the ETSI document, or should take control over = > the whole block. > = > [Ray: See my earlier comments: IETF will have full control, ETSI will = > just be extending it.] > = [[DR]] a registry is better, it also avoids the need to make changes to thi= s document if new extensions are being defined by ETSI or other organizatio= ns. = [Ray] See my earlier comment: if the WG consensus is that we need a registr= y, I can include one. = > 3. The relation with the ETSI specification TS 183 063 should have = > been described clearly from the beginning of the document. > = > [Ray: See my earlier comment. Since the IETF draft will be that = > normative spec that ETSI will be referencing, I believe this = > relationship should be described in ETSI, not in IETF]. > = [[DR]] This is where we disagree. If there was no history of control, no pr= evious ETSI specification you would be right, but this is not the case. = [Ray] Can we agree to a short informational section that describes the hist= ory of IDMS in ETSI and IETF? > 4. In Section 7: > = > When > reporting on an RTP packet which is one of several consecutive RTP > packets having equal timestamps, an SC SHOULD report on the RTP > packet it received with the lowest sequence number. > = > Why a SHOULD here and not a MUST? If there are any cases of exception = > they need to be detailed. > = > [Ray: Implementations might be optimized for specific scenarios by = > reporting on specific packets as indicated by e.g. an out-of-band = > signal] > = [[DR]] It would be good to clarify this in the text. = [Ray] OK > 7. In Section 8: > = > The timestamp is formatted based on the NTP > timestamp format as specified in [RFC5905]. If this field is empty, > then it SHALL be set to 0. This field MAY be left empty if none or > only one of the receivers reported on presentation timestamps. > = > Why a MAY here? Especially for the case when none of the receivers = > reported, what content can be set there but 0 ? > = > [Ray: I believe it should be up to the implementation to decide how it = > wants to handle the case of there being only one receiver who reported = > on presentation timestamps]. > = [[DR]] OK, so the cases when none of the receivers reported and one receive= r only reported should be dealt with differently. This needs to be clarifie= d. = [Ray] What exactly is the problem with the MAY here? IMO it doesn't create = any interop issues: whatever is the reason for setting the value to 0, to t= he client the end result is the same: ignore it. = Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From dromasca@avaya.com Mon Jun 10 06:11:10 2013 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 A4A7621F8AC2; Mon, 10 Jun 2013 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 ASVcaeA1UB3Y; Mon, 10 Jun 2013 06:11:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8C21F866E; Mon, 10 Jun 2013 06:11:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIPPtVGHCzI1/2dsb2JhbABagmghMEm+QYEDFnSCIwEBAQECARIoOAcFBwQCAQgNBAQBAQsUCQchERQJCAEBBAoEBQgTB4dZAwkGAQudMZJzDYg7F4xbgSuBATEHBoJ5YQOVWAGIKYVchSSDD4FxNg X-IronPort-AV: E=Sophos;i="4.87,837,1363147200"; d="scan'208";a="12506580" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2013 09:11:00 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jun 2013 09:05:54 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 09:10:38 -0400 From: "Romascanu, Dan (Dan)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThA= Date: Mon, 10 Jun 2013 13:10:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 13:11:11 -0000 Hi Ray, Thanks again for considering my comments.=20 See in-line.=20 Regards, Dan > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 3:28 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 > Hi Dan, >=20 > (I've cc'ed the AVTCORE list on Magnus' request) >=20 > Please see my comments inline (I've shortened the message exchange > somewhat to only include the points of discussion). >=20 > Best regards, >=20 > Ray >=20 > > Before responding to your comments in detail, let me give you some > > background on how we handle the relationship with the ETSI document: > > Exactly how we should deal with the existing ETSI spec has been > > discussed at length in AVTCORE, both on- and offlist. As you can see > > in the earlier versions of the draft, the document used to extend the > > ETSI document, referencing it where necessary and including sections > > that describe this relationship. In the end, the WG consensus was that > > the IETF draft should be the normative spec for the XR block and > > AVTCORE should have full change control over it. We therefore removed > > most references to the ETSI spec, and instead started a Work Item in > > ETSI to change TS 183 063 to point to the IETF draft and remove all > > normative statements (apart from extending the IETF-defined block with > > three new SPST values). > > > [[DR]] Thank you for the clarification information. This is very useful. > Can you tell what is the status of the work item in ETSI? >=20 > [Ray] The current status is that the Work Item has been opened and the > contributions have been written and discussed. ETSI has postponed > formally accepting the contributions until the IETF document is given an > RFC number so that they can reference it. >=20 > > The current idea is therefore that since the ETSI spec will be > > referencing the IETF spec, instead of the other way around, that there > > is no need to describe this relationship in the IETF draft. The IETF > > spec is the normative 'base' spec, and ETSI is just describing a way > > to use it within an IPTV system, including three additional SPST > > values specific to that scenario. > [[DR]] I disagree that there is no need to describe this relationship on > the IETF draft. As control for the XR block was previously in ETSI and > will now be transferred to the IETF we should assume that there are > implementers and deployments who know about the older ETSI > specification. You need a sections that describes the relationship with > the ETSI document, and describes the changes relative to that version - > same as would have been written if there was an RFC that was updated or > made obsolete by this document. >=20 > Moreover, the current document is not consistent, as it still keeps a > normative reference to the older (not even the latest version) ETSI > document. This will be not needed any longer, an informational reference > would be sufficient. >=20 > [Ray] I agree completely. This seems to be a relic and I will update the > reference to make it informational. >=20 > > 1. This document is tightly connected with the ETSI specification TS > > 183 063. However this relation is mentioned only in a couple of places > > and does not describe the complexity of the relation. Moreover, the > > relation itself seems problematic. > > > > The I-D uses some of the inter-destination media techniques described > > by ETSI TS 183 063. For example Section 7 replicates part of the > > content of Annex W of the ETSI document. It does it partially however, > > and with some modifications, as only the content definition and > > behavior of the transmitters and receivers for SPST=3D1 were taken from > > Annex W, while the content and behavior for SPST=3D2-4 are marked as > > 'defined by ETSI TISPAN'. The ETSI document details what happens with > > the fields when SPST=3D2-4. This will result in the RTCP XR block for > > IDMS to be defined in two places - part in this IETF document (if > > approved), the rest in the ETSI document (to be modified accordingly > > in the future). For some period of time the same fields will be > > defined in two places. This seems broken. > > > > [Ray: See my comments above. The ETSI document will be changed to > > point to the IETF spec. Does this solve your issue? In addition, we > > could create an IANA registry for SPST values, although I personally > > believe this to not be necessary] > > > [[DR]] Eventually it will solve the issue, but the situation is murky in > the interim. I believe that creating a registry would be good, because > it provides a way to describe the interim situation, and also because we > do not know yet for sure who may use the values 5-15 in the future. >=20 > [Ray] As Roni mentioned, it is a chicken-egg problem. If there is > consensus in the WG to create a registry, I am happy to include one in > the draft. >=20 > > 2. The note to the RFC Editor in section 14.2 states: > > > > 14.2. RTCP XR IDMS Report Block > > > > This document assigns the block type value 12 in the IANA "RTCP XR > > Block Type Registry" to the RTCP XR IDMS Report Block. > > > > [Note to RFC Editor: this block type value is currently assigned to > > [TS183063]. This document replaces [TS183063] as the normative > > specification of the RTCP XR IDMS Report Block. Upon publication > of > > this document as RFC, [TS183063] will be changed to reflect this. > > > > The first statement is not accurate. Value 12 is not a new assignment, > > 12 was already assigned by ETSI, this document asks to change the > > assignment of value 12 from the RTCP XR Block Type for reporting IDMS > > information to the IETF defined RTCP XR IDMS Report Block. > > > > [Ray: Hmm, I'm not sure. I checked with IANA and they don't see a > > problem in the current wording. I think this is fundamentally a > > question of describing the 'soll' situation versus describing the > > process of getting from 'ist' to 'soll'. Once the ETSI doc has been > > updated, your proposed sentence would no longer be necessary, right?] > > > [[DR]] The phrase 'This document assigns ... ' is typically used for new > assignments, and may be misleading, especially in the interim. > Describing explicitly the transfer of control is better IMO. >=20 > [Ray] Fair enough. How about: 'This document asks to update the > assignment of value 12 from the RTCP XR Block Type for reporting IDMS > information to the RTCP XR IDMS Report Block defined in this document' ? >=20 [[DR]] close, with slight edits, I would make it:=20 'This document updates the assignment of value 12 from the RTCP XR=20 Block Type for reporting IDMS information as per [TS183063] to the=20 RTCP XR IDMS Report Block defined in this document'=20 > > This change is however partial as described previously, as the content > > of the fields and behavior for SPST =3D 2-4 remain under ETSI control. > > Moreover, it is not clear who has further control for other new > > values, as SPST =3D 5-15 show as 'reserved for future use in both > > documents'. The IANA section does not define or refer an IANA registry > > and the policy for adding and approving new values for SPST. > > > > This solution is not clean. Only one organization should have control > > upon the definition of one single RTCP XR block type. Either the IETF > > should make the overleaping parts of the document Informational and > > reflect the content of the ETSI document, or should take control over > > the whole block. > > > > [Ray: See my earlier comments: IETF will have full control, ETSI will > > just be extending it.] > > > [[DR]] a registry is better, it also avoids the need to make changes to > this document if new extensions are being defined by ETSI or other > organizations. >=20 > [Ray] See my earlier comment: if the WG consensus is that we need a > registry, I can include one. >=20 > > 3. The relation with the ETSI specification TS 183 063 should have > > been described clearly from the beginning of the document. > > > > [Ray: See my earlier comment. Since the IETF draft will be that > > normative spec that ETSI will be referencing, I believe this > > relationship should be described in ETSI, not in IETF]. > > > [[DR]] This is where we disagree. If there was no history of control, no > previous ETSI specification you would be right, but this is not the > case. >=20 > [Ray] Can we agree to a short informational section that describes the > history of IDMS in ETSI and IETF? >=20 >=20 [[DR]] that's all I am asking > > 4. In Section 7: > > > > When > > reporting on an RTP packet which is one of several consecutive RTP > > packets having equal timestamps, an SC SHOULD report on the RTP > > packet it received with the lowest sequence number. > > > > Why a SHOULD here and not a MUST? If there are any cases of exception > > they need to be detailed. > > > > [Ray: Implementations might be optimized for specific scenarios by > > reporting on specific packets as indicated by e.g. an out-of-band > > signal] > > > [[DR]] It would be good to clarify this in the text. >=20 > [Ray] OK >=20 >=20 > > 7. In Section 8: > > > > The timestamp is formatted based on the NTP > > timestamp format as specified in [RFC5905]. If this field is > empty, > > then it SHALL be set to 0. This field MAY be left empty if none or > > only one of the receivers reported on presentation timestamps. > > > > Why a MAY here? Especially for the case when none of the receivers > > reported, what content can be set there but 0 ? > > > > [Ray: I believe it should be up to the implementation to decide how it > > wants to handle the case of there being only one receiver who reported > > on presentation timestamps]. > > > [[DR]] OK, so the cases when none of the receivers reported and one > receiver only reported should be dealt with differently. This needs to > be clarified. >=20 > [Ray] What exactly is the problem with the MAY here? IMO it doesn't > create any interop issues: whatever is the reason for setting the value > to 0, to the client the end result is the same: ignore it. >=20 [[DR]] In the case when none of the receivers reported we want to avoid lea= ving some garbage in this field which could be interpreted differently - do= n't we?=20 > Best regards, >=20 > Ray > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer From kevin.gross@avanw.com Mon Jun 10 07:26:16 2013 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 0CBFD21F93E5 for ; Mon, 10 Jun 2013 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, 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 GWaeGs0YUnRE for ; Mon, 10 Jun 2013 07:26:12 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 94C0321F93FB for ; Mon, 10 Jun 2013 07:26:07 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta14.emeryville.ca.mail.comcast.net with comcast id meFG1l00617UAYkAEeS6pT; Mon, 10 Jun 2013 14:26:06 +0000 Received: from mail-ie0-x22f.google.com ([IPv6:2607:f8b0:4001:c03::22f]) by omta13.emeryville.ca.mail.comcast.net with comcast id meS41l00x5FJP4R8ZeS5Cc; Mon, 10 Jun 2013 14:26:06 +0000 Received: by mail-ie0-f175.google.com with SMTP id a13so3505636iee.20 for ; Mon, 10 Jun 2013 07:26:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxSUwGNAiNQ+YkSrt0Qdt6RNZ1iHRyTYpqS/VnTwvsk=; b=ZjdxUDkSKhOAuU4HegUwFttzMflHo9wBF38LEkma/YyjoSU/Q2Afd1HU1GZ9g+jhDf D4OBSCtTVKs++k/XNMfzj1AbLSdttnKC2goneIp6pEW5Jsh+kWATrkRopo+T8FLHNv5h GRXLhycYFQniMHtzzyyGl0bw9gpSgcuCS7JAmzuLk1A12ET8i+UdR864VBj3bXBpJjSY Zq0eifmE5YLKa32OgZhEhVWOM6gIAk4sFlglPtZHOTXKiQZ0i7pBy4Z20k2OEsQbaNt8 V7lQAnzcTsKbCd1/Lg3XzAocSwKfBSXhvEAQspDRkAQMyxlH//9ebDKnUH/p/1KoGE2x kGKA== MIME-Version: 1.0 X-Received: by 10.43.9.4 with SMTP id ou4mr3868419icb.53.1370874364796; Mon, 10 Jun 2013 07:26:04 -0700 (PDT) Received: by 10.50.149.199 with HTTP; Mon, 10 Jun 2013 07:26:04 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> Date: Mon, 10 Jun 2013 08:26:04 -0600 Message-ID: From: Kevin Gross To: "Brandenburg, R. (Ray) van" Content-Type: multipart/alternative; boundary=bcaec50dc32c8bcb4004decd8f9c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370874366; bh=JxSUwGNAiNQ+YkSrt0Qdt6RNZ1iHRyTYpqS/VnTwvsk=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=rNJ02E3PeQ/O/3Nx5cILUjm+6BESWPgy+EEa90QsSTR5YLus0/uJqz9IymmWe78e0 tTx/0fbXUXcxgALvvJpQAtSMBxsYUoD6a+5PFfoVc5G6yhOIHHNeYzLS+Qce0gqwHm jiImP4EhQLQR/6eMYf8x5Cs3t1eRebnPzZ9c5xd88zriKLIeUv8Yu9zBCNObqbmrIv aLajIkEP5HVWEgD6moYSwohS0w3FVg0IWTNHaDFdFPvN7JVKQ7PK/Ciq2Cjgl8QR19 HzyS0gU2evuxpW+AW8t+AjgsDdCPQ4niDWwye816LKX4/x5mzjo6d4aaRIqr5mY/NI FzKKox37UnJzQ== Cc: "Romascanu, Dan \(Dan\)" , General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 14:26:16 -0000 --bcaec50dc32c8bcb4004decd8f9c Content-Type: text/plain; charset=ISO-8859-1 Dan, thanks for looking at this. As a co-author, I'll weigh in on a couple of things that Ray did not address. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van < ray.vanbrandenburg@tno.nl> wrote: > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: zondag 9 juni 2013 9:53 > To: General Area Review Team > Cc: draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: Gen-ART review of draft-ietf-avtcore-idms-09 > > (resending, I mis-spelled .all address at the first try) > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-avtcore-idms-09 > Reviewer: Dan Romascanu > Review Date: 6/6/13 > IETF LC End Date: 6/11/13 > IESG Telechat date: > > Summary: > > Not Ready > > Major issues: > > 5. In Section 8: > > Because RTP > timestamps do wrap around, the sender of this packet SHOULD use > recent values, i.e. choose NTP timestamps that reflect current time > and not too far in the future or in the past. > > Why a SHOULD here and not a MUST? If there are any cases of exception they > need to be detailed. > > [Ray: I will check with my co-authors] > [Kevin] Devices that receive these reports need to deal with rollover conditions both for the RTP timestamp (which can rollover a couple times a day) and the NTP timestamp (which will have its first rollover in 2036). I believe these requirements are already stated in RFC3550 and RFC5905 respectively. The suggestion to use recent timestamps in reporting reduces statistical chance that a receiving device will need to do extra computation required to handle an RTP rollover. There's no way to eliminate this possibility altogether and the requirement is stated in a qualitative way and so could not be enforced as a MUST. > > 6. In Section 8: > > This SHOULD relate to the first > arriving RTP packet containing this particular RTP timestamp, in case > multiple RTP packets contain the same RTP timestamp. > > Why a SHOULD here and not a MUST? If there are any cases of exception they > need to be detailed. > > [Ray: I will check with my co-authors] > [Kevin] This is an issue that the authors discussed at length and for which we do not believe there is an optimal solution and so we were reluctant to require our recommendation. Ideally we want an NTP timestamp indicating when all data required to render the specified RTP timestamp has arrived. For this we'd really like to know when the last packet for an RTP timestamp arrived. In the presence packet loss and reordering, it is not possible to reliably record the last packet. It is possible to record the first packet and so this is our recommendation. The accuracy of arrival times is not so critical in IDMS as arrival time allows a less precise synchronization than presentation times. --bcaec50dc32c8bcb4004decd8f9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan, thanks for looking at this.

As a c= o-author, I'll weigh in on a couple of things that Ray did not address.=

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


On Mon, Jun 10, 2013 at 2:33 AM, Branden= burg, R. (Ray) van <ray.vanbrandenburg@tno.nl> wrote= :

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dr= omasca@avaya.com]
Sent: zondag 9 juni 2013 9:53
To: General Area Review Team
Cc: draft-iet= f-avtcore-idms.all@tools.ietf.org
Subject: Gen-ART review of draft-ietf-avtcore-idms-09

(resending, I mis-spelled .all address at the first try)

I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

Please resolve these comments along with any other Last Call comments you m= ay receive.

Document: draft-ietf-avtcore-idms-09
Reviewer: Dan Romascanu
Review Date: 6/6/13
IETF LC End Date: 6/11/13
IESG Telechat date:

Summary:

Not Ready

Major issues:

5. In Section 8:

=A0 =A0Because RTP
=A0 =A0timestamps do wrap around, the sender of this packet SHOULD use
=A0 =A0recent values, i.e. choose NTP timestamps that reflect current time<= br> =A0 =A0and not too far in the future or in the past.

Why a SHOULD here and not a MUST? If there are any cases of exception they = need to be detailed.

[Ray: I will check with my co-authors]

[Kevin] Devices that receive these reports need to deal with ro= llover conditions both for the RTP timestamp (which can rollover a couple t= imes a day) and the NTP timestamp (which will have its first rollover in 20= 36). I believe these requirements are already stated in RFC3550 and RFC5905= respectively. The suggestion to use recent timestamps in reporting reduces= statistical chance that a receiving device will need to do extra computati= on required to handle an RTP rollover. There's no way to eliminate this= possibility altogether and the requirement is stated in a qualitative way = and so could not be enforced as a MUST.

6. In Section 8:

=A0 =A0This SHOULD relate to the first
=A0 =A0arriving RTP packet containing this particular RTP timestamp, in cas= e
=A0 =A0multiple RTP packets contain the same RTP timestamp.

Why a SHOULD here and not a MUST? If there are any cases of exception they = need to be detailed.

[Ray: I will check with my co-authors]

[Kevin] This is an issue that the authors discussed at length a= nd for which we do not believe there is an optimal solution and so we were = reluctant to require our recommendation. Ideally we want an NTP timestamp i= ndicating when all data required to render the specified RTP timestamp has = arrived. For this we'd really like to know when the last packet for an = RTP timestamp arrived. In the presence packet loss and reordering, it is no= t possible to reliably record the last packet. It is possible to record the= first packet and so this is our recommendation. The accuracy of arrival ti= mes is not so critical in IDMS as arrival time allows a less precise synchr= onization than presentation times.
--bcaec50dc32c8bcb4004decd8f9c-- From ray.vanbrandenburg@tno.nl Mon Jun 10 07:27:14 2013 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 2CC0A21F9485; Mon, 10 Jun 2013 07:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Wrzb8I1fjksv; Mon, 10 Jun 2013 07:27:08 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB921F9473; Mon, 10 Jun 2013 07:27:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,837,1363129200"; d="scan'208";a="9667752" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 10 Jun 2013 16:27:06 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 16:27:06 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4A== Date: Mon, 10 Jun 2013 14:27:05 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 14:27:14 -0000 Hi Dan, Please see inline. We seem to be converging:) Ray -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: maandag 10 juni 2013 15:11 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org; General Area Review Team; Roni Even (ron.even.tlv@gmail.c= om); draft-ietf-avtcore-idms.all@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 Hi Ray, Thanks again for considering my comments.=20 See in-line.=20 Regards, Dan > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 3:28 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even=20 > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 > Hi Dan, >=20 > (I've cc'ed the AVTCORE list on Magnus' request) >=20 > Please see my comments inline (I've shortened the message exchange=20 > somewhat to only include the points of discussion). >=20 > Best regards, >=20 > Ray >=20 > > Before responding to your comments in detail, let me give you some=20 > > background on how we handle the relationship with the ETSI document: > > Exactly how we should deal with the existing ETSI spec has been=20 > > discussed at length in AVTCORE, both on- and offlist. As you can see=20 > > in the earlier versions of the draft, the document used to extend=20 > > the ETSI document, referencing it where necessary and including=20 > > sections that describe this relationship. In the end, the WG=20 > > consensus was that the IETF draft should be the normative spec for=20 > > the XR block and AVTCORE should have full change control over it. We=20 > > therefore removed most references to the ETSI spec, and instead=20 > > started a Work Item in ETSI to change TS 183 063 to point to the=20 > > IETF draft and remove all normative statements (apart from extending=20 > > the IETF-defined block with three new SPST values). > > > [[DR]] Thank you for the clarification information. This is very useful. > Can you tell what is the status of the work item in ETSI? >=20 > [Ray] The current status is that the Work Item has been opened and the=20 > contributions have been written and discussed. ETSI has postponed=20 > formally accepting the contributions until the IETF document is given=20 > an RFC number so that they can reference it. >=20 > > The current idea is therefore that since the ETSI spec will be=20 > > referencing the IETF spec, instead of the other way around, that=20 > > there is no need to describe this relationship in the IETF draft.=20 > > The IETF spec is the normative 'base' spec, and ETSI is just=20 > > describing a way to use it within an IPTV system, including three=20 > > additional SPST values specific to that scenario. > [[DR]] I disagree that there is no need to describe this relationship=20 > on the IETF draft. As control for the XR block was previously in ETSI=20 > and will now be transferred to the IETF we should assume that there=20 > are implementers and deployments who know about the older ETSI=20 > specification. You need a sections that describes the relationship=20 > with the ETSI document, and describes the changes relative to that=20 > version - same as would have been written if there was an RFC that was=20 > updated or made obsolete by this document. >=20 > Moreover, the current document is not consistent, as it still keeps a=20 > normative reference to the older (not even the latest version) ETSI=20 > document. This will be not needed any longer, an informational=20 > reference would be sufficient. >=20 > [Ray] I agree completely. This seems to be a relic and I will update=20 > the reference to make it informational. >=20 > > 1. This document is tightly connected with the ETSI specification TS > > 183 063. However this relation is mentioned only in a couple of=20 > > places and does not describe the complexity of the relation.=20 > > Moreover, the relation itself seems problematic. > > > > The I-D uses some of the inter-destination media techniques=20 > > described by ETSI TS 183 063. For example Section 7 replicates part=20 > > of the content of Annex W of the ETSI document. It does it partially=20 > > however, and with some modifications, as only the content definition=20 > > and behavior of the transmitters and receivers for SPST=3D1 were taken= =20 > > from Annex W, while the content and behavior for SPST=3D2-4 are marked= =20 > > as 'defined by ETSI TISPAN'. The ETSI document details what happens=20 > > with the fields when SPST=3D2-4. This will result in the RTCP XR block= =20 > > for IDMS to be defined in two places - part in this IETF document=20 > > (if approved), the rest in the ETSI document (to be modified=20 > > accordingly in the future). For some period of time the same fields=20 > > will be defined in two places. This seems broken. > > > > [Ray: See my comments above. The ETSI document will be changed to=20 > > point to the IETF spec. Does this solve your issue? In addition, we=20 > > could create an IANA registry for SPST values, although I personally=20 > > believe this to not be necessary] > > > [[DR]] Eventually it will solve the issue, but the situation is murky=20 > in the interim. I believe that creating a registry would be good,=20 > because it provides a way to describe the interim situation, and also=20 > because we do not know yet for sure who may use the values 5-15 in the fu= ture. >=20 > [Ray] As Roni mentioned, it is a chicken-egg problem. If there is=20 > consensus in the WG to create a registry, I am happy to include one in=20 > the draft. >=20 > > 2. The note to the RFC Editor in section 14.2 states: > > > > 14.2. RTCP XR IDMS Report Block > > > > This document assigns the block type value 12 in the IANA "RTCP XR > > Block Type Registry" to the RTCP XR IDMS Report Block. > > > > [Note to RFC Editor: this block type value is currently assigned to > > [TS183063]. This document replaces [TS183063] as the normative > > specification of the RTCP XR IDMS Report Block. Upon publication > of > > this document as RFC, [TS183063] will be changed to reflect this. > > > > The first statement is not accurate. Value 12 is not a new=20 > > assignment, > > 12 was already assigned by ETSI, this document asks to change the=20 > > assignment of value 12 from the RTCP XR Block Type for reporting=20 > > IDMS information to the IETF defined RTCP XR IDMS Report Block. > > > > [Ray: Hmm, I'm not sure. I checked with IANA and they don't see a=20 > > problem in the current wording. I think this is fundamentally a=20 > > question of describing the 'soll' situation versus describing the=20 > > process of getting from 'ist' to 'soll'. Once the ETSI doc has been=20 > > updated, your proposed sentence would no longer be necessary,=20 > > right?] > > > [[DR]] The phrase 'This document assigns ... ' is typically used for=20 > new assignments, and may be misleading, especially in the interim. > Describing explicitly the transfer of control is better IMO. >=20 > [Ray] Fair enough. How about: 'This document asks to update the=20 > assignment of value 12 from the RTCP XR Block Type for reporting IDMS=20 > information to the RTCP XR IDMS Report Block defined in this document' ? >=20 [[DR]] close, with slight edits, I would make it:=20 'This document updates the assignment of value 12 from the RTCP XR Block Ty= pe for reporting IDMS information as per [TS183063] to the RTCP XR IDMS Rep= ort Block defined in this document'=20 [Ray] Ok. > > This change is however partial as described previously, as the=20 > > content of the fields and behavior for SPST =3D 2-4 remain under ETSI c= ontrol. > > Moreover, it is not clear who has further control for other new=20 > > values, as SPST =3D 5-15 show as 'reserved for future use in both=20 > > documents'. The IANA section does not define or refer an IANA=20 > > registry and the policy for adding and approving new values for SPST. > > > > This solution is not clean. Only one organization should have=20 > > control upon the definition of one single RTCP XR block type. Either=20 > > the IETF should make the overleaping parts of the document=20 > > Informational and reflect the content of the ETSI document, or=20 > > should take control over the whole block. > > > > [Ray: See my earlier comments: IETF will have full control, ETSI=20 > > will just be extending it.] > > > [[DR]] a registry is better, it also avoids the need to make changes=20 > to this document if new extensions are being defined by ETSI or other=20 > organizations. >=20 > [Ray] See my earlier comment: if the WG consensus is that we need a=20 > registry, I can include one. >=20 > > 3. The relation with the ETSI specification TS 183 063 should have=20 > > been described clearly from the beginning of the document. > > > > [Ray: See my earlier comment. Since the IETF draft will be that=20 > > normative spec that ETSI will be referencing, I believe this=20 > > relationship should be described in ETSI, not in IETF]. > > > [[DR]] This is where we disagree. If there was no history of control,=20 > no previous ETSI specification you would be right, but this is not the=20 > case. >=20 > [Ray] Can we agree to a short informational section that describes the=20 > history of IDMS in ETSI and IETF? >=20 >=20 [[DR]] that's all I am asking [Ray] Ok, I think that is acceptable.=20 > > 4. In Section 7: > > > > When > > reporting on an RTP packet which is one of several consecutive RTP > > packets having equal timestamps, an SC SHOULD report on the RTP > > packet it received with the lowest sequence number. > > > > Why a SHOULD here and not a MUST? If there are any cases of=20 > > exception they need to be detailed. > > > > [Ray: Implementations might be optimized for specific scenarios by=20 > > reporting on specific packets as indicated by e.g. an out-of-band=20 > > signal] > > > [[DR]] It would be good to clarify this in the text. >=20 > [Ray] OK >=20 >=20 > > 7. In Section 8: > > > > The timestamp is formatted based on the NTP > > timestamp format as specified in [RFC5905]. If this field is > empty, > > then it SHALL be set to 0. This field MAY be left empty if none or > > only one of the receivers reported on presentation timestamps. > > > > Why a MAY here? Especially for the case when none of the receivers=20 > > reported, what content can be set there but 0 ? > > > > [Ray: I believe it should be up to the implementation to decide how=20 > > it wants to handle the case of there being only one receiver who=20 > > reported on presentation timestamps]. > > > [[DR]] OK, so the cases when none of the receivers reported and one=20 > receiver only reported should be dealt with differently. This needs to=20 > be clarified. >=20 > [Ray] What exactly is the problem with the MAY here? IMO it doesn't=20 > create any interop issues: whatever is the reason for setting the=20 > value to 0, to the client the end result is the same: ignore it. >=20 [[DR]] In the case when none of the receivers reported we want to avoid lea= ving some garbage in this field which could be interpreted differently - do= n't we?=20 [Ray] I think I see where we disagree. The paragraph says: "If this field i= s empty, then it SHALL be set to 0. This field MAY be left empty if none or= only one of the receivers reported on presentation timestamps". The way I = read this is as: In the case the field is declared empty (=3D contains NULL= information), it SHALL be set to 0. There can be different reasons for dec= laring the field empty/NULL, one of those reasons is if none or only one re= ceiver reported on presentation timestamps. To me, the paragraph doesn't sa= y that this is the only possible reason, but it does specify very clearly t= hat if you decide the field should be empty, you SHALL set it to zero.=20 > Best regards, >=20 > Ray > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/emaildisclaimer From dromasca@avaya.com Mon Jun 10 07:34:44 2013 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 51CFF21F8F6E; Mon, 10 Jun 2013 07:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 kEXw1RgbOzKh; Mon, 10 Jun 2013 07:34:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78321F8F61; Mon, 10 Jun 2013 07:34:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIritVHGmAcF/2dsb2JhbABagmgheb5CgQQWdIIjAQEBAQIBEig/DAQCAQgNBAQBAQsUCQchERQJCAIEDgUIGodZAwkGAZ1TkwQNiDsXjFuCLDEHBoJ5YQOVWAGIKYVchSSDD4In X-IronPort-AV: E=Sophos;i="4.87,837,1363147200"; d="scan'208";a="12521285" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2013 10:34:33 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2013 10:33:04 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 10:34:31 -0400 From: "Romascanu, Dan (Dan)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/A Date: Mon, 10 Jun 2013 14:34:31 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 14:34:44 -0000 Yes, we seem to get closer and closer, focus on one last issue (and much ag= reement deleted) Thanks and Regards, Dan > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 5:27 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 > Hi Dan, >=20 > Please see inline. We seem to be converging:) >=20 > Ray > > > 7. In Section 8: > > > > > > The timestamp is formatted based on the NTP > > > timestamp format as specified in [RFC5905]. If this field is > > empty, > > > then it SHALL be set to 0. This field MAY be left empty if none > or > > > only one of the receivers reported on presentation timestamps. > > > > > > Why a MAY here? Especially for the case when none of the receivers > > > reported, what content can be set there but 0 ? > > > > > > [Ray: I believe it should be up to the implementation to decide how > > > it wants to handle the case of there being only one receiver who > > > reported on presentation timestamps]. > > > > > [[DR]] OK, so the cases when none of the receivers reported and one > > receiver only reported should be dealt with differently. This needs to > > be clarified. > > > > [Ray] What exactly is the problem with the MAY here? IMO it doesn't > > create any interop issues: whatever is the reason for setting the > > value to 0, to the client the end result is the same: ignore it. > > >=20 > [[DR]] In the case when none of the receivers reported we want to avoid > leaving some garbage in this field which could be interpreted > differently - don't we? >=20 > [Ray] I think I see where we disagree. The paragraph says: "If this > field is empty, then it SHALL be set to 0. This field MAY be left empty > if none or only one of the receivers reported on presentation > timestamps". The way I read this is as: In the case the field is > declared empty (=3D contains NULL information), it SHALL be set to 0. > There can be different reasons for declaring the field empty/NULL, one > of those reasons is if none or only one receiver reported on > presentation timestamps. To me, the paragraph doesn't say that this is > the only possible reason, but it does specify very clearly that if you > decide the field should be empty, you SHALL set it to zero. >=20 >=20 [[DR]] But then, why do not you take out 'if none or' - because for the opt= ion of 'none' there is no alternative but the 'null' information, and the M= AY does not make sense.=20 Dan From dromasca@avaya.com Mon Jun 10 07:40:33 2013 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 F0C3E21F938E; Mon, 10 Jun 2013 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.348 X-Spam-Level: X-Spam-Status: No, score=-103.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 N1TuFurvVW-D; Mon, 10 Jun 2013 07:40:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3239421F9399; Mon, 10 Jun 2013 07:40:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAJ7ktVGHCzI1/2dsb2JhbABXA4JFIyEwSbV4iEqBBBZ0giMBAQEBAxIbHDAMBAIBCAcGBAMBAQELHQcyFAkIAgQOBQgTB4drAQudR5tMF48HIAENAwYBBgMIgm5hA5hphRmLAIMPgic X-IronPort-AV: E=Sophos;i="4.87,837,1363147200"; d="scan'208,217";a="12522144" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2013 10:40:24 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jun 2013 10:35:37 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 10:40:22 -0400 From: "Romascanu, Dan (Dan)" To: Kevin Gross , "Brandenburg, R. (Ray) van" Thread-Topic: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: AQHOZeZ7ymQ4hhifMECwBepzBAET3ZkvBFkQ Date: Mon, 10 Jun 2013 14:40:22 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA199E5B@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA199E5BAZFFEXMB04globala_" MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 14:40:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA199E5BAZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, Thank you for looking at my comments and for explaining in detail the edito= rial decisions that you made. Both explanations make sense, and leaving the= current text in place is acceptable. Regards, Dan From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin= Gross Sent: Monday, June 10, 2013 5:26 PM To: Brandenburg, R. (Ray) van Cc: Romascanu, Dan (Dan); General Area Review Team; avt@ietf.org; draft-iet= f-avtcore-idms.all@tools.ietf.org Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 Dan, thanks for looking at this. As a co-author, I'll weigh in on a couple of things that Ray did not addres= s. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com, www.X192.org On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van > wrote: -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: zondag 9 juni 2013 9:53 To: General Area Review Team Cc: draft-ietf-avtcore-idms.all@tools.ietf.org Subject: Gen-ART review of draft-ietf-avtcore-idms-09 (resending, I mis-spelled .all address at the first try) I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-avtcore-idms-09 Reviewer: Dan Romascanu Review Date: 6/6/13 IETF LC End Date: 6/11/13 IESG Telechat date: Summary: Not Ready Major issues: 5. In Section 8: Because RTP timestamps do wrap around, the sender of this packet SHOULD use recent values, i.e. choose NTP timestamps that reflect current time and not too far in the future or in the past. Why a SHOULD here and not a MUST? If there are any cases of exception they = need to be detailed. [Ray: I will check with my co-authors] [Kevin] Devices that receive these reports need to deal with rollover condi= tions both for the RTP timestamp (which can rollover a couple times a day) = and the NTP timestamp (which will have its first rollover in 2036). I belie= ve these requirements are already stated in RFC3550 and RFC5905 respectivel= y. The suggestion to use recent timestamps in reporting reduces statistical= chance that a receiving device will need to do extra computation required = to handle an RTP rollover. There's no way to eliminate this possibility alt= ogether and the requirement is stated in a qualitative way and so could not= be enforced as a MUST. 6. In Section 8: This SHOULD relate to the first arriving RTP packet containing this particular RTP timestamp, in case multiple RTP packets contain the same RTP timestamp. Why a SHOULD here and not a MUST? If there are any cases of exception they = need to be detailed. [Ray: I will check with my co-authors] [Kevin] This is an issue that the authors discussed at length and for which= we do not believe there is an optimal solution and so we were reluctant to= require our recommendation. Ideally we want an NTP timestamp indicating wh= en all data required to render the specified RTP timestamp has arrived. For= this we'd really like to know when the last packet for an RTP timestamp ar= rived. In the presence packet loss and reordering, it is not possible to re= liably record the last packet. It is possible to record the first packet an= d so this is our recommendation. The accuracy of arrival times is not so cr= itical in IDMS as arrival time allows a less precise synchronization than p= resentation times. --_000_9904FB1B0159DA42B0B887B7FA8119CA199E5BAZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

 <= /p>

Thank you for looking at = my comments and for explaining in detail the editorial decisions that you m= ade. Both explanations make sense, and leaving the current text in place is acceptable.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin Gross
Sent: Monday, June 10, 2013 5:26 PM
To: Brandenburg, R. (Ray) van
Cc: Romascanu, Dan (Dan); General Area Review Team; avt@ietf.org; dr= aft-ietf-avtcore-idms.all@tools.ietf.org
Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09<= o:p>

 

Dan, thanks for looking at this.

 

As a co-author, I'll weigh in on a couple of things = that Ray did not address.


Kevin Gross

+1-303-447-0517

Media Network Consultant

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

 

On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ra= y) van <r= ay.vanbrandenburg@tno.nl> wrote:

 

-----Original Message= -----
From: Romascanu, Dan (Dan) [mailto:dr= omasca@avaya.com]
Sent: zondag 9 juni 2013 9:53
To: General Area Review Team
Cc: draft-iet= f-avtcore-idms.all@tools.ietf.org
Subject: Gen-ART review of draft-ietf-avtcore-idms-09

(resending, I mis-spelled .all address at the first try)

I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

Please resolve these comments along with any other Last Call comments you m= ay receive.

Document: draft-ietf-avtcore-idms-09
Reviewer: Dan Romascanu
Review Date: 6/6/13
IETF LC End Date: 6/11/13
IESG Telechat date:

Summary:

Not Ready

Major issues:

5. In Section 8:

   Because RTP
   timestamps do wrap around, the sender of this packet SHOULD us= e
   recent values, i.e. choose NTP timestamps that reflect current= time
   and not too far in the future or in the past.

Why a SHOULD here and not a MUST? If there are any cases of exception they = need to be detailed.

[Ray: I will check with my co-authors]

 

[Kevin] Devices that receive these reports need to d= eal with rollover conditions both for the RTP timestamp (which can rollover= a couple times a day) and the NTP timestamp (which will have its first rol= lover in 2036). I believe these requirements are already stated in RFC3550 and RFC5905 respectively. The suggestion to = use recent timestamps in reporting reduces statistical chance that a receiv= ing device will need to do extra computation required to handle an RTP roll= over. There's no way to eliminate this possibility altogether and the requirement is stated in a qualitative= way and so could not be enforced as a MUST.


6. In Section 8:

   This SHOULD relate to the first
   arriving RTP packet containing this particular RTP timestamp, = in case
   multiple RTP packets contain the same RTP timestamp.

Why a SHOULD here and not a MUST? If there are any cases of exception they = need to be detailed.

[Ray: I will check with my co-authors]

 

[Kevin] This is an issue that the authors discussed = at length and for which we do not believe there is an optimal solution and = so we were reluctant to require our recommendation. Ideally we want an NTP = timestamp indicating when all data required to render the specified RTP timestamp has arrived. For this we'd = really like to know when the last packet for an RTP timestamp arrived. In t= he presence packet loss and reordering, it is not possible to reliably reco= rd the last packet. It is possible to record the first packet and so this is our recommendation. The accuracy= of arrival times is not so critical in IDMS as arrival time allows a less = precise synchronization than presentation times.

--_000_9904FB1B0159DA42B0B887B7FA8119CA199E5BAZFFEXMB04globala_-- From ray.vanbrandenburg@tno.nl Mon Jun 10 07:52:02 2013 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 CCC0721F9408; Mon, 10 Jun 2013 07:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Z5DVMoDCyV7b; Mon, 10 Jun 2013 07:51:57 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 82B0B21F8EF7; Mon, 10 Jun 2013 07:51:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,837,1363129200"; d="scan'208";a="9669333" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 10 Jun 2013 16:51:50 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 16:51:49 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtA= Date: Mon, 10 Jun 2013 14:51:49 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 14:52:03 -0000 Hi Dan, See below... Best regards, Ray -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] = Sent: maandag 10 juni 2013 16:35 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org; General Area Review Team; Roni Even (ron.even.tlv@gmail.c= om); draft-ietf-avtcore-idms.all@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 Yes, we seem to get closer and closer, focus on one last issue (and much ag= reement deleted) Thanks and Regards, Dan > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 5:27 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even = > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > = > Hi Dan, > = > Please see inline. We seem to be converging:) > = > Ray > > > 7. In Section 8: > > > > > > The timestamp is formatted based on the NTP > > > timestamp format as specified in [RFC5905]. If this field is > > empty, > > > then it SHALL be set to 0. This field MAY be left empty if = > > > none > or > > > only one of the receivers reported on presentation timestamps. > > > > > > Why a MAY here? Especially for the case when none of the receivers = > > > reported, what content can be set there but 0 ? > > > > > > [Ray: I believe it should be up to the implementation to decide = > > > how it wants to handle the case of there being only one receiver = > > > who reported on presentation timestamps]. > > > > > [[DR]] OK, so the cases when none of the receivers reported and one = > > receiver only reported should be dealt with differently. This needs = > > to be clarified. > > > > [Ray] What exactly is the problem with the MAY here? IMO it doesn't = > > create any interop issues: whatever is the reason for setting the = > > value to 0, to the client the end result is the same: ignore it. > > > = > [[DR]] In the case when none of the receivers reported we want to = > avoid leaving some garbage in this field which could be interpreted = > differently - don't we? > = > [Ray] I think I see where we disagree. The paragraph says: "If this = > field is empty, then it SHALL be set to 0. This field MAY be left = > empty if none or only one of the receivers reported on presentation = > timestamps". The way I read this is as: In the case the field is = > declared empty (=3D contains NULL information), it SHALL be set to 0. > There can be different reasons for declaring the field empty/NULL, one = > of those reasons is if none or only one receiver reported on = > presentation timestamps. To me, the paragraph doesn't say that this is = > the only possible reason, but it does specify very clearly that if you = > decide the field should be empty, you SHALL set it to zero. > = > = [[DR]] But then, why do not you take out 'if none or' - because for the opt= ion of 'none' there is no alternative but the 'null' information, and the M= AY does not make sense. = [Ray] The fact that no receiver reported on the packet presentation timesta= mp does not necessarily mean that the MSAS does not want to indicate a prop= osed packet presentation timestamp. The absence of such reports just means = that the proposed playout moment might not be realistic, or be supported by= any receiver. = Dan This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From dromasca@avaya.com Mon Jun 10 07:57:23 2013 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 D7AEC21F95D7; Mon, 10 Jun 2013 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 47YXCJLzOHJi; Mon, 10 Jun 2013 07:57:11 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 734D421F938E; Mon, 10 Jun 2013 07:57:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAJTotVGHCzI1/2dsb2JhbABagmgheb5CgQQWdIIjAQEBAQMSKD8MBAIBCA0EBAEBCxQJByERFAkIAgQOBQgah1kDDwGdUpMJDYg7F4xbgiwxBwaCeWEDlVgBiCmFXIUkgw+CJw X-IronPort-AV: E=Sophos;i="4.87,837,1363147200"; d="scan'208";a="12524860" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2013 10:56:59 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jun 2013 10:52:12 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 16:56:57 +0200 From: "Romascanu, Dan (Dan)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQA== Date: Mon, 10 Jun 2013 14:56:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 14:57:23 -0000 X-List-Received-Date: Mon, 10 Jun 2013 14:57:23 -0000 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 5:52 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 > Hi Dan, >=20 > See below... >=20 > Best regards, >=20 > Ray >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: maandag 10 juni 2013 16:35 > To: Brandenburg, R. (Ray) van > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 >=20 > Yes, we seem to get closer and closer, focus on one last issue (and much > agreement deleted) >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > Sent: Monday, June 10, 2013 5:27 PM > > To: Romascanu, Dan (Dan) > > Cc: avt@ietf.org; General Area Review Team; Roni Even > > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > > > > Hi Dan, > > > > Please see inline. We seem to be converging:) > > > > Ray >=20 > > > > 7. In Section 8: > > > > > > > > The timestamp is formatted based on the NTP > > > > timestamp format as specified in [RFC5905]. If this field is > > > empty, > > > > then it SHALL be set to 0. This field MAY be left empty if > > > > none > > or > > > > only one of the receivers reported on presentation timestamps. > > > > > > > > Why a MAY here? Especially for the case when none of the receivers > > > > reported, what content can be set there but 0 ? > > > > > > > > [Ray: I believe it should be up to the implementation to decide > > > > how it wants to handle the case of there being only one receiver > > > > who reported on presentation timestamps]. > > > > > > > [[DR]] OK, so the cases when none of the receivers reported and one > > > receiver only reported should be dealt with differently. This needs > > > to be clarified. > > > > > > [Ray] What exactly is the problem with the MAY here? IMO it doesn't > > > create any interop issues: whatever is the reason for setting the > > > value to 0, to the client the end result is the same: ignore it. > > > > > > > [[DR]] In the case when none of the receivers reported we want to > > avoid leaving some garbage in this field which could be interpreted > > differently - don't we? > > > > [Ray] I think I see where we disagree. The paragraph says: "If this > > field is empty, then it SHALL be set to 0. This field MAY be left > > empty if none or only one of the receivers reported on presentation > > timestamps". The way I read this is as: In the case the field is > > declared empty (=3D contains NULL information), it SHALL be set to 0. > > There can be different reasons for declaring the field empty/NULL, one > > of those reasons is if none or only one receiver reported on > > presentation timestamps. To me, the paragraph doesn't say that this is > > the only possible reason, but it does specify very clearly that if you > > decide the field should be empty, you SHALL set it to zero. > > > > >=20 > [[DR]] But then, why do not you take out 'if none or' - because for the > option of 'none' there is no alternative but the 'null' information, and > the MAY does not make sense. >=20 > [Ray] The fact that no receiver reported on the packet presentation > timestamp does not necessarily mean that the MSAS does not want to > indicate a proposed packet presentation timestamp. The absence of such > reports just means that the proposed playout moment might not be > realistic, or be supported by any receiver. >=20 [[DR]] yes, but is the field set to anything but 0 in such cases?=20 Dan From ray.vanbrandenburg@tno.nl Mon Jun 10 08:06:15 2013 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 E75BB21F96F5; Mon, 10 Jun 2013 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 ozH18FxEojmB; Mon, 10 Jun 2013 08:06:09 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7602321F9732; Mon, 10 Jun 2013 08:06:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,837,1363129200"; d="scan'208";a="1611512" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 10 Jun 2013 17:05:59 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 17:05:59 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQAAAZQ1g Date: Mon, 10 Jun 2013 15:05:58 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 15:06:15 -0000 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] = Sent: maandag 10 juni 2013 16:57 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org; General Area Review Team; Roni Even (ron.even.tlv@gmail.c= om); draft-ietf-avtcore-idms.all@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 5:52 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even = > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > = > Hi Dan, > = > See below... > = > Best regards, > = > Ray > = > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: maandag 10 juni 2013 16:35 > To: Brandenburg, R. (Ray) van > Cc: avt@ietf.org; General Area Review Team; Roni Even = > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > = > = > Yes, we seem to get closer and closer, focus on one last issue (and = > much agreement deleted) > = > Thanks and Regards, > = > Dan > = > = > = > > -----Original Message----- > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > Sent: Monday, June 10, 2013 5:27 PM > > To: Romascanu, Dan (Dan) > > Cc: avt@ietf.org; General Area Review Team; Roni Even = > > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > > > > Hi Dan, > > > > Please see inline. We seem to be converging:) > > > > Ray > = > > > > 7. In Section 8: > > > > > > > > The timestamp is formatted based on the NTP > > > > timestamp format as specified in [RFC5905]. If this field is > > > empty, > > > > then it SHALL be set to 0. This field MAY be left empty if = > > > > none > > or > > > > only one of the receivers reported on presentation timestamps. > > > > > > > > Why a MAY here? Especially for the case when none of the = > > > > receivers reported, what content can be set there but 0 ? > > > > > > > > [Ray: I believe it should be up to the implementation to decide = > > > > how it wants to handle the case of there being only one receiver = > > > > who reported on presentation timestamps]. > > > > > > > [[DR]] OK, so the cases when none of the receivers reported and = > > > one receiver only reported should be dealt with differently. This = > > > needs to be clarified. > > > > > > [Ray] What exactly is the problem with the MAY here? IMO it = > > > doesn't create any interop issues: whatever is the reason for = > > > setting the value to 0, to the client the end result is the same: ign= ore it. > > > > > > > [[DR]] In the case when none of the receivers reported we want to = > > avoid leaving some garbage in this field which could be interpreted = > > differently - don't we? > > > > [Ray] I think I see where we disagree. The paragraph says: "If this = > > field is empty, then it SHALL be set to 0. This field MAY be left = > > empty if none or only one of the receivers reported on presentation = > > timestamps". The way I read this is as: In the case the field is = > > declared empty (=3D contains NULL information), it SHALL be set to 0. > > There can be different reasons for declaring the field empty/NULL, = > > one of those reasons is if none or only one receiver reported on = > > presentation timestamps. To me, the paragraph doesn't say that this = > > is the only possible reason, but it does specify very clearly that = > > if you decide the field should be empty, you SHALL set it to zero. > > > > > = > [[DR]] But then, why do not you take out 'if none or' - because for = > the option of 'none' there is no alternative but the 'null' = > information, and the MAY does not make sense. > = > [Ray] The fact that no receiver reported on the packet presentation = > timestamp does not necessarily mean that the MSAS does not want to = > indicate a proposed packet presentation timestamp. The absence of such = > reports just means that the proposed playout moment might not be = > realistic, or be supported by any receiver. > = [[DR]] yes, but is the field set to anything but 0 in such cases? = [Ray] If the MSAS decides to leave the field empty, it is set to 0 accordin= g to the SHALL. If the MSAS decides to include a timestamp anyway, it is se= t to whatever value the MSAS proposes. = Dan This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From dromasca@avaya.com Mon Jun 10 08:11:40 2013 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 ECE5121F8EAE; Mon, 10 Jun 2013 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 aQfo6EzEssCk; Mon, 10 Jun 2013 08:11:34 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B08C121F8FB6; Mon, 10 Jun 2013 08:11:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFACfstVHGmAcF/2dsb2JhbABagmgheb5CgQQWdIIjAQEBAQMSKD8MBAIBCA0EBAEBCxQJByERFAkIAgQOBQgah1kDDwGdUJMLDYg7F4xbgiwxBwaCeWEDlVgBiCmFXIUkgw+CJw X-IronPort-AV: E=Sophos;i="4.87,837,1363147200"; d="scan'208";a="12527806" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2013 11:11:32 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2013 11:10:03 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 17:11:30 +0200 From: "Romascanu, Dan (Dan)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQAAAZQ1gAAAuajA= Date: Mon, 10 Jun 2013 15:11:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA199F21@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 15:11:41 -0000 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 6:06 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: maandag 10 juni 2013 16:57 > To: Brandenburg, R. (Ray) van > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > Sent: Monday, June 10, 2013 5:52 PM > > To: Romascanu, Dan (Dan) > > Cc: avt@ietf.org; General Area Review Team; Roni Even > > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > > > > Hi Dan, > > > > See below... > > > > Best regards, > > > > Ray > > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: maandag 10 juni 2013 16:35 > > To: Brandenburg, R. (Ray) van > > Cc: avt@ietf.org; General Area Review Team; Roni Even > > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > > > > > > Yes, we seem to get closer and closer, focus on one last issue (and > > much agreement deleted) > > > > Thanks and Regards, > > > > Dan > > > > > > > > > -----Original Message----- > > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > > Sent: Monday, June 10, 2013 5:27 PM > > > To: Romascanu, Dan (Dan) > > > Cc: avt@ietf.org; General Area Review Team; Roni Even > > > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > > > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > > > > > > Hi Dan, > > > > > > Please see inline. We seem to be converging:) > > > > > > Ray > > > > > > > 7. In Section 8: > > > > > > > > > > The timestamp is formatted based on the NTP > > > > > timestamp format as specified in [RFC5905]. If this field is > > > > empty, > > > > > then it SHALL be set to 0. This field MAY be left empty if > > > > > none > > > or > > > > > only one of the receivers reported on presentation > timestamps. > > > > > > > > > > Why a MAY here? Especially for the case when none of the > > > > > receivers reported, what content can be set there but 0 ? > > > > > > > > > > [Ray: I believe it should be up to the implementation to decide > > > > > how it wants to handle the case of there being only one receiver > > > > > who reported on presentation timestamps]. > > > > > > > > > [[DR]] OK, so the cases when none of the receivers reported and > > > > one receiver only reported should be dealt with differently. This > > > > needs to be clarified. > > > > > > > > [Ray] What exactly is the problem with the MAY here? IMO it > > > > doesn't create any interop issues: whatever is the reason for > > > > setting the value to 0, to the client the end result is the same: > ignore it. > > > > > > > > > > [[DR]] In the case when none of the receivers reported we want to > > > avoid leaving some garbage in this field which could be interpreted > > > differently - don't we? > > > > > > [Ray] I think I see where we disagree. The paragraph says: "If this > > > field is empty, then it SHALL be set to 0. This field MAY be left > > > empty if none or only one of the receivers reported on presentation > > > timestamps". The way I read this is as: In the case the field is > > > declared empty (=3D contains NULL information), it SHALL be set to 0. > > > There can be different reasons for declaring the field empty/NULL, > > > one of those reasons is if none or only one receiver reported on > > > presentation timestamps. To me, the paragraph doesn't say that this > > > is the only possible reason, but it does specify very clearly that > > > if you decide the field should be empty, you SHALL set it to zero. > > > > > > > > > > [[DR]] But then, why do not you take out 'if none or' - because for > > the option of 'none' there is no alternative but the 'null' > > information, and the MAY does not make sense. > > > > [Ray] The fact that no receiver reported on the packet presentation > > timestamp does not necessarily mean that the MSAS does not want to > > indicate a proposed packet presentation timestamp. The absence of such > > reports just means that the proposed playout moment might not be > > realistic, or be supported by any receiver. > > >=20 > [[DR]] yes, but is the field set to anything but 0 in such cases? >=20 > [Ray] If the MSAS decides to leave the field empty, it is set to 0 > according to the SHALL. If the MSAS decides to include a timestamp > anyway, it is set to whatever value the MSAS proposes. >=20 [[DR]] So two different implementations may behave differently in similar s= ituations. Is this a problem?=20 Dan From ray.vanbrandenburg@tno.nl Mon Jun 10 09:19:07 2013 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 35DB821F9649; Mon, 10 Jun 2013 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 UbW-mHh3OHXI; Mon, 10 Jun 2013 09:19:02 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE621F93D4; Mon, 10 Jun 2013 09:19:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,838,1363129200"; d="scan'208";a="9673876" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 10 Jun 2013 18:18:46 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 18:18:46 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQAAAZQ1gAAAuajAAAmW0KA== Date: Mon, 10 Jun 2013 16:18:44 +0000 Message-ID: <3DFD3155-BBD9-4BE0-8912-81B92C93D3CB@tno.nl> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> , <9904FB1B0159DA42B0B887B7FA8119CA199F21@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199F21@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 16:19:07 -0000 On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" wrot= e: > = > = > = > = >> -----Original Message----- >> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >> Sent: Monday, June 10, 2013 6:06 PM >> To: Romascanu, Dan (Dan) >> Cc: avt@ietf.org; General Area Review Team; Roni Even >> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >> = >> = >> = >> -----Original Message----- >> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >> Sent: maandag 10 juni 2013 16:57 >> To: Brandenburg, R. (Ray) van >> Cc: avt@ietf.org; General Area Review Team; Roni Even >> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >> = >> = >> = >> = >> = >>> -----Original Message----- >>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>> Sent: Monday, June 10, 2013 5:52 PM >>> To: Romascanu, Dan (Dan) >>> Cc: avt@ietf.org; General Area Review Team; Roni Even >>> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >>> = >>> Hi Dan, >>> = >>> See below... >>> = >>> Best regards, >>> = >>> Ray >>> = >>> -----Original Message----- >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>> Sent: maandag 10 juni 2013 16:35 >>> To: Brandenburg, R. (Ray) van >>> Cc: avt@ietf.org; General Area Review Team; Roni Even >>> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >>> = >>> = >>> Yes, we seem to get closer and closer, focus on one last issue (and >>> much agreement deleted) >>> = >>> Thanks and Regards, >>> = >>> Dan >>> = >>> = >>> = >>>> -----Original Message----- >>>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Sent: Monday, June 10, 2013 5:27 PM >>>> To: Romascanu, Dan (Dan) >>>> Cc: avt@ietf.org; General Area Review Team; Roni Even >>>> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org >>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >>>> = >>>> Hi Dan, >>>> = >>>> Please see inline. We seem to be converging:) >>>> = >>>> Ray >>> = >>>>>> 7. In Section 8: >>>>>> = >>>>>> The timestamp is formatted based on the NTP >>>>>> timestamp format as specified in [RFC5905]. If this field is >>>>> empty, >>>>>> then it SHALL be set to 0. This field MAY be left empty if >>>>>> none >>>> or >>>>>> only one of the receivers reported on presentation >> timestamps. >>>>>> = >>>>>> Why a MAY here? Especially for the case when none of the >>>>>> receivers reported, what content can be set there but 0 ? >>>>>> = >>>>>> [Ray: I believe it should be up to the implementation to decide >>>>>> how it wants to handle the case of there being only one receiver >>>>>> who reported on presentation timestamps]. >>>>>> = >>>>> [[DR]] OK, so the cases when none of the receivers reported and >>>>> one receiver only reported should be dealt with differently. This >>>>> needs to be clarified. >>>>> = >>>>> [Ray] What exactly is the problem with the MAY here? IMO it >>>>> doesn't create any interop issues: whatever is the reason for >>>>> setting the value to 0, to the client the end result is the same: >> ignore it. >>>>> = >>>> = >>>> [[DR]] In the case when none of the receivers reported we want to >>>> avoid leaving some garbage in this field which could be interpreted >>>> differently - don't we? >>>> = >>>> [Ray] I think I see where we disagree. The paragraph says: "If this >>>> field is empty, then it SHALL be set to 0. This field MAY be left >>>> empty if none or only one of the receivers reported on presentation >>>> timestamps". The way I read this is as: In the case the field is >>>> declared empty (=3D contains NULL information), it SHALL be set to 0. >>>> There can be different reasons for declaring the field empty/NULL, >>>> one of those reasons is if none or only one receiver reported on >>>> presentation timestamps. To me, the paragraph doesn't say that this >>>> is the only possible reason, but it does specify very clearly that >>>> if you decide the field should be empty, you SHALL set it to zero. >>>> = >>>> = >>> = >>> [[DR]] But then, why do not you take out 'if none or' - because for >>> the option of 'none' there is no alternative but the 'null' >>> information, and the MAY does not make sense. >>> = >>> [Ray] The fact that no receiver reported on the packet presentation >>> timestamp does not necessarily mean that the MSAS does not want to >>> indicate a proposed packet presentation timestamp. The absence of such >>> reports just means that the proposed playout moment might not be >>> realistic, or be supported by any receiver. >>> = >> = >> [[DR]] yes, but is the field set to anything but 0 in such cases? >> = >> [Ray] If the MSAS decides to leave the field empty, it is set to 0 >> according to the SHALL. If the MSAS decides to include a timestamp >> anyway, it is set to whatever value the MSAS proposes. >> = > = > [[DR]] So two different implementations may behave differently in similar= situations. Is this a problem? = > = No, I don't think it is a problem if two different MSAS implementations beh= ave differently in this regard. I see it as server-side configuration. Anyw= ay, even if we would replace the MAY with a SHOULD or remove the sentence a= ll together, there would still be different implementations: for example, l= et's say we have a sync group of 12 devices, with 7 of them reporting prese= ntation timestamps. What should the MSAS do? Set the field in the IDMS Sett= ings Packet to 0 or not? I feel this decision should be up to the implement= ation as I don't see an advantage to us specifying either one way or the ot= her. = Ray > Dan > = This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From dromasca@avaya.com Mon Jun 10 10:00:09 2013 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 11FEE21F8EF2; Mon, 10 Jun 2013 10:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 fooV8Ntl3C2k; Mon, 10 Jun 2013 10:00:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2C38121F9750; Mon, 10 Jun 2013 10:00:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlHGmAcF/2dsb2JhbABQgmUhwX6BBxZ0gh8BAQEBAxIoPwwEAgEIDQQEAQEBChQJByERFAkIAgQOBQgah2ADDwGgR5M5DYlGF4xDgiImCwcGglphA5UeAYgKhUyFHIMLgig X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="14969589" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jun 2013 13:00:01 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2013 12:58:31 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 18:59:59 +0200 From: "Romascanu, Dan (Dan)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQAAAZQ1gAAAuajAAAmW0KAAAUNTw Date: Mon, 10 Jun 2013 16:59:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA19A0A6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> , <9904FB1B0159DA42B0B887B7FA8119CA199F21@AZ-FFEXMB04.global.avaya.com> <3DFD3155-BBD9-4BE0-8912-81B92C93D3CB@tno.nl> In-Reply-To: <3DFD3155-BBD9-4BE0-8912-81B92C93D3CB@tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 10 Jun 2013 17:00:09 -0000 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 7:19 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: Re: Gen-ART review of draft-ietf-avtcore-idms-09 >=20 >=20 >=20 > On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" > wrote: >=20 > > > > > > > > > >> -----Original Message----- > >> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Sent: Monday, June 10, 2013 6:06 PM > >> To: Romascanu, Dan (Dan) > >> Cc: avt@ietf.org; General Area Review Team; Roni Even > >> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >> > >> > >> > >> -----Original Message----- > >> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >> Sent: maandag 10 juni 2013 16:57 > >> To: Brandenburg, R. (Ray) van > >> Cc: avt@ietf.org; General Area Review Team; Roni Even > >> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >>> Sent: Monday, June 10, 2013 5:52 PM > >>> To: Romascanu, Dan (Dan) > >>> Cc: avt@ietf.org; General Area Review Team; Roni Even > >>> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >>> > >>> Hi Dan, > >>> > >>> See below... > >>> > >>> Best regards, > >>> > >>> Ray > >>> > >>> -----Original Message----- > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >>> Sent: maandag 10 juni 2013 16:35 > >>> To: Brandenburg, R. (Ray) van > >>> Cc: avt@ietf.org; General Area Review Team; Roni Even > >>> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >>> > >>> > >>> Yes, we seem to get closer and closer, focus on one last issue (and > >>> much agreement deleted) > >>> > >>> Thanks and Regards, > >>> > >>> Dan > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >>>> Sent: Monday, June 10, 2013 5:27 PM > >>>> To: Romascanu, Dan (Dan) > >>>> Cc: avt@ietf.org; General Area Review Team; Roni Even > >>>> (ron.even.tlv@gmail.com); > >>>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >>>> > >>>> Hi Dan, > >>>> > >>>> Please see inline. We seem to be converging:) > >>>> > >>>> Ray > >>> > >>>>>> 7. In Section 8: > >>>>>> > >>>>>> The timestamp is formatted based on the NTP > >>>>>> timestamp format as specified in [RFC5905]. If this field is > >>>>> empty, > >>>>>> then it SHALL be set to 0. This field MAY be left empty if > >>>>>> none > >>>> or > >>>>>> only one of the receivers reported on presentation > >> timestamps. > >>>>>> > >>>>>> Why a MAY here? Especially for the case when none of the > >>>>>> receivers reported, what content can be set there but 0 ? > >>>>>> > >>>>>> [Ray: I believe it should be up to the implementation to decide > >>>>>> how it wants to handle the case of there being only one receiver > >>>>>> who reported on presentation timestamps]. > >>>>>> > >>>>> [[DR]] OK, so the cases when none of the receivers reported and > >>>>> one receiver only reported should be dealt with differently. This > >>>>> needs to be clarified. > >>>>> > >>>>> [Ray] What exactly is the problem with the MAY here? IMO it > >>>>> doesn't create any interop issues: whatever is the reason for > >>>>> setting the value to 0, to the client the end result is the same: > >> ignore it. > >>>>> > >>>> > >>>> [[DR]] In the case when none of the receivers reported we want to > >>>> avoid leaving some garbage in this field which could be interpreted > >>>> differently - don't we? > >>>> > >>>> [Ray] I think I see where we disagree. The paragraph says: "If this > >>>> field is empty, then it SHALL be set to 0. This field MAY be left > >>>> empty if none or only one of the receivers reported on presentation > >>>> timestamps". The way I read this is as: In the case the field is > >>>> declared empty (=3D contains NULL information), it SHALL be set to 0= . > >>>> There can be different reasons for declaring the field empty/NULL, > >>>> one of those reasons is if none or only one receiver reported on > >>>> presentation timestamps. To me, the paragraph doesn't say that this > >>>> is the only possible reason, but it does specify very clearly that > >>>> if you decide the field should be empty, you SHALL set it to zero. > >>>> > >>>> > >>> > >>> [[DR]] But then, why do not you take out 'if none or' - because for > >>> the option of 'none' there is no alternative but the 'null' > >>> information, and the MAY does not make sense. > >>> > >>> [Ray] The fact that no receiver reported on the packet presentation > >>> timestamp does not necessarily mean that the MSAS does not want to > >>> indicate a proposed packet presentation timestamp. The absence of > >>> such reports just means that the proposed playout moment might not > >>> be realistic, or be supported by any receiver. > >>> > >> > >> [[DR]] yes, but is the field set to anything but 0 in such cases? > >> > >> [Ray] If the MSAS decides to leave the field empty, it is set to 0 > >> according to the SHALL. If the MSAS decides to include a timestamp > >> anyway, it is set to whatever value the MSAS proposes. > >> > > > > [[DR]] So two different implementations may behave differently in > similar situations. Is this a problem? > > >=20 > No, I don't think it is a problem if two different MSAS implementations > behave differently in this regard. I see it as server-side > configuration. Anyway, even if we would replace the MAY with a SHOULD or > remove the sentence all together, there would still be different > implementations: for example, let's say we have a sync group of 12 > devices, with 7 of them reporting presentation timestamps. What should > the MSAS do? Set the field in the IDMS Settings Packet to 0 or not? I > feel this decision should be up to the implementation as I don't see an > advantage to us specifying either one way or the other. >=20 > Ray >=20 [[DR]] The open issue is not about this case but about the case when no rec= eiver reported. You say one MSAS implementation may treat this as null info= rmation setting the field to 0 (which would seem to me like the obvious thi= ng to do), but other MSAS implementation may include a timestamp anyway (wh= ich one?). My question 'Is this a problem' was about this case?=20 Dan From kevin.gross@avanw.com Mon Jun 10 12:39:51 2013 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 99E1E21F9AA4 for ; Mon, 10 Jun 2013 12:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] 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 ZyiWQ7RqYox2 for ; Mon, 10 Jun 2013 12:39:47 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 21ED621F9A48 for ; Mon, 10 Jun 2013 12:39:42 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta03.emeryville.ca.mail.comcast.net with comcast id mfZL1l0021GXsucA3jfioc; Mon, 10 Jun 2013 19:39:42 +0000 Received: from mail-ie0-x22c.google.com ([IPv6:2607:f8b0:4001:c03::22c]) by omta07.emeryville.ca.mail.comcast.net with comcast id mjfh1l00a195Pdh8UjfiXK; Mon, 10 Jun 2013 19:39:42 +0000 Received: by mail-ie0-f172.google.com with SMTP id 17so17475161iea.17 for ; Mon, 10 Jun 2013 12:39:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0CBzSjZRompoHUWM8A0lJmrM+/mr2laBMe7+OsABL3k=; b=MC4GAN0F2DLMf1Jg7OS5efnQkqA3GW/vetDp5mFwtbd9W1z/DzmA80e+NOpoE7RfPO SQpAOC57uq+GzKtQgTAO3g07x3Lh4RVIDol3tWt1CEFC+x4njrFaa+V3VX6DLvhClzUr Q4A6cIWSCKfzKOSv72dlvvwBBGje3nLhMOntBOXxAEW1opffleOBwUC2kKO2ralpQ2c2 skHKuIvRwrMYJXllaEC4jSd2mspmOSDGnbzxoR7t6N0M6c0Ithb3F8anRie5mUXMhpOY bIG+HtNA/dGmyFNRBMvx593EPikLhSKZGh0LrMn9c9z0NFG+nwaoJ3tqASSuH7j5aa5o Pqeg== MIME-Version: 1.0 X-Received: by 10.50.114.131 with SMTP id jg3mr4840390igb.75.1370893181837; Mon, 10 Jun 2013 12:39:41 -0700 (PDT) Received: by 10.50.149.199 with HTTP; Mon, 10 Jun 2013 12:39:41 -0700 (PDT) In-Reply-To: <51659559.8060901@xiph.org> References: <20130410162949.28228.61181.idtracker@ietfa.amsl.com> <51659559.8060901@xiph.org> Date: Mon, 10 Jun 2013 13:39:41 -0600 Message-ID: From: Kevin Gross To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=089e0122ac4c20eb5504ded1f15d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370893182; bh=0CBzSjZRompoHUWM8A0lJmrM+/mr2laBMe7+OsABL3k=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=bDuOk9w3H+vOocR845NNAf+/Xh184ErPhiyHWgvVPQacVpF7VAKScrrvTxeCJyMDY hm4vDxbJvGxao18XGoZgZuZwRu7IqNei/eikHXBMi4W2IlDY6hR6n3YI/6dAmSxkes +Jgo/5PQ/JgE6nH0TEcxFnDWjaKf07HbigIc5YCeDgcVmU6vXqrEhdLDdKdMDvSF6m YiRbETBvZgeM0lpZFQ2MnSD87u1RwPf3QP2L1xahV98X8lPtqW6LOwhYhdIirD2IFT qAIQDQeI+4Zub6LsC3Gwg9LSuRBcsAIquFlEbxy1DJEC/NOlHjs2PX6Vg2yOwnf4vp D2Y3bg1mqMc+w== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.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, 10 Jun 2013 19:39:51 -0000 --089e0122ac4c20eb5504ded1f15d Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this and it looks good to me. I had to do a bit of digging to even find out what DVI4 was so removing it looks like removing is a good idea. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Apr 10, 2013 at 10:37 AM, Timothy B. Terriberry wrote: > internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/**doc/draft-ietf-avtcore-avp-**codecs >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/**draft-ietf-avtcore-avp-codecs-**02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?**url2=draft-ietf-avtcore-avp-**codecs-02 >> > > Changelog for this version: > > - Updated profile names to include the "RTP/" prefix. > > - Expanded the references in the abstract into document titles, and added > a sentence to the introduce to actually reference the relevant RFCs. > > - Used Magnus's proposal for describing the text updates. > > - Used Keith's proposed text: "Some environments REQUIRE support for PCMU" > (without including an "only"). > > > I did not change anything with respect to PCMA, as I could detect no clear > consensus on the topic. We have one person arguing that neither PCMU nor > PCMA should be SHOULD requirements, but I think that's a big enough change > that more than one person should advocate for it before we make it > (especially considering that PCMU was recently made a MUST for WebRTC). > > If I missed any other comments, please let me know! > > ______________________________**_________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/**listinfo/avt > --089e0122ac4c20eb5504ded1f15d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this and it looks good to me. I had to do = a bit of digging to even find out what DVI4 was so removing it looks like r= emoving is a good idea.

<= div> Kevin Gross
+1-303-447-0517
Media Network Consultant
<= div>AVA Networks -=A0ww= w.AVAnw.com,=A0www.X1= 92.org


On Wed, Apr 10, 2013 at 10:37 AM, Timoth= y B. Terriberry <tterribe@xiph.org> wrote:
internet-draf= ts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcor= e-avp-codecs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-avp-cod= ecs-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -avtcore-avp-codecs-02

Changelog for this version:

- Updated profile names to include the "RTP/" prefix.

- Expanded the references in the abstract into document titles, and added a= sentence to the introduce to actually reference the relevant RFCs.

- Used Magnus's proposal for describing the text updates.

- Used Keith's proposed text: "Some environments REQUIRE support f= or PCMU" (without including an "only").


I did not change anything with respect to PCMA, as I could detect no clear = consensus on the topic. We have one person arguing that neither PCMU nor PC= MA should be SHOULD requirements, but I think that's a big enough chang= e that more than one person should advocate for it before we make it (espec= ially considering that PCMU was recently made a MUST for WebRTC).

If I missed any other comments, please let me know!

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

--089e0122ac4c20eb5504ded1f15d-- From gabor.somogyi@nsn.com Tue Jun 11 02:27:59 2013 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 F07C721F960F for ; Tue, 11 Jun 2013 02:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BRKdbac-M6pt for ; Tue, 11 Jun 2013 02:27:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 78C1021F9607 for ; Tue, 11 Jun 2013 02:27:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5B9RjEn017591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 11:27:45 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5B9RiVY007168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 11:27:45 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Jun 2013 11:27:44 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.149]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 11:27:44 +0200 From: "Somogyi, Gabor (NSN - HU/Budapest)" To: ext Kevin Gross , "Timothy B. Terriberry" , "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.txt Thread-Index: AQHOZhJLbiToFq+d4kOvLTSkFurP/JkwJVRA Date: Tue, 11 Jun 2013 09:27:44 +0000 Message-ID: References: <20130410162949.28228.61181.idtracker@ietfa.amsl.com> <51659559.8060901@xiph.org> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: multipart/alternative; boundary="_000_BB7768BF2D4BB94B8473C8E77C07857B0657A2DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13784 X-purgate-ID: 151667::1370942866-000017BA-12BD36CB/0-0/0-0 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.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, 11 Jun 2013 09:28:00 -0000 --_000_BB7768BF2D4BB94B8473C8E77C07857B0657A2DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > We have one person arguing that neither PCMU nor PCMA should > be SHOULD requirements, but I think that's a big enough change > that more than one person should advocate for it before we make it For 17+ years IETF RFCs (1890, 3551) recommend PCMU and DVI4. If DVI4 faded= away, it may make sense to update the RFC. While PCMU may have gained grou= nd outside of its traditional home. It is nice to have a common encoding su= pported globally. > especially considering that PCMU was recently made a MUST for WebRTC While on trunk side ITU-T Q.1912.5 says that either PCMA only or both PCMU and PCMA shall be sent in SDP off= er. 3GPP TS 26.103 state= s that supporting both PCMA and PCMU is mandatory for SIP-I CS CN. And NICC= ND1701 and ND1704 state that PCMA shall be supported. Just to name a fe= w standards. > "Some environments REQUIRE support for PCMU." That is true. The same applies to PCMA. And AMR/8000 in certain mobile netw= orks. And I may create a system for my dogs where BARK/32000 will be REQUIR= ED :-) Sorry for the joke, but I wanted to point out that I do not see (per= sonal opinion) the value of the sentence quoted. BR, Gabor Somogyi From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of ext K= evin Gross Sent: Monday, June 10, 2013 9:40 PM To: Timothy B. Terriberry Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.txt I have reviewed this and it looks good to me. I had to do a bit of digging = to even find out what DVI4 was so removing it looks like removing is a good= idea. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com, www.X192.org On Wed, Apr 10, 2013 at 10:37 AM, Timothy B. Terriberry > wrote: internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-avp-codecs-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-avp-codecs-02 Changelog for this version: - Updated profile names to include the "RTP/" prefix. - Expanded the references in the abstract into document titles, and added a= sentence to the introduce to actually reference the relevant RFCs. - Used Magnus's proposal for describing the text updates. - Used Keith's proposed text: "Some environments REQUIRE support for PCMU" = (without including an "only"). I did not change anything with respect to PCMA, as I could detect no clear = consensus on the topic. We have one person arguing that neither PCMU nor PC= MA should be SHOULD requirements, but I think that's a big enough change th= at more than one person should advocate for it before we make it (especiall= y considering that PCMU was recently made a MUST for WebRTC). If I missed any other comments, please let me know! _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_BB7768BF2D4BB94B8473C8E77C07857B0657A2DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> We have one person arguing that neither PCMU no= r PCMA should

> be SHOULD requirements, but I think that's a bi= g enough change

> that more than one person should advocate for i= t before we make it

 

For 17+ years IETF RFCs (1890, 3551= ) recommend PCMU and DVI4. If DVI4 faded away, it may make sense to update = the RFC. While PCMU may have gained ground outside of its traditional home. It is nice to have a common encoding supported globally.<= /span>

 

> especially considering that PCMU was recently made a MUST for WebRTC=

 

While on trunk side ITU-T Q.1912.5 say= s that either PCMA only or both PCMU and PCMA shall be sent in SDP offer. 3GPP TS 26.10= 3 states that supporting both PCMA and PCMU is mandatory for SIP-I CS C= N. And NICC ND1701 and ND1704 state that PCMA shall be supported. Just to name a few standards= .

 

> "Some environments REQUIRE support for PCMU."

 

That is true. The same applies to PCMA.= And AMR/8000 in certain mobile networks. And I may create a system for my = dogs where BARK/32000 will be REQUIRED :-) Sorry for the joke, but I wanted to point out that I do not see (personal opinion) the v= alue of the sentence quoted.

 

BR,

Gabor Somogyi

 

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of ext Kevin Gross
Sent: Monday, June 10, 2013 9:40 PM
To: Timothy B. Terriberry
Cc: avt@ietf.org
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.= txt

 

I have reviewed this and it looks good to me. I had = to do a bit of digging to even find out what DVI4 was so removing it looks = like removing is a good idea.


Kevin Gross

+1-303-447-0517

Media Network Consultant

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

 

On Wed, Apr 10, 2013 at 10:37 AM, Timothy B. Terribe= rry <tterribe@xip= h.org> wrote:

internet-drafts@ietf.org wrote:

A New Internet-Draft = is available from the on-line Internet-Drafts directories.


Changelog for this version:

- Updated profile names to include the "RTP/" prefix.

- Expanded the references in the abstract into document titles, and added a= sentence to the introduce to actually reference the relevant RFCs.

- Used Magnus's proposal for describing the text updates.

- Used Keith's proposed text: "Some environments REQUIRE support for P= CMU" (without including an "only").


I did not change anything with respect to PCMA, as I could detect no clear = consensus on the topic. We have one person arguing that neither PCMU nor PC= MA should be SHOULD requirements, but I think that's a big enough change th= at more than one person should advocate for it before we make it (especially considering that PCMU was recently ma= de a MUST for WebRTC).

If I missed any other comments, please let me know!


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

 

--_000_BB7768BF2D4BB94B8473C8E77C07857B0657A2DEMUMBX005nsnintr_-- From ray.vanbrandenburg@tno.nl Tue Jun 11 03:30:13 2013 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 DA9EE21F9425; Tue, 11 Jun 2013 03:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 rhKpNXonZnqL; Tue, 11 Jun 2013 03:30:08 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF07821F9433; Tue, 11 Jun 2013 03:30:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,844,1363129200"; d="scan'208";a="9709115" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 11 Jun 2013 12:29:56 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 12:29:56 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQAAAZQ1gAAAuajAAAmW0KAAAUNTwACTzZ6A= Date: Tue, 11 Jun 2013 10:29:55 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> , <9904FB1B0159DA42B0B887B7FA8119CA199F21@AZ-FFEXMB04.global.avaya.com> <3DFD3155-BBD9-4BE0-8912-81B92C93D3CB@tno.nl> <9904FB1B0159DA42B0B887B7FA8119CA19A0A6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA19A0A6@AZ-FFEXMB04.global.avaya.com> 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 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, 11 Jun 2013 10:30:14 -0000 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] = Sent: maandag 10 juni 2013 19:00 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org; General Area Review Team; Roni Even (ron.even.tlv@gmail.c= om); draft-ietf-avtcore-idms.all@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 7:19 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even = > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: Re: Gen-ART review of draft-ietf-avtcore-idms-09 > = > = > = > On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" > wrote: > = > > > > > > > > > >> -----Original Message----- > >> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Sent: Monday, June 10, 2013 6:06 PM > >> To: Romascanu, Dan (Dan) > >> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >> (ron.even.tlv@gmail.com); = > >> draft-ietf-avtcore-idms.all@tools.ietf.org > >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >> > >> > >> > >> -----Original Message----- > >> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >> Sent: maandag 10 juni 2013 16:57 > >> To: Brandenburg, R. (Ray) van > >> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >> (ron.even.tlv@gmail.com); = > >> draft-ietf-avtcore-idms.all@tools.ietf.org > >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >>> Sent: Monday, June 10, 2013 5:52 PM > >>> To: Romascanu, Dan (Dan) > >>> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >>> (ron.even.tlv@gmail.com); = > >>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >>> > >>> Hi Dan, > >>> > >>> See below... > >>> > >>> Best regards, > >>> > >>> Ray > >>> > >>> -----Original Message----- > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >>> Sent: maandag 10 juni 2013 16:35 > >>> To: Brandenburg, R. (Ray) van > >>> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >>> (ron.even.tlv@gmail.com); = > >>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >>> > >>> > >>> Yes, we seem to get closer and closer, focus on one last issue = > >>> (and much agreement deleted) > >>> > >>> Thanks and Regards, > >>> > >>> Dan > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Brandenburg, R. (Ray) van = > >>>> [mailto:ray.vanbrandenburg@tno.nl] > >>>> Sent: Monday, June 10, 2013 5:27 PM > >>>> To: Romascanu, Dan (Dan) > >>>> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >>>> (ron.even.tlv@gmail.com); = > >>>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >>>> > >>>> Hi Dan, > >>>> > >>>> Please see inline. We seem to be converging:) > >>>> > >>>> Ray > >>> > >>>>>> 7. In Section 8: > >>>>>> > >>>>>> The timestamp is formatted based on the NTP > >>>>>> timestamp format as specified in [RFC5905]. If this field is > >>>>> empty, > >>>>>> then it SHALL be set to 0. This field MAY be left empty if = > >>>>>> none > >>>> or > >>>>>> only one of the receivers reported on presentation > >> timestamps. > >>>>>> > >>>>>> Why a MAY here? Especially for the case when none of the = > >>>>>> receivers reported, what content can be set there but 0 ? > >>>>>> > >>>>>> [Ray: I believe it should be up to the implementation to decide = > >>>>>> how it wants to handle the case of there being only one = > >>>>>> receiver who reported on presentation timestamps]. > >>>>>> > >>>>> [[DR]] OK, so the cases when none of the receivers reported and = > >>>>> one receiver only reported should be dealt with differently. = > >>>>> This needs to be clarified. > >>>>> > >>>>> [Ray] What exactly is the problem with the MAY here? IMO it = > >>>>> doesn't create any interop issues: whatever is the reason for = > >>>>> setting the value to 0, to the client the end result is the same: > >> ignore it. > >>>>> > >>>> > >>>> [[DR]] In the case when none of the receivers reported we want to = > >>>> avoid leaving some garbage in this field which could be = > >>>> interpreted differently - don't we? > >>>> > >>>> [Ray] I think I see where we disagree. The paragraph says: "If = > >>>> this field is empty, then it SHALL be set to 0. This field MAY be = > >>>> left empty if none or only one of the receivers reported on = > >>>> presentation timestamps". The way I read this is as: In the case = > >>>> the field is declared empty (=3D contains NULL information), it SHAL= L be set to 0. > >>>> There can be different reasons for declaring the field = > >>>> empty/NULL, one of those reasons is if none or only one receiver = > >>>> reported on presentation timestamps. To me, the paragraph doesn't = > >>>> say that this is the only possible reason, but it does specify = > >>>> very clearly that if you decide the field should be empty, you SHALL= set it to zero. > >>>> > >>>> > >>> > >>> [[DR]] But then, why do not you take out 'if none or' - because = > >>> for the option of 'none' there is no alternative but the 'null' > >>> information, and the MAY does not make sense. > >>> > >>> [Ray] The fact that no receiver reported on the packet = > >>> presentation timestamp does not necessarily mean that the MSAS = > >>> does not want to indicate a proposed packet presentation = > >>> timestamp. The absence of such reports just means that the = > >>> proposed playout moment might not be realistic, or be supported by an= y receiver. > >>> > >> > >> [[DR]] yes, but is the field set to anything but 0 in such cases? > >> > >> [Ray] If the MSAS decides to leave the field empty, it is set to 0 = > >> according to the SHALL. If the MSAS decides to include a timestamp = > >> anyway, it is set to whatever value the MSAS proposes. > >> > > > > [[DR]] So two different implementations may behave differently in > similar situations. Is this a problem? > > > = > No, I don't think it is a problem if two different MSAS = > implementations behave differently in this regard. I see it as = > server-side configuration. Anyway, even if we would replace the MAY = > with a SHOULD or remove the sentence all together, there would still = > be different > implementations: for example, let's say we have a sync group of 12 = > devices, with 7 of them reporting presentation timestamps. What should = > the MSAS do? Set the field in the IDMS Settings Packet to 0 or not? I = > feel this decision should be up to the implementation as I don't see = > an advantage to us specifying either one way or the other. > = > Ray > = [[DR]] The open issue is not about this case but about the case when no rec= eiver reported. You say one MSAS implementation may treat this as null info= rmation setting the field to 0 (which would seem to me like the obvious thi= ng to do), but other MSAS implementation may include a timestamp anyway (wh= ich one?). My question 'Is this a problem' was about this case? = [Ray] I don't see a difference between the two cases: in both cases the MSA= S can decide to send 'some' timestamp. I'm not saying this is recommended,= but I also don't see any interop issues. In any synchronization group ther= e will be a maximum of 1 MSAS, so all receivers will receive the same prese= ntation timestamp. What they do with that timestamp is up to the SCs themse= lves. = Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From kevin.gross@avanw.com Tue Jun 11 06:30:20 2013 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 50F9E21F949D for ; Tue, 11 Jun 2013 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.503 X-Spam-Level: X-Spam-Status: No, score=0.503 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 soAGMnTE1c4c for ; Tue, 11 Jun 2013 06:30:16 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 8552221F8EBE for ; Tue, 11 Jun 2013 06:30:16 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta12.emeryville.ca.mail.comcast.net with comcast id n0l41l00116AWCU011WGzg; Tue, 11 Jun 2013 13:30:16 +0000 Received: from mail-ie0-x230.google.com ([IPv6:2607:f8b0:4001:c03::230]) by omta06.emeryville.ca.mail.comcast.net with comcast id n1WF1l0094xlzhT8S1WF92; Tue, 11 Jun 2013 13:30:16 +0000 Received: by mail-ie0-f176.google.com with SMTP id ar20so17194206iec.21 for ; Tue, 11 Jun 2013 06:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sydfQlGbnylY3z5dug8+qnSNBlMPjdCwbFV2g9il4C8=; b=IzsERq/z7u1vsPkNmZN69f/7JyFMVmghkHdwct7ehSqEvL4eCMOc7JD28C8ip8voP/ SJhsK9nxfSAp+h565v+zSpWeOEXfWyz63VdaG3ZHsVbXkT/HOjSBzTM6QBMMV7S65Tor 6RGYTkXcJfcGLE6ZvE7LF/YFZbGyDtfze+TaKvIppnoIHDwQBVGMoGq1i1jwwlBAkerg iCYWNCgJfqVEEomxb6osiyeiDw1jqTuAWcOGTT/A5rgdHzD9KKyVsOR5PcWgyW5HqWIx I+bWMrRViIPFOydErgQ1P9LF3fJcJJJzSLKGWY7wZILDNzJGOAlV8emb9KtPGDp+htkc scgw== MIME-Version: 1.0 X-Received: by 10.50.136.168 with SMTP id qb8mr971624igb.5.1370957415385; Tue, 11 Jun 2013 06:30:15 -0700 (PDT) Received: by 10.50.149.199 with HTTP; Tue, 11 Jun 2013 06:30:15 -0700 (PDT) In-Reply-To: References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> Date: Tue, 11 Jun 2013 07:30:15 -0600 Message-ID: From: Kevin Gross To: Colin Perkins Content-Type: multipart/alternative; boundary=089e0149495ebf11ca04dee0e527 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370957416; bh=sydfQlGbnylY3z5dug8+qnSNBlMPjdCwbFV2g9il4C8=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=U9E4SDPfpDdjWMmipBgqwspfnXvm56MMqxcRUMV0dj3ycjmay+fFlQ0H7o0jWP/sL AEGLLTXtZrNmy+ZBALuYWHHOdxf+crK9WLhKbORaza6LtVJ5+QBvk2RUuhyhBaZ5uO KsscpEfUcCgiofCSyREcF8y8oYK7suBLdc0nM6lw23F0ZihquTmD0BsNn8rYQ5jNJA dh4diNgezu7ezUS7Xlnfyr0Q3RH2++XcYxf5KIkH/Rpl1Bd2dY1dy3F7L8B8KgRU9D uvG7609hN2wUOwnkyf3a7VylhIxOGZIN1P2EGyXxoahXSPMYRqNS4aaIEajDEm4off eES0B98UL0MUw== Cc: mmusic , "avt@ietf.org" , "draft-ietf-avtcore-clksrc@tools.ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 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, 11 Jun 2013 13:30:20 -0000 --089e0149495ebf11ca04dee0e527 Content-Type: text/plain; charset=ISO-8859-1 I've read section 12.2 of RFC 5576 and it is unclear to me whether a properly-registered attribute also requires a separate registration to be used as a source-level attribute. I gather there's some uncertainty on Colin's part. Can anyone help clarify these requirements for us? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Fri, May 3, 2013 at 10:26 AM, Colin Perkins wrote: > On 21 Apr 2013, at 07:39, Roni Even wrote: > > I would like to start a WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock > Source Signalling. > > > > The WGLC will end on May 12th , 2013 > > > > Please review the draft and send comments to the list. > > This generally looks good, and I had only one comment: if I'm reading RFC > 5576 correctly, this draft needs to include IANA registrations for > "att-field (source level)" for the SDP attributes, to allow them to be used > in the a=ssrc: lines. Making this change will probably also requires > changes to the ABNF, to cleanly separate the syntax for "a=..." and > "a=ssrc: ..." forms so they can be separately referenced. > > -- > Colin Perkins > http://csperkins.org/ > > > > --089e0149495ebf11ca04dee0e527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've read section 12.2 of RFC 5576 and it is unclear t= o me whether a properly-registered attribute also requires a separate regis= tration to be used as a source-level attribute. I gather there's some u= ncertainty on Colin's part. Can anyone help clarify these requirements = for us?

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


On Fri, May 3, 2013 at 10:26 AM, Colin P= erkins <csp@csperkins.org> wrote:
On 21 Apr 2013, at 07:39, Roni Even wrote:
> I would like to start a WGLC on http://tools.ietf.org/html/= draft-ietf-avtcore-clksrc-03 =A0, RTP Clock Source Signalling.
>
> The WGLC will end on May 12th , 2013
>
> Please review the draft and send comments to the list.

This generally looks good, and I had only one comment: if I'm rea= ding RFC 5576 correctly, this draft needs to include IANA registrations for= "att-field (source level)" for the SDP attributes, to allow them= to be used in the a=3Dssrc: lines. Making this change will probably also r= equires changes to the ABNF, to cleanly separate the syntax for "a=3D.= .." and "a=3Dssrc: ..." forms so they can be separately refe= renced.

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




--089e0149495ebf11ca04dee0e527-- From gjshep@gmail.com Wed Jun 12 10:35:58 2013 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 5F63811E80E7 for ; Wed, 12 Jun 2013 10:35: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjiqviCgxEyY for ; Wed, 12 Jun 2013 10:35:57 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D71D11E80E3 for ; Wed, 12 Jun 2013 10:35:50 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so727834wiv.9 for ; Wed, 12 Jun 2013 10:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=WGD+Dr87Bhiaiz3n6z+WguUSbiaa61vvnc/3xI0RxSU=; b=tLCpaW2Q049s8hzpfrPtT+S6uMucY555EcLaTDKm8SVrUJSJfpN6H5WxdI8cAU6SVw HwrVMU4yIWlb/+bsR4QzybC/4Vv4ONGsnimeFFJPt9/5IsywFDlFYQk6DJkMKQjPceNJ hYx1zlJPmgTwWfOXsjPAxlFlRnHzRVMvgCHkhX/5RUF1y5Tu6CoFe+Dw0k5/d1jn7LYC S3wYZZ1q2irrnaNppyMaUG6bx1IBd10i7lL0WcLVJOk86LbHEySEYi/DJxnm/EwJBhS1 9Io/+Hk9+jLL7rXVEBUnzphf6G90Z0c4bOIreu92DjWLWOEJREB1O7sJh/t8PQJJYa6Q IPaw== MIME-Version: 1.0 X-Received: by 10.180.76.103 with SMTP id j7mr5221939wiw.21.1371058549484; Wed, 12 Jun 2013 10:35:49 -0700 (PDT) Received: by 10.180.189.12 with HTTP; Wed, 12 Jun 2013 10:35:49 -0700 (PDT) In-Reply-To: <20130612173141.16659.99790.idtracker@ietfa.amsl.com> References: <20130612173141.16659.99790.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 10:35:49 -0700 Message-ID: From: Greg Shepherd To: avt@ietf.org, joel jaeggli Content-Type: multipart/alternative; boundary=f46d043c7cc6cef20004def871e8 Subject: [AVTCORE] Fwd: New Version Notification for draft-shepherd-multicast-udp-guidelines-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:35:58 -0000 --f46d043c7cc6cef20004def871e8 Content-Type: text/plain; charset=ISO-8859-1 Please read and comment. I'd like to present this in Berlin, and get ample feedback before then in order to help this progress as quickly as possible. In addition to its overall value, it will be a helpful document in addressing outstanding Discuss issues in the RFC Editors' queue. Thanks, Greg ---------- Forwarded message ---------- From: Date: Wed, Jun 12, 2013 at 10:31 AM Subject: New Version Notification for draft-shepherd-multicast-udp-guidelines-01.txt To: Greg Shepherd A new version of I-D, draft-shepherd-multicast-udp-guidelines-01.txt has been successfully submitted by Greg Shepherd and posted to the IETF repository. Filename: draft-shepherd-multicast-udp-guidelines Revision: 01 Title: Multicast UDP Usage Guidelines for Application Designers Creation date: 2013-06-12 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-shepherd-multicast-udp-guidelines-01.txt Status: http://datatracker.ietf.org/doc/draft-shepherd-multicast-udp-guidelines Htmlized: http://tools.ietf.org/html/draft-shepherd-multicast-udp-guidelines-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-shepherd-multicast-udp-guidelines-01 Abstract: The multi-recipient nature of Multicast prevents the use of any pont- to-point connection-oriented transport, therefore restricts all Multicast data to be sent over the User Datagram Protocol (UDP). UDP provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use Multicast UDP as an Internet service must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of multicast applications and higher-level protocols. The IETF Secretariat --f46d043c7cc6cef20004def871e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please read and comment. I'd like to present this in B= erlin, and get ample feedback before then in order to help this progress as= quickly as possible. In addition to its overall value, it will be a helpfu= l document in addressing outstanding Discuss issues in the RFC Editors'= queue.

Thanks,
Greg

---= ------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Wed, Jun 12, 2013 at 10:31 AM
Subject: New Version Notification fo= r draft-shepherd-multicast-udp-guidelines-01.txt
To: Greg Shepherd <<= a href=3D"mailto:gjshep@gmail.com">gjshep@gmail.com>



A new version of I-D, draft-shepherd-multicast-udp-guidelines-01.txt
has been successfully submitted by Greg Shepherd and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-shepherd-multicast-udp-guidelines
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Multicast UDP Usage Guidelines for Application D= esigners
Creation date: =A0 2013-06-12
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.ietf.org/internet-drafts/draft-shepherd-multicast-udp-guidelines-01.txt<= /a>
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ie= tf.org/doc/draft-shepherd-multicast-udp-guidelines
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/htm= l/draft-shepherd-multicast-udp-guidelines-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ie= tf.org/rfcdiff?url2=3Ddraft-shepherd-multicast-udp-guidelines-01

Abstract:
=A0 =A0The multi-recipient nature of Multicast prevents the use of any pont= -
=A0 =A0to-point connection-oriented transport, therefore restricts all
=A0 =A0Multicast data to be sent over the User Datagram Protocol (UDP). =A0= UDP
=A0 =A0provides a minimal message-passing transport that has no inherent =A0 =A0congestion control mechanisms. =A0Because congestion control is
=A0 =A0critical to the stable operation of the Internet, applications and =A0 =A0upper-layer protocols that choose to use Multicast UDP as an Interne= t
=A0 =A0service must employ mechanisms to prevent congestion collapse and to=
=A0 =A0establish some degree of fairness with concurrent traffic. =A0This =A0 =A0document provides guidelines on the use of UDP for the designers of<= br> =A0 =A0multicast applications and higher-level protocols.




The IETF Secretariat


--f46d043c7cc6cef20004def871e8-- From Mark.Duckworth@polycom.com Fri Jun 14 06:50:33 2013 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 CC19E21F9C8A for ; Fri, 14 Jun 2013 06:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 44qxXYRTGucc for ; Fri, 14 Jun 2013 06:50:28 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 510D321F9B57 for ; Fri, 14 Jun 2013 06:50:28 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 14 Jun 2013 06:50:27 -0700 From: "Duckworth, Mark" To: "avt@ietf.org" Date: Fri, 14 Jun 2013 06:50:26 -0700 Thread-Topic: Is a source projecting middlebox part of Topo-Mixer? Thread-Index: Ac5pBN4eKDJv+oQrTuS7yI/vsK0q+Q== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60146DF3E@CRPMBOXPRD07.polycom.com> 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_49E45C59CA48264997FEBFB29B6BC2D60146DF3ECRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [AVTCORE] Is a source projecting middlebox part of Topo-Mixer? 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, 14 Jun 2013 13:50:33 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60146DF3ECRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question regarding draft-ietf-avtcore-rtp-topologies-update. Is a= source projecting middlebox part of Topo-Mixer? Section 3.6 describes the Topo-Mixer category, with subsections describing = the media mixing variety and the media switching variety. Then section 3.7 describes a source projecting middlebox, but there is no T= opo- designation for this case. If the source projecting middlebox is a th= ird variety of Topo-Mixer, then this section 3.7 should be renumbered as 3.= 6.3, to indicate it is part of 3.6 Topo-Mixer. If the source projecting mi= ddlebox is not a variety of Topo-Mixer, then it should be given its own new= Topo-Source-Projecting designation, and also added to the comparison in se= ction 4.2. Mark Duckworth --_000_49E45C59CA48264997FEBFB29B6BC2D60146DF3ECRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a questio= n regarding draft-ietf-avtcore-rtp-topologies-update.  Is a source pro= jecting middlebox part of Topo-Mixer?

 

Section 3.6 describes the Topo-Mixe= r category, with subsections describing the media mixing variety and the me= dia switching variety.

 =

Then section 3.7 describes a source projecting mid= dlebox, but there is no Topo- designation for this case.  If the sourc= e projecting middlebox is a third variety of Topo-Mixer, then this section = 3.7 should be renumbered as 3.6.3, to indicate it is part of 3.6 Topo-Mixer= .  If the source projecting middlebox is not a variety of Topo-Mixer, = then it should be given its own new Topo-Source-Projecting designation, and= also added to the comparison in section 4.2.

 

Mark Duckworth

= --_000_49E45C59CA48264997FEBFB29B6BC2D60146DF3ECRPMBOXPRD07pol_-- From internet-drafts@ietf.org Fri Jun 14 07:48:34 2013 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 E4DFC21F9AAB; Fri, 14 Jun 2013 07:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.537 X-Spam-Level: X-Spam-Status: No, score=-98.537 tagged_above=-999 required=5 tests=[AWL=-3.913, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsRb0WHb0x77; Fri, 14 Jun 2013 07:48:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99CA21F9C90; Fri, 14 Jun 2013 07:48:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614144832.19811.85991.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 07:48:32 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-10.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: Fri, 14 Jun 2013 14:48:35 -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 Maintenance Wo= rking Group of the IETF. Title : Inter-destination Media Synchronization using the RTP Co= ntrol Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-10.txt Pages : 22 Date : 2013-06-14 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent 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 useful 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jun 14 07:55:34 2013 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 B1A8821F9CEC; Fri, 14 Jun 2013 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.52 X-Spam-Level: X-Spam-Status: No, score=-98.52 tagged_above=-999 required=5 tests=[AWL=-3.896, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdiXlRaaf2tV; Fri, 14 Jun 2013 07:55:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2746A21F9CE5; Fri, 14 Jun 2013 07:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614145534.20095.32177.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 07:55:34 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-11.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: Fri, 14 Jun 2013 14:55:34 -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 Maintenance Wo= rking Group of the IETF. Title : Inter-destination Media Synchronization using the RTP Co= ntrol Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-11.txt Pages : 22 Date : 2013-06-14 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent 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 useful 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ray.vanbrandenburg@tno.nl Fri Jun 14 08:04:37 2013 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 7343821F84B2 for ; Fri, 14 Jun 2013 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.484 X-Spam-Level: *** X-Spam-Status: No, score=3.484 tagged_above=-999 required=5 tests=[AWL=-3.988, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 JbaPZlAjm7ne for ; Fri, 14 Jun 2013 08:04:32 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 604F121F9CFC for ; Fri, 14 Jun 2013 08:04:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,867,1363129200"; d="scan'208";a="1650494" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 14 Jun 2013 17:04:26 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 17:04:26 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-11.txt Thread-Index: Ac5pEHVQCQtlfKnkRX6TxzlF9erRGw== Date: Fri, 14 Jun 2013 15:04:25 +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.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "Romascanu, Dan \(Dan\) \(dromasca@avaya.com\)" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-11.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: Fri, 14 Jun 2013 15:04:37 -0000 Hi all, I've just uploaded a (or actually two, due to human error...) new version(s= ) of the IDMS draft. This includes all comments received during IETF LC. = The most important changes are the fact that there is now an IANA Registry = for the SPST values and a small informative section detailing the relations= hip with the ETSI document. = For those looking for a diff with the IETF LC-version: = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://tools.ietf.o= rg/id/draft-ietf-avtcore-idms-09.txt&url2=3Dhttp://tools.ietf.org/id/draft-= ietf-avtcore-idms-11.txt Best regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: vrijdag 14 juni 2013 16:56 To: i-d-announce@ietf.org Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-11.txt 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 Maintenance Wo= rking Group of the IETF. Title : Inter-destination Media Synchronization using the RTP Co= ntrol Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-11.txt Pages : 22 Date : 2013-06-14 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent 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 useful 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From internet-drafts@ietf.org Wed Jun 19 03:11:36 2013 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 EF8F321F9D7D; Wed, 19 Jun 2013 03:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nELKSfeELO5m; Wed, 19 Jun 2013 03:11:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7877D21F9D58; Wed, 19 Jun 2013 03:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619101135.27036.17334.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 03:11:35 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-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: Wed, 19 Jun 2013 10:11:36 -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 Maintenance Wo= rking Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-04.txt Pages : 10 Date : 2013-06-19 Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=98839ac3d4=magnus.westerlund@ericsson.com Thu Jun 20 01:41:59 2013 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 24ED421F9F5A for ; Thu, 20 Jun 2013 01:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.119 X-Spam-Level: X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=0.130, 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 NsZ8q2+3HU7h for ; Thu, 20 Jun 2013 01:41:52 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6166F21F9E4C for ; Thu, 20 Jun 2013 01:41:51 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-10-51c2c04f7749 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 07.41.09795.F40C2C15; Thu, 20 Jun 2013 10:41:51 +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.279.1; Thu, 20 Jun 2013 10:41:50 +0200 Message-ID: <51C2C058.3090900@ericsson.com> Date: Thu, 20 Jun 2013 10:42:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Duckworth, Mark" References: <49E45C59CA48264997FEBFB29B6BC2D60146DF3E@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60146DF3E@CRPMBOXPRD07.polycom.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+Jvra7/gUOBBsceCFi87FnJbrHuyFNm ByaPJUt+Mnm8eKAUwBTFbZOUWFIWnJmep2+XwJ2xdvcMloL7PBUN09tYGhhXcnUxcnJICJhI 7Ly6jAnCFpO4cG89WxcjF4eQwClGic/nl7JCOMsZJd49mskMUsUroC1x41QDO4jNIqAq0f37 PlicTcBC4uaPRjYQW1QgWOLI9s0sEPWCEidnPgGzRQSMJI6unwJUz8HBLKAoMaldEiQsLOAt 0bd3FxNIWEjAX2LfbguQMKdAgMSSzZ+gbpOU2PKiHWwrs4CexJSrLYwQtrxE89bZYBcIAV3W 0NTBOoFRaBaSxbOQtMxC0rKAkXkVI3tuYmZOern5JkZgoB7c8ttgB+Om+2KHGKU5WJTEeT+d 2hUoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MDrMmt3xljPkNbtzZ+LM/JOmu77J+k7c Xv4r/4npmupfEqXX1W7FfnTnX6PSceHvCZ8jytIxs2/duVpRpjDRqTGklKnP7u6SG3oRSTLO MyZZFKnrqoQsUVPTXMrqVdK+58PXHlfx/z3Wu/TMl83ape3NoTPpl/K/vBk7jxxcLLjig1mI Uu2SZUosxRmJhlrMRcWJAOxrK+AnAgAA Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Is a source projecting middlebox part of Topo-Mixer? 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, 20 Jun 2013 08:41:59 -0000 On 2013-06-14 15:50, Duckworth, Mark wrote: > I have a question regarding draft-ietf-avtcore-rtp-topologies-update. > Is a source projecting middlebox part of Topo-Mixer? > Short answer: Probably not! Longer answer below. > > > Section 3.6 describes the Topo-Mixer category, with subsections > describing the media mixing variety and the media switching variety. > > > > Then section 3.7 describes a source projecting middlebox, but there is > no Topo- designation for this case. If the source projecting middlebox > is a third variety of Topo-Mixer, then this section 3.7 should be > renumbered as 3.6.3, to indicate it is part of 3.6 Topo-Mixer. If the > source projecting middlebox is not a variety of Topo-Mixer, then it > should be given its own new Topo-Source-Projecting designation, and also > added to the comparison in section 4.2. I think it needs its own designation. The issue with source projecting mixer is that it is a hybrid between translator and mixer. From certain perspective it can be seen as a translator, for others it is much more like a mixer. I definitely want input on this matter. 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 woohwankim@gmail.com Wed Jun 26 22:14:00 2013 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 49E4921F9BD3 for ; Wed, 26 Jun 2013 22:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IlmJLoE0Wcs for ; Wed, 26 Jun 2013 22:13:59 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4921F92E3 for ; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so207893wib.0 for ; Wed, 26 Jun 2013 22:13:50 -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=LxOKEFf6Ms9KEPaknLMJEuLx1JG9KoVm4jyYZ9s7ZVs=; b=xkSFitzMYV3SL/cc0L/u0PGmpbkfXREddoKS5zZWEYDuvMjaFH6LbyzGidUIMiZ3rW hQAeejF8OCUw8tzpoCgyUB5k0BKBZAZnFggJdRInJMu9RS/f7UVdLMquIUZaZaKbrZCh F3l0qXK9H+INhk7IaS6LGL7+9jeDOj3oIgd3VZYYQ59z91Lc3Zp4HsFZRKZmiu/akjrv U4UF6FZbQ3pwwnbLWg/scOajjol5fvJSi4SVKEmOFdyPO023AAx/hQsM5TsQG/RxpSs6 jlXbKb5wiwh/TNQLdjFQmIQLdtUGlhoHFbFhl472ZLrXqEwkWLq4beW36jyIPWcR3ajb Y4ug== MIME-Version: 1.0 X-Received: by 10.194.123.69 with SMTP id ly5mr5009262wjb.29.1372310030248; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.216.161.133 with HTTP; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) Date: Thu, 27 Jun 2013 14:13:50 +0900 X-Google-Sender-Auth: iFjDvtvg919qvP7PyNuWb-qQ4uU Message-ID: From: Woo-Hwan Kim To: Magnus Westerlund , avt@ietf.org Content-Type: multipart/alternative; boundary=089e01175f83dff17b04e01bd316 Cc: draft-ietf-avtcore-aria-srtp@tools.ietf.org Subject: [AVTCORE] Re: Comments on draft-ietf-avtcore-aria-srtp-01 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, 27 Jun 2013 05:14:00 -0000 --089e01175f83dff17b04e01bd316 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We'll add some comments regarding the risk of short tags in the security considerations of new version(-03) and post a mail about AES-CCM ciphersuites issues. Thanks. Best Regards, Woo-Hwan Kim > Hi, > > Please see my replies inline. > > > On 2013-06-04 08:35, Woo-Hwan Kim wrote: >> First of all, we appreciate your helpful comment on the draft. >> >>>>2) Section 2.1 and 4: >>>> >>>>What are the security implications of using a 256 bit key length for th= e >>>>crypto but have as weak integrity protection as SAH1 32 bits? I think >>>>you need to discuss the implications of this, it doesn't appear to be >>>>particular balanced. >> >> We think that the key length and tag length should be treated separately= . >> Though the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good= , >> the statement of Section 7.5 in RFC 3711 still seems to be valid for 192/256 >> bit key block cipher. >> From another point of view, even when the tag length is short, >> large key length provides more security against key recovery attacks. >> So we would like to define ARIA ciphersuites corresponding to AES >> ciphersuites >> such as AES_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose a >> proper ciphersuite depending on environments. > > Okay, I don't see any significant issue with that, but please be > explicit in the considerations that this combination is quite loop sided > from a security perspective. > >> >>>>3) Section 2.2: >>>> >>>> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >>>> of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM >>>> with SRTP is defined the same as that of AES-CCM and AES-GCM. >>>> >>>>Looking in AES-GCM it appears to define a generic AEAD procedures for >>>>SRTP cipher suits. Can you please be more explicit and clear on how you >>>>use that generic procedure? >>>> >>>> >>>>4) Section 2.1, 2.2: >>>> >>>>These procedures are define by reference to existing algorithms like >>>>these sentences: >>>> >>>> ARIA counter modes are >>>> defined in a similar manner, and are denoted by ARIA_128_CTR, >>>> ARIA_192_CTR and ARIA_256_CTR respectively, according to the key >>>> lengths. The plaintext inputs to the block cipher are formed as in >>>> AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs >>>> are processed as in AES-CTR. >>>> >>>> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >>>> of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM >>>> with SRTP is defined the same as that of AES-CCM and AES-GCM. >>>> >>>>I think using words as "similar" and not being very explicit about what >>>>procedures from the other specification that applies here provide some >>>>risk for misunderstanding. I hope you can be more explicit and clear on >>>>which procedures and usage are applicable. >> >> The only difference between ARIA ciphersuites and AES ciphersuites is >> whether to invoke ARIA or AES. There is no difference in modes of >> operation itself. >> Thus we think it is not necessary to define AEAD procedures and other >> modes of >> operations more explicitly in the draft if there are proper references. >> >> If the word "similar" is inappropriate, we'll replace it by the word >> "same". >> The below sentences can be added. >> >> - ARIA counter modes are defined in the same manner except that each >> invocation of >> AES is replaced by that of ARIA. >> - The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as >> that of AES-CCM and AES-GCM except that each invocation of AES is replaced >> by ARIA. > > Correct, I agree with reference procedures when they exist. But you need > to be explicit about this. Same is better, but I haven't judged if that > makes it obvious how you apply ARIA instead of AES. > >> >> We are following the AES-SRTP documents including >> draft-ietf-avtcore-srtp-aes-gcm. >> Section 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is >> used for CCM and >> it is written that the tag size for GCM is determined by the algorithm >> choice. >> But the tag size for CCM also can be determined by the algorithm choice and >> it is better to define CCM ciphersuites for each tag size. We submitted >> such opinion, >> but not accepted yet. > > Okay, if that discussion is from the AES-GCM last call, I think you need > to re-raise this on the list as a focused email on that issue. I don't > seem to be able to find any reply to those comments. So please remind > the authors about this issue and lets see if we can come to a conclusion > on it. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- > --089e01175f83dff17b04e01bd316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We'll add some comments regarding the risk of short ta= gs in the security considerations of new version(-03)
and post a mail a= bout AES-CCM ciphersuites issues.

Thanks.

Best Regards, Woo-Hwan Kim

> Hi,
>
> Please see= my replies inline.
>
>
> On 2013-06-04 08:35, Woo-Hwan K= im wrote:
>> First = of all, we appreciate your helpful comment on the draft.
>>
>>>>= ;2) Section 2.1 and 4:
>= ;>>>
>>>>= ;What are the security implications of using a 256 bit key length for the
>>>>crypto but= have as weak integrity protection as SAH1 32 bits? I think
>>>>= ;you need to discuss the implications of this, it doesn't appear to be<= /span>
>>>>particular= balanced.
>>=
>> We think that the key l= ength and tag length should be treated separately.
>> Though= the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good,<= br style=3D"font-family:arial,sans-serif;font-size:14px">>> the statement of Section= 7.5 in RFC 3711 still seems to be valid for 192/256
>> bit ke= y block cipher.
>> F= rom another point of view, even when the tag length is short,
>> large = key length provides more security against key recovery attacks.
>> So we would like to define A= RIA ciphersuites corresponding to AES
>> cipher= suites
>> such as AE= S_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose a
>> proper= ciphersuite depending on environments.
>
> Okay, I do= n't see any significant issue with that, but please be
> explicit in the considerations that = this combination is quite loop sided
> from a sec= urity perspective.
>
>>=
>>>>3) Section 2.2:<= /span>
>>>>= ;
>>>> The int= ernet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>>>>= ; =A0 of AES-GCM and AES-CCM with SRTP. =A0The use of ARIA-CCM and ARIA-GCM=
>>>> =A0 with= SRTP is defined the same as that of AES-CCM and AES-GCM.
>>>>= ;
>>>>Looking = in AES-GCM it appears to define a generic AEAD procedures for
>>>>= ;SRTP cipher suits. Can you please be more explicit and clear on how you
>>>>use that g= eneric procedure?
>>>>= ;
>>>><= br style=3D"font-family:arial,sans-serif;font-size:14px"> >>>>= ;4) Section 2.1, 2.2:
>= >>>
>>>>= ;These procedures are define by reference to existing algorithms like
>>>>these sentences= :
>>>>= ;
>>>> =A0 =A0= ARIA counter modes are
>>>>= ; =A0 defined in a similar manner, and are denoted by ARIA_128_CTR,<= br style=3D"font-family:arial,sans-serif;font-size:14px">>>>> =A0 ARIA_192_CTR= and ARIA_256_CTR respectively, according to the key
>>>>= ; =A0 lengths. =A0The plaintext inputs to the block cipher are formed as in=
>>>> =A0 AES-= CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs
>>>>= ; =A0 are processed as in AES-CTR.
>>>>
>>>>= ; =A0 The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >>>>= ; =A0 of AES-GCM and AES-CCM with SRTP. =A0The use of ARIA-CCM and ARIA-GCM=
>>>> =A0 with= SRTP is defined the same as that of AES-CCM and AES-GCM.
>>>>= ;
>>>>I think = using words as "similar" and not being very explicit about what
>>>>= ;procedures from the other specification that applies here provide some
>>>>risk for misu= nderstanding. I hope you can be more explicit and clear on
>>>>= ;which procedures and usage are applicable.
>>
>> The on= ly difference between ARIA ciphersuites and AES ciphersuites is
>> whether to invoke ARIA or AE= S. There is no difference in modes of
>> operat= ion itself.
>> Thus = we think it is not necessary to define AEAD procedures and other
>> modes = of
>> operations mor= e explicitly in the draft if there are proper references.
>>=
>> If the word "simil= ar" is inappropriate, we'll replace it by the word
>> "= same".
>> The b= elow sentences can be added.
>>=
>> - ARIA counter modes ar= e defined in the same manner except that each
>> invoca= tion of
>> AES is re= placed by that of ARIA.
>> - The = use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as
>> that of AES-CCM and AES-GCM ex= cept that each invocation of AES is replaced
>> by ARI= A.
>
> Correct, I= agree with reference procedures when they exist. But you need
> to be explicit about this. Same i= s better, but I haven't judged if that
> makes it o= bvious how you apply ARIA instead of AES.
>
>>=
>> We are following the AE= S-SRTP documents including
>> draft-= ietf-avtcore-srtp-aes-gcm.
>> Sectio= n 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is
>> used f= or CCM and
= >> it is = written that the tag size for GCM is determined by the algorithm
>> choice= .
>> But the tag siz= e for CCM also can be determined by the algorithm choice and
>> it is = better to define CCM ciphersuites for each tag size. We submitted>> such opinion,
>> but no= t accepted yet.
>
> Okay, if t= hat discussion is from the AES-GCM last call, I think you need
> to re-raise this on the list as a= focused email on that issue. I don't
> seem to be= able to find any reply to those comments. So please remind
> the authors about this issue and let= s see if we can come to a conclusion
> on it.
>
> Cheers
>
> Magnus Wes= terlund
>
> ----------= ------------------------------------------------------------
> Multimedia= Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------<= /span>
> Ericsson A= B =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:=A0magnus.wes= terlund@ericsson.com
> ----------= ------------------------------------------------------------
>
=
--089e01175f83dff17b04e01bd316-- From woohwankim@gmail.com Wed Jun 26 22:22:41 2013 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 C6E0421F9BFC for ; Wed, 26 Jun 2013 22:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpCUkxOZL64a for ; Wed, 26 Jun 2013 22:22:40 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2D21F9A19 for ; Wed, 26 Jun 2013 22:22:39 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so195515wgh.23 for ; Wed, 26 Jun 2013 22:22:38 -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=SVa9v3sQ46pWVW6qCPuTIvC0XKJ7fKbPK+wgFVUWBnQ=; b=ItyFK81xM4m9ZXjx7NEjgOAH98LuGuxKQf4+UnKZE19hRUnCiSKtleumdJp0MX6RzT 3jke9/546IEL4pVmSVbZahzNQUA4a3Z4cUfecZYlywhdd09BsCD5QOxJSfG/ya/iOu/L cPVVvGurgPbXsFpM4HhuWVo4v+YWTxSj64M/QDG/SBFTov5a3ElRm1V01GA//dNAik60 S1skc6ODuoVLty7CtXM6ptZE3aF0ve1IsD82fmQBPaWTHrkZ9pLakkLbLWt7x6tSQbtc /zR0hGD6xCG7bIfGnqXnX9ZN+QjuvCjcpu978XPQNPk9S2Pn71lBm6uocyTj4l92GzEA ROJw== MIME-Version: 1.0 X-Received: by 10.194.123.69 with SMTP id ly5mr5026377wjb.29.1372310558875; Wed, 26 Jun 2013 22:22:38 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.216.161.133 with HTTP; Wed, 26 Jun 2013 22:22:38 -0700 (PDT) Date: Thu, 27 Jun 2013 14:22:38 +0900 X-Google-Sender-Auth: 9xfSgrQbINw538O8D30CRvQjhpk Message-ID: From: Woo-Hwan Kim To: avt@ietf.org, draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01175f836226cd04e01bf31f Cc: Magnus Westerlund , Daesung Kwon , Je Hong Park Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-06 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, 27 Jun 2013 05:22:41 -0000 --089e01175f836226cd04e01bf31f Content-Type: text/plain; charset=ISO-8859-1 Hi. Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-06. 1. In section 5.2, Tag_Size_Flag is used for CCM mode input and it is written that the tag size for GCM mode is determined by the algorithm choice. There is no difference between CCM and GCM from the point of view that the ciphersuite can determine the tag length. CCM needs tag length in the input formatting function while GCM does not. But I think it does not imply that the inputs of GCM and CCM differ and it is better to be consistent. 2. AES-CCM ciphersuites is defined for each tag length except but Section 14.1. I think it is better to add the following ciphersuites in Section 14.1 as well as other parts of the draft. - AEAD_AES_128_CCM_8 - AEAD_AES_256_CCM_8 - AEAD_AES_128_CCM_12 - AEAD_AES_256_CCM_12 3. Section 6, Section 11.1 (2^24)-16 octets => (2^28)-16 octets Regards, Woo-Hwan Kim --089e01175f836226cd04e01bf31f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi.

Here are some comments on the=A0draft-ietf= -avtcore-srtp-aes-gcm-06.

1. In section 5.2, Tag_= Size_Flag is used for CCM mode input and it is written=20 that the tag size for GCM mode is determined by the algorithm choice.
There is no=20 difference between CCM and GCM from the point of view that the ciphersuite = can=20 determine the tag length.
CCM needs tag length in the input formatting= =20 function while GCM does not.
But I think it does not imply that the inp= uts=20 of GCM and CCM differ and it is better to be consistent.=20
=A0
2. AES-CCM ciphersuites is defined for each tag length except but Sect= ion=20 14.1.
I think it is better to add the following ciphersuites in Section 14.1= =A0as=20 well as=A0other parts of the draft.
- AEAD_AES_128_CCM_8
- AEAD_AES_256_CCM_8
- AEAD_AES_128_CCM_12
- AEAD_AES_256_CCM_12
=A0
3. Section 6, Section 11.1
=A0(2^24)-16 octets =3D>=20 (2^28)-16 octets

Regards= , Woo-Hwan Kim
--089e01175f836226cd04e01bf31f-- From internet-drafts@ietf.org Wed Jun 26 22:43:14 2013 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 59B7B21F9C07; Wed, 26 Jun 2013 22:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e9xr7YDxOTT; Wed, 26 Jun 2013 22:43:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E456B21F9301; Wed, 26 Jun 2013 22:43:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130627054313.28629.3912.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 22:43:13 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-03.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, 27 Jun 2013 05:43:14 -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 Maintenance Wo= rking 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-03.txt Pages : 32 Date : 2013-06-26 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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-aria-srtp-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Fri Jun 28 01:02:50 2013 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 B7B5D21F9EE2 for ; Fri, 28 Jun 2013 01:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugBia8x2MStW for ; Fri, 28 Jun 2013 01:02:45 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 294F521F9EE1 for ; Fri, 28 Jun 2013 01:02:43 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so1281135wgh.27 for ; Fri, 28 Jun 2013 01:02:42 -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=SNyRKN9RL8eiFsK6HXtGdzXzIWmHAF4HPGahNLlCjIo=; b=SjhEuKlpyCuSOB3IeJkR3u8iDXGy8vFWpt/KtwtuINBU0wdLL9cf+jWLOzyVfuGv5j SGOE/54bBybvXZ6R4zxCk7yHAJqhzU7xDj0zNTCrd3QbD2N7Zo8FnzH+jIxxgYdeyr5K 5Nyd83+av3SJbpXJq43KGrz6YKokkb2QwhPnumpwZ13TViRqUKRk53KUA3wDjbHB6r7I /nQm/2pswfd3uCQtEXGZl44wJwoVbXg79ryv/0+Eia0VnmVK2skbZFvo63B1qDbrTqek 3bukNVxxOo0MLyXG+eGatBKQJlwNF/oM9gVm3YOM+9x5LK+O1UUlH4Dt44u5ZeOtGghF GRhQ== X-Received: by 10.180.78.98 with SMTP id a2mr1535423wix.27.1372406562333; Fri, 28 Jun 2013 01:02:42 -0700 (PDT) Received: from RoniE ([109.67.214.161]) by mx.google.com with ESMTPSA id nb12sm1515207wic.7.2013.06.28.01.02.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Jun 2013 01:02:41 -0700 (PDT) From: "Roni Even" To: Date: Fri, 28 Jun 2013 11:01:13 +0300 Message-ID: <037001ce73d5$aabc79b0$00356d10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0371_01CE73EE.D00A9C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5z1QaXGsu0rukVTxq72gA4rN7bbQ== Content-Language: en-us Cc: Magnus Westerlund Subject: [AVTCORE] Agenda request for IETF67 Berlin 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, 28 Jun 2013 08:02:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0371_01CE73EE.D00A9C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. avtcore Session Wednesday , morning Session I 9:00-11:30 Room Name: Bellevue Important dates to note: * 2013-07-01 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. * 2013-07-05 (Friday): Final agenda to be published. * 2013-07-08 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool . * 2013-07-15 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool . * 2013-07-17 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . * 2013-07-22 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . Roni Even AVTCore co-chair ------=_NextPart_000_0371_01CE73EE.D00A9C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time.

 

    avtcore Session =

    Wednesday , = morning  Session I 9:00-11:30

    Room Name: = Bellevue      

 

 

Important dates to note:

 

  • 2013-07-01 = (Monday): Working = Group Chair approval for initial document (Version -00) submissions = appreciated by UTC 24:00.
  • 2013-07-05 = (Friday): Final = agenda to be published.
  • 2013-07-08 = (Monday): Internet = Draft Cut-off for initial document (-00) submission by UTC 24:00, upload = using IETF ID = Submission Tool.
  • 2013-07-15 = (Monday): Internet = Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission = Tool.
  • 2013-07-17 = (Wednesday): Draft = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.
  • 2013-07-22 = (Monday): Revised = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.

Roni Even

AVTCore co-chair

------=_NextPart_000_0371_01CE73EE.D00A9C10-- From ron.even.tlv@gmail.com Fri Jun 28 01:06:28 2013 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 6133921F94DF for ; Fri, 28 Jun 2013 01:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqHK6NeRHVbf for ; Fri, 28 Jun 2013 01:06:22 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id CB9F621F9476 for ; Fri, 28 Jun 2013 01:03:59 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so1245887wes.23 for ; Fri, 28 Jun 2013 01:03:59 -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=iq89u/phGXPvxkg4K8GjBTwkC+C2LgYWEGIxAel8Pk4=; b=DIwPCF3aHn/2+66KEiOF/OnnciFngF8tvOft3MK/NHlbqxlVXg8uvOBMhxUBt9z2xT HFsIFZXr37+ugWzuJryisf4f2fLXMpzRSsz2OZoaAALZq9yZ7f2or4RVmnT1YzVqIO2q 6yJrE65FuNR9emES65y/30aKEWFTPgB2QGT4CNnsPmGKOoIHm3Mxh8C4oluhdDdYhJMS MUdc+CYFzAebHvJCPv8Q9JMj5s92egj1E8DdLBLk2ndjk5soCXO5A5K6sVMBRrR/12od R4oHCMxdh7HawjwWOMyUgLVH1DkJQlr4j/mc+Wm889Erd5b1JTXUqdqyqFrcbW6Ua9rk JYGw== X-Received: by 10.180.89.231 with SMTP id br7mr1587715wib.19.1372406638951; Fri, 28 Jun 2013 01:03:58 -0700 (PDT) Received: from RoniE ([109.67.214.161]) by mx.google.com with ESMTPSA id i1sm22142069wiz.6.2013.06.28.01.03.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Jun 2013 01:03:58 -0700 (PDT) From: "Roni Even" To: Date: Fri, 28 Jun 2013 11:02:30 +0300 Message-ID: <037501ce73d5$d8e18650$8aa492f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0376_01CE73EE.FE2FA8B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5z1casIDo7aYpxRqqSgw/x4+qhmA== Content-Language: en-us Cc: Magnus Westerlund Subject: Re: [AVTCORE] Agenda request for IETF87 Berlin 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, 28 Jun 2013 08:06:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0376_01CE73EE.FE2FA8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Sorry for the error in the subject Roni From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 28 June, 2013 11:01 AM To: avt@ietf.org Cc: Magnus Westerlund (magnus.westerlund@ericsson.com) Subject: Agenda request for IETF67 Berlin Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. avtcore Session Wednesday , morning Session I 9:00-11:30 Room Name: Bellevue Important dates to note: * 2013-07-01 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. * 2013-07-05 (Friday): Final agenda to be published. * 2013-07-08 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool . * 2013-07-15 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool . * 2013-07-17 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . * 2013-07-22 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . Roni Even AVTCore co-chair ------=_NextPart_000_0376_01CE73EE.FE2FA8B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Sorry for the error in = the subject

Roni

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 28 June, 2013 = 11:01 AM
To: avt@ietf.org
Cc: Magnus Westerlund = (magnus.westerlund@ericsson.com)
Subject: Agenda request for = IETF67 Berlin

 

Hi,

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time.

 

    avtcore Session =

    Wednesday , = morning  Session I 9:00-11:30

    Room Name: = Bellevue      

 

 

Important dates to note:

 

  • 2013-07-01 = (Monday): Working = Group Chair approval for initial document (Version -00) submissions = appreciated by UTC 24:00.
  • 2013-07-05 = (Friday): Final = agenda to be published.
  • 2013-07-08 = (Monday): Internet = Draft Cut-off for initial document (-00) submission by UTC 24:00, upload = using IETF ID = Submission Tool.
  • 2013-07-15 = (Monday): Internet = Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission = Tool.
  • 2013-07-17 = (Wednesday): Draft = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.
  • 2013-07-22 = (Monday): Revised = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.

Roni Even

AVTCore = co-chair

------=_NextPart_000_0376_01CE73EE.FE2FA8B0-- From kevin.gross@avanw.com Sat Jun 29 20:00:50 2013 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 CBE1021F9D88 for ; Sat, 29 Jun 2013 20:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.426 X-Spam-Level: * X-Spam-Status: No, score=1.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 o8F35c2c+ptk for ; Sat, 29 Jun 2013 20:00:46 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8B21F9D6C for ; Sat, 29 Jun 2013 20:00:45 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta09.emeryville.ca.mail.comcast.net with comcast id uSvy1l0011bwxycA9T0llm; Sun, 30 Jun 2013 03:00:45 +0000 Received: from mail-ob0-x22c.google.com ([IPv6:2607:f8b0:4003:c01::22c]) by omta18.emeryville.ca.mail.comcast.net with comcast id uT0i1l00R4KWrzs8eT0jC4; Sun, 30 Jun 2013 03:00:45 +0000 Received: by mail-ob0-f172.google.com with SMTP id wo10so3215978obc.3 for ; Sat, 29 Jun 2013 20:00:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cPK9WC7fpuWPzZiMrdIOUw0Ps6Osgm1jcZ4qoA30q5Q=; b=G1V+QFGziDCQSJ8JXBlAwkL6iJ5/YBX8KNwO3WuVWagDW9ASWDXYKnD+tZ5fceYRVj opBWGhryFhVcKDJcfrvM8OHyQvk3qxmlSyyQFjCAS3UupAmp9pkwsJUj4EK6Z9qLEwrj /JvIEh3STtzCL9oJKm6yRoAu9y88SY1E4hEIMfYi+qzyDrxwLTy9B80x2JkWkW+2aSTD 1rU/TdQsjJl3RxMDVK5Sq52qAtj7ZCfmFtOdTE9kHAjC7TOIuutjo01L7FpaE1bqryyG o9EeRtyarWQiwCd6MKjnQWutrQnGaPCHKWm/2jf1DOdWBvZaq7PHtVgz2eQmPhCIQ9zV uhNg== MIME-Version: 1.0 X-Received: by 10.182.128.42 with SMTP id nl10mr5285505obb.41.1372561242707; Sat, 29 Jun 2013 20:00:42 -0700 (PDT) Received: by 10.182.149.98 with HTTP; Sat, 29 Jun 2013 20:00:42 -0700 (PDT) In-Reply-To: <51877C75.8040805@ericsson.com> References: <20130506094039.7500.34911.idtracker@ietfa.amsl.com> <51877C75.8040805@ericsson.com> Date: Sat, 29 Jun 2013 21:00:42 -0600 Message-ID: From: Kevin Gross To: Magnus Westerlund , draft-ietf-avtcore-rtp-security-options@tools.ietf.org Content-Type: multipart/mixed; boundary=e89a8ff1cc9e4dddcf04e05651a8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372561245; bh=cPK9WC7fpuWPzZiMrdIOUw0Ps6Osgm1jcZ4qoA30q5Q=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=pCwK/T9jT+wvrEkh2rjhNCYfPulNw6phGfXe/MscaWoDWfGAS26YyMm4dT/Kws2Km Z0O1y5xrxXAI1B1gb4hosdASm6jNxoMO40MDsHXcDxHq44dSzEiteW1lZyyo8ak2Ih /e4/LTX5xdKEaQeCq/LuVKj/WXV9RMCMac/n/FwYL4irtGNw4IrOZXG3Z8KhSfLIR0 4KfKduY9Bwt1lwaphzIIsUFhhAdkXJgXIET7vEAYaDYLVChstASDD8AO3uTGv1vBnA zORuF4YAQOvvtcjm3xwDlNbEwiv+MPy6Op0FfY8fYNLMbSS277W7zaK8FevvLwwhop rxj7rRAWlzmsQ== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-03.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: Sun, 30 Jun 2013 03:00:50 -0000 --e89a8ff1cc9e4dddcf04e05651a8 Content-Type: multipart/alternative; boundary=e89a8ff1cc9e4dddcd04e05651a6 --e89a8ff1cc9e4dddcd04e05651a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've now read this draft. There were too many minor grammatical issues to list individually so I edited the XML and have attached a copy. The rest of the issues are general editorial and feedback on readability from the perspective of someone trying to learn this stuff. I hope this is useful to the authors. General: There is no definitions section in the draft and there is a lot of security terminology in the draft. Except where noted, I was able to use Wikipedia to orient myself. Section 2: What's the distinction, in this context, between "multicast groups" and "broadcast topologies". Section 3, paragraph 2: Wordy Section 3.1, paragraph 2: Wordy Section 3.1.1, paragraph 1: Add a ref for "TLS resumption" Section 3.1.1, paragraph 3, lines 6-8: Unclear Section 3.1.3, first paragraph, last sentence: "SSRC uniqueness property" and its relation to this security issue requires elaboration Section 3.1.5, second paragraph: Are any references available for proprietary solutions mentioned Section 3.2: Where does the recommendation not to use RFC 3550 Section 9 come from? Section 3.3, first paragraph: Unclear Section 3.3, third paragraph: Does "central nodes" and "peers" refer to the same entities? Section 3.4, second paragraph: Unclear Section 3.5, second paragraph: Are any references available for proprietary solutions mentioned Section 3.6, first paragraph: What are "RTP hint tracks"? Section 4.1.1, Potential for other leakage: I don't understand how RTP and RTCP headers are are visible to observers when RTP and RTCP packets are wrapped in cryptographic containers. Are we talking about IPsec? Wouldn't such wrapping include these headers? Section 4.1.3, Base level, paragraph 2, second sentence: Incomplete sentence/thought or otherwise unclear Section 4.1.3, Using Identities, paragraph 4, first 2 sentences: Unclear Section 4.1.4, Certificate based, lines 6-10: Confusing, run-on sentence Section 5.2, Location disclosure: Add ref or definition for "ICE negotiation" Section 5.2, note at end of section: Unclear Section 7: Does a security document require a security section? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, May 6, 2013 at 3:48 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > (as individual contributor) > > This update of the RTP security options has a number of improvements. > > 1. It discusses known usage or inclusion in standard specs of different > choices. > > 2. It has two new examples, PSS and RTSP 2.0. > > 3. A section on identity. > > I think this is good enough for its purpose and would really appreciate > some feedback on it. Both from people knowing security and people who > don't. > > Cheers > > Magnus Westerlund > > On 2013-05-06 11:40, 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 Maintenanc= e > Working Group of the IETF. > > > > Title : Options for Securing RTP Sessions > > Author(s) : Magnus Westerlund > > Colin Perkins > > Filename : draft-ietf-avtcore-rtp-security-options-03.txt > > Pages : 32 > > Date : 2013-05-06 > > > > Abstract: > > The Real-time Transport Protocol (RTP) is used in a large number of > > different application domains and environments. This heterogeneity > > implies that different security mechanisms are needed to provide > > services such as confidentiality, integrity and source authenticatio= n > > of RTP/RTCP packets suitable for the various environments. The rang= e > > of solutions makes it difficult for RTP-based application developers > > to pick the most suitable mechanism. This document provides an > > overview of a number of security solutions for RTP, and gives > > guidance for developers on how to choose the appropriate security > > mechanism. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-option= s > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-option= s-03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 > --e89a8ff1cc9e4dddcd04e05651a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've now read this draft. There were too many minor gr= ammatical issues to list individually so I edited the XML and have attached= a copy.

The rest of the issues are general editor= ial and feedback on readability from the perspective of someone trying to l= earn this stuff. I hope this is useful to the authors.

General: There is no definitions section in= the draft and there is a lot of security terminology in the draft. Except = where noted, I was able to use Wikipedia to orient myself.

Section 2: What's the distinction, in this context= , between "multicast groups" and "broadcast topologies"= .

Section 3, paragraph 2: Wordy

Section 3.1, paragraph 2: Wordy

Section 3.1.1, paragraph 1: Add a ref for "T= LS resumption"

Section 3.1.1, par= agraph 3, lines 6-8: Unclear

Section 3.1.3, first paragraph, last senten= ce: "SSRC uniqueness property" and its relation to this security = issue requires elaboration

Section 3.1= .5, second paragraph: Are any references available for proprietary solution= s mentioned

Section 3.2: Where does the recommendation = not to use RFC 3550 Section 9 come from?

Section 3.3, first paragraph: Unclear

Section 3.3, third paragraph: Does "central nodes" and "peer= s" refer to the same entities?

Section 3.4, second paragraph: Unclear

Section 3.5, second paragraph: Are any references available for proprietary= solutions mentioned

Section 3.6, firs= t paragraph: What are "RTP hint tracks"?

Section 4.1.1, Potential for other leakage: I don't un= derstand how RTP and RTCP headers are are visible to observers when RTP and= RTCP packets are wrapped in cryptographic containers. Are we talking about= IPsec? Wouldn't such wrapping include these headers?

Section 4.1.3, Base level, paragraph 2, sec= ond sentence: Incomplete sentence/thought or otherwise unclear

Section 4.1.3, Using Identities, paragraph 4, firs= t 2 sentences: Unclear

Section 4.1.4, Certificate based, lines 6-1= 0: Confusing, run-on sentence

Section = 5.2, Location disclosure: Add ref or definition for "ICE negotiation&q= uot;

Section 5.2, note at end of section: Unclea= r

Section 7: Does a security document = require a security section?

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


On Mon, May 6, 2013 at 3:48 AM, Magnus W= esterlund <magnus.westerlund@ericsson.com> wrot= e:
WG,

(as individual contributor)

This update of the RTP security options has a number of improvements.

1. It discusses known usage or inclusion in standard specs of different
choices.

2. It has two new examples, PSS and RTSP 2.0.

3. A section on identity.

I think this is good enough for its purpose and would really appreciate
some feedback on it. Both from people knowing security and people who
don't.

Cheers

Magnus Westerlund

On 2013-05-06 11:40, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0This draft is a work item of the Audio/Video Transport Core Mainten= ance Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Options for Securing RTP Sessi= ons
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Magnus Westerlund
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Colin Perkins
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-rtp-security-= options-03.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 32
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-06
>
> Abstract:
> =A0 =A0The Real-time Transport Protocol (RTP) is used in a large numbe= r of
> =A0 =A0different application domains and environments. =A0This heterog= eneity
> =A0 =A0implies that different security mechanisms are needed to provid= e
> =A0 =A0services such as confidentiality, integrity and source authenti= cation
> =A0 =A0of RTP/RTCP packets suitable for the various environments. =A0T= he range
> =A0 =A0of solutions makes it difficult for RTP-based application devel= opers
> =A0 =A0to pick the most suitable mechanism. =A0This document provides = an
> =A0 =A0overview of a number of security solutions for RTP, and gives > =A0 =A0guidance for developers on how to choose the appropriate securi= ty
> =A0 =A0mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iet= f-avtcore-rtp-security-options
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtcore= -rtp-security-options-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-avtcore-rtp-security-options-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
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

--e89a8ff1cc9e4dddcd04e05651a6-- --e89a8ff1cc9e4dddcf04e05651a8 Content-Type: text/xml; charset=US-ASCII; name="draft-ietf-avtcore-rtp-security-options-03-kg.xml" Content-Disposition: attachment; filename="draft-ietf-avtcore-rtp-security-options-03-kg.xml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hijmg9m00 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPCFET0NUWVBFIHJmYyBT WVNURU0gInJmYzI2MjkuZHRkIj4KPD9yZmMgdG9jPSJ5ZXMiPz4KPD9yZmMgdG9jb21wYWN0PSJ5 ZXMiPz4KPD9yZmMgdG9jZGVwdGg9IjMiPz4KPD9yZmMgdG9jaW5kZW50PSJ5ZXMiPz4KPD9yZmMg c3ltcmVmcz0ieWVzIj8+Cjw/cmZjIHNvcnRyZWZzPSJ5ZXMiPz4KPD9yZmMgY29tbWVudHM9Inll cyI/Pgo8P3JmYyBpbmxpbmU9InllcyI/Pgo8P3JmYyBjb21wYWN0PSJ5ZXMiPz4KPD9yZmMgc3Vi Y29tcGFjdD0ibm8iPz4KPHJmYyBjYXRlZ29yeT0iaW5mbyIgZG9jTmFtZT0iZHJhZnQtaWV0Zi1h dnRjb3JlLXJ0cC1zZWN1cml0eS1vcHRpb25zLTAzIgogICAgIGlwcj0idHJ1c3QyMDA5MDIiPgog IDxmcm9udD4KICAgIDx0aXRsZSBhYmJyZXY9Ik9wdGlvbnMgZm9yIFNlY3VyaW5nIFJUUCBTZXNz aW9ucyI+T3B0aW9ucyBmb3IgU2VjdXJpbmcgUlRQCiAgICBTZXNzaW9uczwvdGl0bGU+CgogICAg PGF1dGhvciBmdWxsbmFtZT0iTWFnbnVzIFdlc3Rlcmx1bmQiIGluaXRpYWxzPSJNLiIgc3VybmFt ZT0iV2VzdGVybHVuZCI+CiAgICAgIDxvcmdhbml6YXRpb24+RXJpY3Nzb248L29yZ2FuaXphdGlv bj4KCiAgICAgIDxhZGRyZXNzPgogICAgICAgIDxwb3N0YWw+CiAgICAgICAgICA8c3RyZWV0PkZh cm9nYXRhbiA2PC9zdHJlZXQ+CgogICAgICAgICAgPGNpdHk+U0UtMTY0IDgwIEtpc3RhPC9jaXR5 PgoKICAgICAgICAgIDxjb3VudHJ5PlN3ZWRlbjwvY291bnRyeT4KICAgICAgICA8L3Bvc3RhbD4K CiAgICAgICAgPHBob25lPis0NiAxMCA3MTQgODIgODc8L3Bob25lPgoKICAgICAgICA8ZW1haWw+ bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9lbWFpbD4KICAgICAgPC9hZGRyZXNzPgog ICAgPC9hdXRob3I+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iQ29saW4gUGVya2lucyIgaW5pdGlh bHM9IkMuICIgc3VybmFtZT0iUGVya2lucyI+CiAgICAgIDxvcmdhbml6YXRpb24+VW5pdmVyc2l0 eSBvZiBHbGFzZ293PC9vcmdhbml6YXRpb24+CgogICAgICA8YWRkcmVzcz4KICAgICAgICA8cG9z dGFsPgogICAgICAgICAgPHN0cmVldD5TY2hvb2wgb2YgQ29tcHV0aW5nIFNjaWVuY2U8L3N0cmVl dD4KCiAgICAgICAgICA8Y2l0eT5HbGFzZ293PC9jaXR5PgoKICAgICAgICAgIDxjb2RlPkcxMiA4 UVE8L2NvZGU+CgogICAgICAgICAgPGNvdW50cnk+VW5pdGVkIEtpbmdkb208L2NvdW50cnk+CiAg ICAgICAgPC9wb3N0YWw+CgogICAgICAgIDxlbWFpbD5jc3BAY3NwZXJraW5zLm9yZzwvZW1haWw+ CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxkYXRlIGRheT0iNiIgbW9udGg9 Ik1heSIgeWVhcj0iMjAxMyIvPgoKICAgIDxhYnN0cmFjdD4KICAgICAgPHQ+VGhlIFJlYWwtdGlt ZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgaXMgdXNlZCBpbiBhIGxhcmdlIG51bWJlciBvZgog ICAgICBkaWZmZXJlbnQgYXBwbGljYXRpb24gZG9tYWlucyBhbmQgZW52aXJvbm1lbnRzLiBUaGlz IGhldGVyb2dlbmVpdHkKICAgICAgaW1wbGllcyB0aGF0IGRpZmZlcmVudCBzZWN1cml0eSBtZWNo YW5pc21zIGFyZSBuZWVkZWQgdG8gcHJvdmlkZQogICAgICBzZXJ2aWNlcyBzdWNoIGFzIGNvbmZp ZGVudGlhbGl0eSwgaW50ZWdyaXR5IGFuZCBzb3VyY2UgYXV0aGVudGljYXRpb24gb2YKICAgICAg UlRQL1JUQ1AgcGFja2V0cyBzdWl0YWJsZSBmb3IgdGhlIHZhcmlvdXMgZW52aXJvbm1lbnRzLiBU aGUgcmFuZ2Ugb2YKICAgICAgc29sdXRpb25zIG1ha2VzIGl0IGRpZmZpY3VsdCBmb3IgUlRQLWJh c2VkIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdG8KICAgICAgcGljayB0aGUgbW9zdCBzdWl0YWJs ZSBtZWNoYW5pc20uIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YKICAgICAg YSBudW1iZXIgb2Ygc2VjdXJpdHkgc29sdXRpb25zIGZvciBSVFAsIGFuZCBnaXZlcyBndWlkYW5j ZSBmb3IKICAgICAgZGV2ZWxvcGVycyBvbiBob3cgdG8gY2hvb3NlIHRoZSBhcHByb3ByaWF0ZSBz ZWN1cml0eSBtZWNoYW5pc20uPC90PgogICAgPC9hYnN0cmFjdD4KICA8L2Zyb250PgoKICA8bWlk ZGxlPgogICAgPHNlY3Rpb24gdGl0bGU9IkludHJvZHVjdGlvbiI+CiAgICAgIDx0Pjx4cmVmIHRh cmdldD0iUkZDMzU1MCI+UmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKTwveHJlZj4g aXMKICAgICAgd2lkZWx5IHVzZWQgaW4gYSBsYXJnZSB2YXJpZXR5IG9mIG11bHRpbWVkaWEgYXBw bGljYXRpb25zLCBpbmNsdWRpbmcKICAgICAgVm9pY2Ugb3ZlciBJUCAoVm9JUCksIGNlbnRyYWxp emVkIG11bHRpbWVkaWEgY29uZmVyZW5jaW5nLCBzZW5zb3IgZGF0YQogICAgICB0cmFuc3BvcnQs IGFuZCBJbnRlcm5ldCB0ZWxldmlzaW9uIChJUFRWKSBzZXJ2aWNlcy4gVGhlc2UgYXBwbGljYXRp b25zCiAgICAgIGNhbiByYW5nZSBmcm9tIHBvaW50LXRvLXBvaW50IHBob25lIGNhbGxzLCB0aHJv dWdoIGNlbnRyYWxpc2VkIGdyb3VwCiAgICAgIHRlbGVjb25mZXJlbmNlcywgdG8gbGFyZ2Utc2Nh bGUgdGVsZXZpc2lvbiBkaXN0cmlidXRpb24gc2VydmljZXMuIFRoZQogICAgICB0eXBlcyBvZiBt ZWRpYSBjYW4gdmFyeSBzaWduaWZpY2FudGx5LCBhcyBjYW4gdGhlIHNpZ25hbGxpbmcgbWV0aG9k cwogICAgICB1c2VkIHRvIGVzdGFibGlzaCB0aGUgUlRQIHNlc3Npb25zLjwvdD4KCiAgICAgIDx0 PlRoaXMgbXVsdGktZGltZW5zaW9uYWwgaGV0ZXJvZ2VuZWl0eSBoYXMgc28gZmFyIHByZXZlbnRl ZCBkZXZlbG9wbWVudAogICAgICBvZiBhIHNpbmdsZSBzZWN1cml0eSBzb2x1dGlvbiB0aGF0IG1l ZXRzIHRoZSBuZWVkcyBvZiB0aGUgZGlmZmVyZW50CiAgICAgIGFwcGxpY2F0aW9ucy4gSW5zdGVh ZCBzaWduaWZpY2FudCBudW1iZXIgb2YgZGlmZmVyZW50IHNvbHV0aW9ucyBoYXZlCiAgICAgIGJl ZW4gZGV2ZWxvcGVkIHRvIG1lZXQgZGlmZmVyZW50IHNldHMgb2Ygc2VjdXJpdHkgZ29hbHMuIFRo aXMgbWFrZXMgaXQKICAgICAgZGlmZmljdWx0IGZvciBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHRv IGtub3cgd2hhdCBzb2x1dGlvbnMgZXhpc3QsIGFuZAogICAgICB3aGV0aGVyIHRoZWlyIHByb3Bl cnRpZXMgYXJlIGFwcHJvcHJpYXRlLiBUaGlzIG1lbW8gZ2l2ZXMgYW4gb3ZlcnZpZXcgb2YKICAg ICAgdGhlIGF2YWlsYWJsZSBSVFAgc29sdXRpb25zLCBhbmQgcHJvdmlkZXMgZ3VpZGFuY2Ugb24g dGhlaXIKICAgICAgYXBwbGljYWJpbGl0eSBmb3IgZGlmZmVyZW50IGFwcGxpY2F0aW9uIGRvbWFp bnMuIEl0IGFsc28gYXR0ZW1wdHMgdG8KICAgICAgcHJvdmlkZSBpbmRpY2F0aW9uIG9mIGFjdHVh bCBhbmQgaW50ZW5kZWQgdXNhZ2UgYXQgdGltZSBvZiB3cml0aW5nIGFzCiAgICAgIGFkZGl0aW9u YWwgaW5wdXQgdG8gaGVscCB3aXRoIGNvbnNpZGVyYXRpb25zIHN1Y2ggYXMgaW50ZXJvcGVyYWJp bGl0eSwKICAgICAgYXZhaWxhYmlsaXR5IG9mIGltcGxlbWVudGF0aW9ucyBldGMuIFRoZSBndWlk YW5jZSBwcm92aWRlZCBpcyBub3QKICAgICAgZXhoYXVzdGl2ZSwgYW5kIHRoaXMgbWVtbyBkb2Vz IG5vdCBwcm92aWRlIG5vcm1hdGl2ZQogICAgICByZWNvbW1lbmRhdGlvbnMuPC90PgoKICAgICAg PHQ+SXQgaXMgaW1wb3J0YW50IHRoYXQgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBjb25zaWRlciB0 aGUgc2VjdXJpdHkKICAgICAgZ29hbHMgYW5kIHJlcXVpcmVtZW50cyBmb3IgdGhlaXIgYXBwbGlj YXRpb24uIFRoZSBJRVRGIGNvbnNpZGVycyBpdAogICAgICBpbXBvcnRhbnQgdGhhdCBwcm90b2Nv bHMgaW1wbGVtZW50LCBhbmQgbWFrZXMgYXZhaWxhYmxlIHRvIHRoZSB1c2VyLAogICAgICBzZWN1 cmUgbW9kZXMgb2Ygb3BlcmF0aW9uIDx4cmVmIHRhcmdldD0iUkZDMzM2NSIvPi4gQmVjYXVzZSBv ZiB0aGUKICAgICAgaGV0ZXJvZ2VuZWl0eSBvZiBSVFAgYXBwbGljYXRpb25zIGFuZCB1c2UgY2Fz ZXMsIGhvd2V2ZXIsIGEgc2luZ2xlCiAgICAgIHNlY3VyaXR5IHNvbHV0aW9uIGNhbm5vdCBiZSBt YW5kYXRlZC4gSW5zdGVhZCwgYXBwbGljYXRpb24gZGV2ZWxvcGVycwogICAgICBuZWVkIHRvIHNl bGVjdCBtZWNoYW5pc21zIHRoYXQgcHJvdmlkZSBhcHByb3ByaWF0ZSBzZWN1cml0eSBmb3IgdGhl aXIKICAgICAgZW52aXJvbm1lbnQuIEl0IGlzIHN0cm9uZ2x5IGVuY291cmFnZWQgdGhhdCBjb21t b24gbWVjaGFuaXNtcyBhcmUgdXNlZAogICAgICBieSByZWxhdGVkIGFwcGxpY2F0aW9ucyBpbiBj b21tb24gZW52aXJvbm1lbnRzLiBUaGUgSUVURiBwdWJsaXNoZXMKICAgICAgZ3VpZGVsaW5lcyBm b3Igc3BlY2lmaWMgY2xhc3NlcyBvZiBhcHBsaWNhdGlvbnMsIHNvIGl0IHdvcnRoIHNlYXJjaGlu ZwogICAgICBmb3Igc3VjaCBndWlkZWxpbmVzLjwvdD4KCiAgICAgIDx0PlRoZSByZW1haW5kZXIg b2YgdGhpcyBkb2N1bWVudCBpcyBzdHJ1Y3R1cmVkIGFzIGZvbGxvd3MuIDx4cmVmCiAgICAgIHRh cmdldD0ic2VjLWJhY2tncm91bmQiLz4gcHJvdmlkZXMgYWRkaXRpb25hbCBiYWNrZ3JvdW5kLiA8 eHJlZgogICAgICB0YXJnZXQ9InNlYy1vcHRpb25zIi8+IG91dGxpbmVzIHRoZSBhdmFpbGFibGUg c2VjdXJpdHkgbWVjaGFuaXNtcyBhdCB0aGUKICAgICAgdGltZSBvZiB0aGlzIHdyaXRpbmcsIGFu ZCBsaXN0cyB0aGVpciBrZXkgc2VjdXJpdHkgcHJvcGVydGllcyBhbmQKICAgICAgY29uc3RyYWlu dHMuIFRoYXQgaXMgZm9sbG93ZWQgYnkgZ3VpZGVsaW5lcyBhbmQgaW1wb3J0YW50IGFzcGVjdHMg dG8KICAgICAgY29uc2lkZXIgd2hlbiBzZWN1cmluZyBhbiBSVFAgYXBwbGljYXRpb24gaW4gPHhy ZWYKICAgICAgdGFyZ2V0PSJzZWMtYXBwbGljYXRpb25zIi8+LiBGaW5hbGx5LCB3ZSBnaXZlIHNv bWUgZXhhbXBsZXMgb2YKICAgICAgYXBwbGljYXRpb24gZG9tYWlucyB3aGVyZSBndWlkZWxpbmVz IGZvciBzZWN1cml0eSBleGlzdCBpbiA8eHJlZgogICAgICB0YXJnZXQ9InNlYy1leGFtcGxlcyIv Pi48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtYmFja2dyb3Vu ZCIgdGl0bGU9IkJhY2tncm91bmQiPgogICAgICA8dD5SVFAgY2FuIGJlIHVzZWQgaW4gYSB3aWRl IHZhcmlldHkgb2YgdG9wb2xvZ2llcywgYW5kIGNvbWJpbmF0aW9ucyBvZgogICAgICB0b3BvbG9n aWVzLCBkdWUgdG8gaXQncyBzdXBwb3J0IGZvciB1bmljYXN0LCBtdWx0aWNhc3QgZ3JvdXBzLCBh bmQKICAgICAgYnJvYWRjYXN0IHRvcG9sb2dpZXMsIGFuZCB0aGUgZXhpc3RlbmNlIG9mIGRpZmZl cmVudCB0eXBlcyBvZiBSVFAKICAgICAgbWlkZGxlYm94ZXMuIEluIHRoZSBmb2xsb3dpbmcgd2Ug cmV2aWV3IHRoZSBkaWZmZXJlbnQgdG9wb2xvZ2llcwogICAgICBzdXBwb3J0ZWQgYnkgUlRQIHRv IHVuZGVyc3RhbmQgdGhlaXIgaW1wbGljYXRpb25zIGZvciB0aGUgc2VjdXJpdHkKICAgICAgcHJv cGVydGllcyBhbmQgdHJ1c3QgcmVsYXRpb25zIHRoYXQgY2FuIGV4aXN0IGluIFJUUCBzZXNzaW9u cy48L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iUG9pbnQgdG8gUG9pbnQgU2Vzc2lvbnMiPgog ICAgICAgIDx0PlRoZSBtb3N0IGJhc2ljIHVzZSBjYXNlIGlzIHR3byBkaXJlY3RseSBjb25uZWN0 ZWQgZW5kLXBvaW50cywgc2hvd24KICAgICAgICBpbiA8eHJlZiB0YXJnZXQ9ImZpZy1wMnAiLz4s IHdoZXJlIEEgaGFzIGVzdGFibGlzaGVkIGFuIFJUUCBzZXNzaW9uCiAgICAgICAgd2l0aCBCLiBJ biB0aGlzIGNhc2UgdGhlIFJUUCBzZWN1cml0eSBpcyBwcmltYXJpbHkgYWJvdXQgZW5zdXJpbmcg dGhhdAogICAgICAgIGFueSB0aGlyZCBwYXJ0eSBjYW4ndCBjb21wcm9taXNlIHRoZSBjb25maWRl bnRpYWxpdHkgYW5kIGludGVncml0eSBvZgogICAgICAgIHRoZSBtZWRpYSBjb21tdW5pY2F0aW9u LiBUaGlzIHJlcXVpcmVzIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIG9mCiAgICAgICAgdGhl IFJUUCBzZXNzaW9uLCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiB0aGUgUlRQL1JUQ1AgcGFja2V0 cywgYW5kCiAgICAgICAgc291cmNlIGF1dGhlbnRpY2F0aW9uIG9mIGFsbCB0aGUgcGFja2V0cyB0 byBlbnN1cmUgbm8KICAgICAgICBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2sgaXMgdGFraW5nIHBs YWNlLjwvdD4KCiAgICAgICAgPHQ+VGhlIHNvdXJjZSBhdXRoZW50aWNhdGlvbiBjYW4gYWxzbyBi ZSB0aWVkIHRvIGEgdXNlciBvciBhbgogICAgICAgIGVuZC1wb2ludHMgdmVyaWZpYWJsZSBpZGVu dGl0eSB0byBlbnN1cmUgdGhhdCB0aGUgcGVlciBrbm93cyB3aG8gdGhleQogICAgICAgIGFyZSBj b21tdW5pY2F0aW5nIHdpdGguIEhlcmUgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBzZWN1cml0eSBw cm90b2NvbAogICAgICAgIHByb3RlY3RpbmcgdGhlIFJUUCBzZXNzaW9uIGFuZCBpdHMgUlRQIGFu ZCBSVENQIHRyYWZmaWMgYW5kIHRoZQogICAgICAgIGtleS1tYW5hZ2VtZW50IHByb3RvY29sIGJl Y29tZXMgaW1wb3J0YW50IGluIHdoaWNoIHNlY3VyaXR5IHN0YXRlbWVudHMKICAgICAgICBvbmUg Y2FuIGRvLjwvdD4KCiAgICAgICAgPGZpZ3VyZSBhbGlnbj0iY2VudGVyIiBhbmNob3I9ImZpZy1w MnAiCiAgICAgICAgICAgICAgICB0aXRsZT0iUG9pbnQgdG8gUG9pbnQgVG9wb2xvZ3kiPgogICAg ICAgICAgPGFydHdvcms+PCFbQ0RBVEFbKy0tLSsgICAgICAgICArLS0tKwp8IEEgfDwtLS0tLS0t PnwgQiB8CistLS0rICAgICAgICAgKy0tLSsKXV0+PC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJl PgoKICAgICAgICA8dC8+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJT ZXNzaW9ucyBVc2luZyBhbiBSVFAgTWl4ZXIiPgogICAgICAgIDx0PkFuIFJUUCBtaXhlciBpcyBh biBSVFAgc2Vzc2lvbi1sZXZlbCBtaWRkbGVib3ggdGhhdCBvbmUgY2FuIGJ1aWxkCiAgICAgICAg YSBtdWx0aS1wYXJ0eSBSVFAgYmFzZWQgY29uZmVyZW5jZSBhcm91bmQuIFRoZSBSVFAgbWl4ZXIg bWlnaHQKICAgICAgICBhY3R1YWxseSBwZXJmb3JtIG1lZGlhIG1peGluZywgbGlrZSBtaXhpbmcg YXVkaW8gb3IgY29tcG9zaXRpbmcgdmlkZW8KICAgICAgICBpbWFnZXMgaW50byBhIG5ldyBtZWRp YSBzdHJlYW0gYmVpbmcgc2VudCBmcm9tIHRoZSBtaXhlciB0byBhIGdpdmVuCiAgICAgICAgcGFy dGljaXBhbnQ7IG9yIGl0IG1pZ2h0IHByb3ZpZGUgYSBjb25jZXB0dWFsIHN0cmVhbSwgZm9yIGV4 YW1wbGUgdGhlCiAgICAgICAgdmlkZW8gb2YgdGhlIGN1cnJlbnQgYWN0aXZlIHNwZWFrZXIuIEZy b20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3LAogICAgICAgIHRoZSBpbXBvcnRhbnQgZmVhdHVy ZXMgb2YgYW4gUlRQIG1peGVyIGlzIHRoYXQgaXQgZ2VuZXJhdGVzIGEgbmV3CiAgICAgICAgbWVk aWEgc3RyZWFtLCBhbmQgaGFzIGl0cyBvd24gc291cmNlIGlkZW50aWZpZXIsIGFuZCBkb2VzIG5v dCBzaW1wbHkKICAgICAgICBmb3J3YXJkIHRoZSBvcmlnaW5hbCBtZWRpYS48L3Q+CgogICAgICAg IDx0PkFuIFJUUCBzZXNzaW9uIHVzaW5nIGEgbWl4ZXIgbWlnaHQgaGF2ZSBhIHRvcG9sb2d5IGxp a2UgdGhhdCBpbgogICAgICAgIDx4cmVmIHRhcmdldD0iZmlnLW1peGVyIi8+LiBJbiB0aGlzIGV4 YW1wbGUsIHBhcnRpY2lwYW50cyBBIHRocm91Z2ggRCBlYWNoCiAgICAgICAgc2VuZCB1bmljYXN0 IFJUUCB0cmFmZmljIHRvIHRoZSBSVFAgbWl4ZXIsIGFuZAogICAgICAgIHJlY2VpdmUgYW4gUlRQ IHN0cmVhbSBmcm9tIHRoZSBtaXhlciwgY29tcHJpc2luZyBhIG1peHR1cmUgb2YgdGhlCiAgICAg ICAgc3RyZWFtcyBmcm9tIHRoZSBvdGhlciBwYXJ0aWNpcGFudHMuPC90PgoKICAgICAgICA8Zmln dXJlIGFsaWduPSJjZW50ZXIiIGFuY2hvcj0iZmlnLW1peGVyIgogICAgICAgICAgICAgICAgdGl0 bGU9IkV4YW1wbGUgUlRQIE1peGVyIHRvcG9sb2d5Ij4KICAgICAgICAgIDxhcnR3b3JrPjwhW0NE QVRBWystLS0rICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICArLS0tKwp8IEEgfDwtLS0tPnwgICAg ICAgICAgICB8PC0tLS0+fCBCIHwKKy0tLSsgICAgICB8ICAgICAgICAgICAgfCAgICAgICstLS0r CiAgICAgICAgICAgfCAgICBNaXhlciAgIHwKKy0tLSsgICAgICB8ICAgICAgICAgICAgfCAgICAg ICstLS0rCnwgQyB8PC0tLS0+fCAgICAgICAgICAgIHw8LS0tLT58IEQgfAorLS0tKyAgICAgICst LS0tLS0tLS0tLS0rICAgICAgKy0tLSsKIF1dPjwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4K CiAgICAgICAgPHQ+QSBjb25zZXF1ZW5jZSBvZiBhbiBSVFAgbWl4ZXIgaGF2aW5nIGl0cyBvd24g c291cmNlIGlkZW50aWZpZXIsIGFuZAogICAgICAgIGFjdGluZyBhcyBhbiBhY3RpdmUgcGFydGlj aXBhbnQgdG93YXJkcyB0aGUgb3RoZXIgZW5kLXBvaW50cyBpcyB0aGF0CiAgICAgICAgdGhlIFJU UCBtaXhlciBuZWVkcyB0byBiZSBhIHRydXN0ZWQgZGV2aWNlIHRoYXQgaXMgcGFydCBvZiB0aGUK ICAgICAgICBzZWN1cml0eSBjb250ZXh0KHMpIGVzdGFibGlzaGVkLiBUaGUgUlRQIG1peGVyIGNh biBhbHNvIGJlY29tZSBhCiAgICAgICAgc2VjdXJpdHkgZW5mb3JjaW5nIGVudGl0eS4gRm9yIGV4 YW1wbGUsIGEgY29tbW9uIGFwcHJvYWNoIHRvIHNlY3VyZQogICAgICAgIHRoZSB0b3BvbG9neSBp biA8eHJlZiB0YXJnZXQ9ImZpZy1taXhlciIvPiBpcyB0byBlc3RhYmxpc2ggYSBzZWN1cml0eQog ICAgICAgIGNvbnRleHQgYmV0d2VlbiB0aGUgbWl4ZXIgYW5kIGVhY2ggcGFydGljaXBhbnQgaW5k ZXBlbmRlbnRseSwgYW5kIGhhdmUKICAgICAgICB0aGUgbWl4ZXIgc291cmNlIGF1dGhlbnRpY2F0 ZSBlYWNoIHBlZXIuIFRoZSBtaXhlciB0aGVuIGVuc3VyZXMgdGhhdAogICAgICAgIG9uZSBwYXJ0 aWNpcGFudCBjYW5ub3QgaW1wZXJzb25hdGUgYW5vdGhlci48L3Q+CiAgICAgIDwvc2VjdGlvbj4K CiAgICAgIDxzZWN0aW9uIHRpdGxlPSJTZXNzaW9ucyBVc2luZyBhbiBSVFAgVHJhbnNsYXRvciI+ CiAgICAgICAgPHQ+UlRQIHRyYW5zbGF0b3JzIGFyZSBtaWRkbGVib3hlcyB0aGF0IHByb3ZpZGUg dmFyaW91cyBsZXZlbHMgb2YKICAgICAgICBpbi1uZXR3b3JrIG1lZGlhIHRyYW5zbGF0aW9uIGFu ZCB0cmFuc2NvZGluZy4gVGhlaXIgc2VjdXJpdHkKICAgICAgICBwcm9wZXJ0aWVzIHZhcnkgd2lk ZWx5LCBkZXBlbmRpbmcgb24gd2hpY2ggdHlwZSBvZiBvcGVyYXRpb25zIHRoZXkKICAgICAgICBh dHRlbXB0IHRvIHBlcmZvcm0uIFdlIGlkZW50aWZ5IHRocmVlIGRpZmZlcmVudCBjYXRlZ29yaWVz IG9mIFJUUAogICAgICAgIHRyYW5zbGF0b3I6IHRyYW5zcG9ydCB0cmFuc2xhdG9ycywgZ2F0ZXdh eXMsIGFuZCBtZWRpYSB0cmFuc2NvZGVycy4gV2UKICAgICAgICBkaXNjdXNzIGVhY2ggaW4gdHVy bi48L3Q+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJUcmFuc3BvcnQgVHJhbnNsYXRvciAoUmVs YXkpIj4KICAgICAgICAgIDx0PkEgdHJhbnNwb3J0IHRyYW5zbGF0b3IgPHhyZWYgdGFyZ2V0PSJS RkM1MTE3Ii8+IG9wZXJhdGVzIG9uIGEKICAgICAgICAgIGxldmVsIGJlbG93IFJUUCBhbmQgUlRD UC4gSXQgcmVsYXlzIHRoZSBSVFAvUlRDUCB0cmFmZmljIGZyb20gb25lCiAgICAgICAgICBlbmQt cG9pbnQgdG8gb25lIG9yIG1vcmUgb3RoZXIgYWRkcmVzc2VzLiBUaGlzIGNhbiBiZSBkb25lIGJh c2VkCiAgICAgICAgICBvbmx5IG9uIElQIGFkZHJlc3NlcyBhbmQgdHJhbnNwb3J0IHByb3RvY29s IHBvcnRzLCB3aXRoIGVhY2ggcmVjZWl2ZQogICAgICAgICAgcG9ydCBvbiB0aGUgdHJhbnNsYXRv ciBjYW4gaGF2ZSBhIHZlcnkgYmFzaWMgbGlzdCBvZiB3aGVyZSB0bwogICAgICAgICAgZm9yd2Fy ZCB0cmFmZmljLiBUcmFuc3BvcnQgdHJhbnNsYXRvcnMgYWxzbyBuZWVkIHRvIGltcGxlbWVudAog ICAgICAgICAgaW5ncmVzcyBmaWx0ZXJpbmcgdG8gcHJldmVudCByYW5kb20gdHJhZmZpYyBmcm9t IGJlaW5nIGZvcndhcmRlZAogICAgICAgICAgdGhhdCBpc24ndCBjb21pbmcgZnJvbSBhIHBhcnRp Y2lwYW50IGluIHRoZSBjb25mZXJlbmNlLjwvdD4KCiAgICAgICAgICA8dD48eHJlZiB0YXJnZXQ9 ImZpZy1yZWxheSIvPiBzaG93cyBhbiBleGFtcGxlIHRyYW5zcG9ydCB0cmFuc2xhdG9yLAogICAg ICAgICAgd2hlcmUgdHJhZmZpYyBmcm9tIGFueSBvbmUgb2YgdGhlIGZvdXIgcGFydGljaXBhbnRz IHdpbGwgYmUKICAgICAgICAgIGZvcndhcmRlZCB0byB0aGUgb3RoZXIgdGhyZWUgcGFydGljaXBh bnRzIHVuY2hhbmdlZC4gVGhlIHJlc3VsdGluZwogICAgICAgICAgdG9wb2xvZ3kgaXMgdmVyeSBz aW1pbGFyIHRvIEFueSBzb3VyY2UgTXVsdGljYXN0IChBU00pIHNlc3Npb24gKGFzCiAgICAgICAg ICBkaXNjdXNzZWQgaW4gPHhyZWYgdGFyZ2V0PSJzZWMtYXNtIi8+KSwgYnV0IGltcGxlbWVudGVk IGF0IHRoZQogICAgICAgICAgYXBwbGljYXRpb24gbGF5ZXIuPC90PgoKICAgICAgICAgIDxmaWd1 cmUgYWxpZ249ImNlbnRlciIgYW5jaG9yPSJmaWctcmVsYXkiCiAgICAgICAgICAgICAgICAgIHRp dGxlPSJSVFAgcmVsYXkgdHJhbnNsYXRvciB0b3BvbG9neSI+CiAgICAgICAgICAgIDxhcnR3b3Jr PjwhW0NEQVRBWystLS0rICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICArLS0tKwp8IEEgfDwtLS0t PnwgICAgICAgICAgICB8PC0tLS0+fCBCIHwKKy0tLSsgICAgICB8ICAgIFJlbGF5ICAgfCAgICAg ICstLS0rCiAgICAgICAgICAgfCBUcmFuc2xhdG9yIHwKKy0tLSsgICAgICB8ICAgICAgICAgICAg fCAgICAgICstLS0rCnwgQyB8PC0tLS0+fCAgICAgICAgICAgIHw8LS0tLT58IEQgfAorLS0tKyAg ICAgICstLS0tLS0tLS0tLS0rICAgICAgKy0tLStdXT48L2FydHdvcms+CiAgICAgICAgICA8L2Zp Z3VyZT4KCiAgICAgICAgICA8dD5BIHRyYW5zcG9ydCB0cmFuc2xhdG9yIGNhbiBvZnRlbiBvcGVy YXRlIHdpdGhvdXQgbmVlZGluZyB0byBiZSBpbgogICAgICAgICAgdGhlIHNlY3VyaXR5IGNvbnRl eHQsIGFzIGxvbmcgYXMgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbSBkb2VzIG5vdAogICAgICAgICAg cHJvdmlkZSBwcm90ZWN0aW9uIG92ZXIgdGhlIHRyYW5zcG9ydC1sYXllciBpbmZvcm1hdGlvbi4g QSB0cmFuc3BvcnQKICAgICAgICAgIHRyYW5zbGF0b3IgZG9lcywgaG93ZXZlciwgbWFrZSB0aGUg Z3JvdXAgY29tbXVuaWNhdGlvbiB2aXNpYmxlLCBhbmQKICAgICAgICAgIHNvIGNhbiBjb21wbGlj YXRlIGtleWluZyBhbmQgc291cmNlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuIFRoaXMKICAg ICAgICAgIGlzIGZ1cnRoZXIgZGlzY3Vzc2VkIGluIDx4cmVmIHRhcmdldD0ic2VjLWFzbSIvPi48 L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiBhbmNob3I9InNlYy1nYXRl d2F5IiB0aXRsZT0iR2F0ZXdheSI+CiAgICAgICAgICA8dD5HYXRld2F5cyBhcmUgZGVwbG95ZWQg d2hlbiB0aGUgZW5kcG9pbnRzIGFyZSBub3QgZnVsbHkKICAgICAgICAgIGNvbXBhdGlibGUuIDx4 cmVmIHRhcmdldD0iZmlnLWdhdGV3YXkiLz4gc2hvd3MgYW4gZXhhbXBsZSB0b3BvbG9neS4KICAg ICAgICAgIFRoZSBmdW5jdGlvbnMgYSBnYXRld2F5IHByb3ZpZGVzIGNhbiBiZSBkaXZlcnNlLCBh bmQgcmFuZ2UgZnJvbQogICAgICAgICAgdHJhbnNwb3J0IGxheWVyIHJlbGF5aW5nIGJldHdlZW4g dHdvIGRvbWFpbnMgbm90IGFsbG93aW5nIGRpcmVjdAogICAgICAgICAgY29tbXVuaWNhdGlvbiwg dmlhIHRyYW5zcG9ydCBvciBtZWRpYSBwcm90b2NvbCBmdW5jdGlvbiBpbml0aWF0aW9uCiAgICAg ICAgICBvciB0ZXJtaW5hdGlvbiwgdG8gcHJvdG9jb2wgb3IgbWVkaWEgZW5jb2RpbmcgdHJhbnNs YXRpb24uIFRoZQogICAgICAgICAgc3VwcG9ydGVkIHNlY3VyaXR5IHByb3RvY29sIG1pZ2h0IGV2 ZW4gYmUgb25lIG9mIHRoZSByZWFzb25zIGEKICAgICAgICAgIGdhdGV3YXkgaXMgbmVlZGVkLjwv dD4KCiAgICAgICAgICA8ZmlndXJlIGFsaWduPSJjZW50ZXIiIGFuY2hvcj0iZmlnLWdhdGV3YXki CiAgICAgICAgICAgICAgICAgIHRpdGxlPSJSVFAgR2F0ZXdheSBUb3BvbG9neSI+CiAgICAgICAg ICAgIDxhcnR3b3JrPjwhW0NEQVRBWworLS0tKyAgICAgICstLS0tLS0tLS0tLSsgICAgICArLS0t Kwp8IEEgfDwtLS0tPnwgIEdhdGV3YXkgIHw8LS0tLT58IEIgfAorLS0tKyAgICAgICstLS0tLS0t LS0tLSsgICAgICArLS0tKwogXV0+PC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CgogICAg ICAgICAgPHQ+VGhlIGNob2ljZSBvZiBzZWN1cml0eSBwcm90b2NvbCBhbmQgdGhlIGRldGFpbHMg b2YgdGhlIGdhdGV3YXkKICAgICAgICAgIGZ1bmN0aW9uIHdpbGwgZGV0ZXJtaW5lIGlmIHRoZSBn YXRld2F5IG5lZWRzIHRvIGJlIGEgdHJ1c3RlZCBwYXJ0IG9mCiAgICAgICAgICB0aGUgYXBwbGlj YXRpb24gc2VjdXJpdHkgY29udGV4dCBvciBub3QuIE1hbnkgZ2F0ZXdheXMgbmVlZCB0byBiZQog ICAgICAgICAgdHJ1c3RlZCBieSBhbGwgcGVlcnMgdG8gcGVyZm9ybSB0aGUgdHJhbnNsYXRpb247 IGluIG90aGVyIGNhc2VzIHNvbWUKICAgICAgICAgIG9yIGFsbCBwZWVycyBtaWdodCBub3QgYmUg YXdhcmUgb2YgdGhlIHByZXNlbmNlIG9mIHRoZSBnYXRld2F5LiBUaGUKICAgICAgICAgIHNlY3Vy aXR5IHByb3RvY29scyBoYXZlIGRpZmZlcmVudCBwcm9wZXJ0aWVzIGRlcGVuZGluZyBvbiB0aGUg ZGVncmVlCiAgICAgICAgICBvZiB0cnVzdCBhbmQgdmlzaWJpbGl0eSBuZWVkZWQuIEVuc3VyaW5n IGNvbW11bmljYXRpb24gaXMgcG9zc2libGUKICAgICAgICAgIHdpdGhvdXQgdHJ1c3RpbmcgdGhl IGdhdGV3YXkgY2FuIGJlIHN0cm9uZyBpbmNlbnRpdmUgZm9yIGFjY2VwdGluZwogICAgICAgICAg ZGlmZmVyZW50IHNlY3VyaXR5IHByb3BlcnRpZXMuIFNvbWUgc2VjdXJpdHkgc29sdXRpb25zIHdp bGwgYmUgYWJsZQogICAgICAgICAgdG8gZGV0ZWN0IHRoZSBnYXRld2F5cyBhcyBtYW5pcHVsYXRp bmcgdGhlIG1lZGlhIHN0cmVhbSwgdW5sZXNzIHRoZQogICAgICAgICAgZ2F0ZXdheSBpcyBhIHRy dXN0ZWQgZGV2aWNlLjwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIGFu Y2hvcj0ic2VjLXRyYW5zY29kZSIgdGl0bGU9Ik1lZGlhIFRyYW5zY29kZXIiPgogICAgICAgICAg PHQ+QSBNZWRpYSB0cmFuc2NvZGVyIGlzIGEgc3BlY2lhbCB0eXBlIG9mIGdhdGV3YXkgZGV2aWNl IHRoYXQKICAgICAgICAgIGNoYW5nZXMgdGhlIGVuY29kaW5nIG9mIHRoZSBtZWRpYSBiZWluZyB0 cmFuc3BvcnRlZCBieSBSVFAuIFRoZQogICAgICAgICAgZGlzY3Vzc2lvbiBpbiA8eHJlZiB0YXJn ZXQ9InNlYy1nYXRld2F5Ii8+IGFwcGxpZXMuIEEgbWVkaWEKICAgICAgICAgIHRyYW5zY29kZXIg YWx0ZXJzIHRoZSBtZWRpYSBkYXRhLCBhbmQgdGh1cyBuZWVkcyB0byBiZSB0cnVzdGVkCiAgICAg ICAgICBkZXZpY2UgdGhhdCBpcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBjb250ZXh0LjwvdD4KICAg ICAgICA8L3NlY3Rpb24+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0i c2VjLWFzbSIgdGl0bGU9IkFueSBTb3VyY2UgTXVsdGljYXN0Ij4KICAgICAgICA8dD48eHJlZiB0 YXJnZXQ9IlJGQzExMTIiPkFueSBTb3VyY2UgTXVsdGljYXN0PC94cmVmPiBpcyB0aGUgb3JpZ2lu YWwKICAgICAgICBtdWx0aWNhc3QgbW9kZWwgd2hlcmUgYW55IG11bHRpY2FzdCBncm91cCBwYXJ0 aWNpcGFudCBjYW4gc2VuZCB0byB0aGUKICAgICAgICBtdWx0aWNhc3QgZ3JvdXAsIGFuZCBnZXQg dGhlaXIgcGFja2V0cyBkZWxpdmVyZWQgdG8gYWxsIGdyb3VwIG1lbWJlcnMKICAgICAgICAoc2Vl IDx4cmVmIHRhcmdldD0iZmlnLWFzbSIvPikuIFRoaXMgZm9ybSBvZiBjb21tdW5pY2F0aW9uIGhh cwogICAgICAgIGludGVyZXN0aW5nIHNlY3VyaXR5IHByb3BlcnRpZXMsIGR1ZSB0byB0aGUgbWFu eS10by1tYW55IG5hdHVyZSBvZiB0aGUKICAgICAgICBncm91cC4gU291cmNlIGF1dGhlbnRpY2F0 aW9uIGlzIGltcG9ydGFudCwgYnV0IGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhlCiAgICAgICAgZ3Jv dXAgc2VjdXJpdHkgY29udGV4dCB3aWxsIGhhdmUgYWNjZXNzIHRvIHRoZSBuZWNlc3Nhcnkgc2Vj cmV0cyB0bwogICAgICAgIGRlY3J5cHQgYW5kIHZlcmlmeSBpbnRlZ3JpdHkgb2YgdGhlIHRyYWZm aWMuIFRodXMgdXNlIG9mIGFueSBzeW1tZXRyaWMKICAgICAgICBzZWN1cml0eSBmdW5jdGlvbnMg ZmFpbHMgaWYgdGhlIGdvYWwgaXMgdG8gc2VwYXJhdGUgaW5kaXZpZHVhbCBzb3VyY2VzCiAgICAg ICAgd2l0aGluIHRoZSBzZWN1cml0eSBjb250ZXh0OyBhbHRlcm5hdGUgc29sdXRpb25zIGFyZSBu ZWVkZWQuPC90PgoKICAgICAgICA8ZmlndXJlIGFsaWduPSJjZW50ZXIiIGFuY2hvcj0iZmlnLWFz bSIKICAgICAgICAgICAgICAgIHRpdGxlPSJBbnkgU291cmNlIE11bHRpY2FzdCBHcm91cCI+CiAg ICAgICAgICA8YXJ0d29yaz48IVtDREFUQVsKICAgICAgICAgICArLS0tLS0rCistLS0rICAgICAv ICAgICAgIFwgICAgKy0tLSsKfCBBIHwtLS0tLyAgICAgICAgIFwtLS18IEIgfAorLS0tKyAgIC8g ICBNdWx0aS0gIFwgICstLS0rCiAgICAgICArICAgIENhc3QgICAgICsKKy0tLSsgICBcICBOZXR3 b3JrICAvICArLS0tKwp8IEMgfC0tLS1cICAgICAgICAgLy0tLXwgRCB8CistLS0rICAgICBcICAg ICAgIC8gICAgKy0tLSsKICAgICAgICAgICArLS0tLS0rXV0+PC9hcnR3b3JrPgogICAgICAgIDwv ZmlndXJlPgoKICAgICAgICA8dD5JbiBhZGRpdGlvbiB0aGUgcG90ZW50aWFsIGxhcmdlIHNpemUg b2YgbXVsdGljYXN0IGdyb3VwcyBjcmVhdGVzCiAgICAgICAgc29tZSBjb25zaWRlcmF0aW9ucyBm b3IgdGhlIHNjYWxhYmlsaXR5IG9mIHRoZSBzb2x1dGlvbiBhbmQgaG93IHRoZQogICAgICAgIGtl eS1tYW5hZ2VtZW50IGlzIGhhbmRsZWQuPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2Vj dGlvbiB0aXRsZT0iU291cmNlLVNwZWNpZmljIE11bHRpY2FzdCI+CiAgICAgICAgPHQ+PHhyZWYg dGFyZ2V0PSJSRkM0NjA3Ij5Tb3VyY2UgU3BlY2lmaWMgTXVsdGljYXN0PC94cmVmPiBhbGxvd3Mg b25seQogICAgICAgIGEgc3BlY2lmaWMgZW5kLXBvaW50IHRvIHNlbmQgdHJhZmZpYyB0byB0aGUg bXVsdGljYXN0IGdyb3VwLiBUaGF0CiAgICAgICAgZW5kLXBvaW50IGlzIGxhYmVsbGVkIHRoZSBE aXN0cmlidXRpb24gU291cmNlIGluIDx4cmVmCiAgICAgICAgdGFyZ2V0PSJmaWctc3NtLXNlc3Np b24iLz4uIEl0IGRpc3RyaWJ1dGVzIHRyYWZmaWMgZnJvbSBhIG51bWJlciBvZgogICAgICAgIFJU UCBtZWRpYSBzb3VyY2VzLCBNUzEgdG8gTVNtLiA8eHJlZiB0YXJnZXQ9ImZpZy1zc20tc2Vzc2lv biIvPiBhbHNvCiAgICAgICAgZGVwaWN0cyB0aGUgZmVlZGJhY2sgcGFydCBvZiB0aGUgU1NNIDx4 cmVmIHRhcmdldD0iUkZDNTc2MCI+UlRQCiAgICAgICAgc2Vzc2lvbiB1c2luZyB1bmljYXN0IGZl ZWRiYWNrPC94cmVmPiBmcm9tIGEgbnVtYmVyIG9mIHJlY2VpdmVycwogICAgICAgIFIxLi5SbiB0 aGF0IHNlbmRzIGZlZWRiYWNrIHRvIGEgRmVlZGJhY2sgVGFyZ2V0IChGVCkgYW5kIGV2ZW50dWFs bHkKICAgICAgICBhZ2dyZWdhdGVkIGFuZCBkaXN0cmlidXRlZCB0byB0aGUgZ3JvdXAuPC90PgoK ICAgICAgICA8dD5UaGUgdXNlIG9mIFNTTSBtYWtlcyBpdCBtb3JlIGRpZmZpY3VsdCB0byBpbmpl Y3QgdHJhZmZpYyBpbnRvIHRoZQogICAgICAgIG11bHRpY2FzdCBncm91cCwgYnV0IG5vdCBpbXBv c3NpYmxlLiBTb3VyY2UgYXV0aGVudGljYXRpb24KICAgICAgICByZXF1aXJlbWVudHMgYXBwbHkg Zm9yIFNTTSBzZXNzaW9ucyB0b28sIGFuZCBhIG5vbi1zeW1tZXRyaWMKICAgICAgICB2ZXJpZmlj YXRpb24gb2Ygd2hvIHNlbnQgdGhlIFJUUCBhbmQgUlRDUCBwYWNrZXRzIGlzIG5lZWRlZC48L3Q+ CgogICAgICAgIDx0PlRoZSBTU00gY29tbXVuaWNhdGlvbiBjaGFubmVsIG5lZWRzIHRvIGJlIHNl Y3VyZWx5IGVzdGFibGlzaGVkIGFuZAogICAgICAgIGtleWVkLiBJbiBhZGRpdGlvbiBvbmUgYWxz byBoYXMgdGhlIGluZGl2aWR1YWwgdW5pY2FzdCBSVENQIGZlZWRiYWNrIHRoYXQKICAgICAgICBu ZWVkcyB0byBiZSBzZWN1cmVkLjwvdD4KCiAgICAgICAgPGZpZ3VyZSBhbGlnbj0iY2VudGVyIiBh bmNob3I9ImZpZy1zc20tc2Vzc2lvbiIKICAgICAgICAgICAgICAgIHRpdGxlPSJTU00tYmFzZWQg UlRQIHNlc3Npb24gd2l0aCBVbmljYXN0IEZlZWRiYWNrIj4KICAgICAgICAgIDxhcnR3b3JrPjwh W0NEQVRBWwogKy0tLS0tKyAgKy0tLS0tKyAgICAgICAgICArLS0tLS0rCiB8IE1TMSB8ICB8IE1T MiB8ICAgLi4uLiAgIHwgTVNtIHwKICstLS0tLSsgICstLS0tLSsgICAgICAgICAgKy0tLS0tKwog ICAgXiAgICAgICAgXiAgICAgICAgICAgICAgICBeCiAgICB8ICAgICAgICB8ICAgICAgICAgICAg ICAgIHwKICAgIFYgICAgICAgIFYgICAgICAgICAgICAgICAgVgorLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwp8ICAgICAgIERpc3RyaWJ1dGlvbiBTb3VyY2UgICAgICAgfAorLS0t LS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgfAp8IEZUIEFnZyB8ICAgICAgICAgICAgICAg ICAgICAgICAgfAorLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogIF4gXiAgICAg ICAgICAgfAogIDogIC4gICAgICAgICAgfAogIDogICArLi4uLi4uLi4uLi4uLi4uLi4uLisKICA6 ICAgICAgICAgICAgIHwgICAgICAgICAgLgogIDogICAgICAgICAgICAvIFwgICAgICAgICAgLgor LS0tLS0tKyAgICAgIC8gICBcICAgICAgICstLS0tLSsKfCBGVDEgIHw8LS0tLSsgICAgICstLS0t LT58IEZUMiB8CistLS0tLS0rICAgIC8gICAgICAgXCAgICAgKy0tLS0tKwogIF4gIF4gICAgIC8g ICAgICAgICBcICAgICBeICBeCiAgOiAgOiAgICAvICAgICAgICAgICBcICAgIDogIDoKICA6ICA6 ICAgLyAgICAgICAgICAgICBcICAgOiAgOgogIDogIDogIC8gICAgICAgICAgICAgICBcICA6ICA6 CiAgOiAgIC4vXCAgICAgICAgICAgICAgIC9cLiAgIDoKICA6ICAgLy4gXCAgICAgICAgICAgICAv IC5cICAgOgogIDogIFYgIC4gViAgICAgICAgICAgViAuICBWICA6CiArLS0tLSsgKy0tLS0rICAg ICArLS0tLSsgKy0tLS0rCiB8IFIxIHwgfCBSMiB8IC4uLiB8Um4tMXwgfCBSbiB8CiArLS0tLSsg Ky0tLS0rICAgICArLS0tLSsgKy0tLS0rXV0+PC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgoK ICAgICAgICA8dC8+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlv biBhbmNob3I9InNlYy1vcHRpb25zIiB0aXRsZT0iU2VjdXJpdHkgT3B0aW9ucyI+CiAgICAgIDx0 PlRoaXMgc2VjdGlvbiBwcm92aWRlcyBhbiBvdmVydmlldyBvZiBhIG51bWJlciBvZiBjdXJyZW50 bHkgZGVmaW5lZAogICAgICBzZWN1cml0eSBtZWNoYW5pc21zIHRoYXQgY2FuIGJlIHVzZWQgd2l0 aCBSVFAuIFRoaXMgc2VjdGlvbiB3aWxsIHVzZSBhCiAgICAgIG51bWJlciBvZiBkaWZmZXJlbnQg c2VjdXJpdHkgcmVsYXRlZCB0ZXJtcywgaWYgdGhleSBhcmUgdW5rbm93biB0byB0aGUKICAgICAg cmVhZGVyLCBwbGVhc2UgY29uc3VsdCB0aGUgPHhyZWYgdGFyZ2V0PSJSRkM0OTQ5Ij4iSW50ZXJu ZXQgU2VjdXJpdHkKICAgICAgR2xvc3NhcnksIFZlcnNpb24gMiI8L3hyZWY+LjwvdD4KCiAgICAg IDx0PlBhcnQgb2YgdGhpcyBkaXNjdXNzaW9uIHdpbGwgYmUgaW5kaWNhdGlvbiBvZiBrbm93biBk ZXBsb3ltZW50cyBvciBhdAogICAgICBsZWFzdCByZXF1aXJlbWVudHMgaW4gc3BlY2lmaWNhdGlv biB0byBzdXBwb3J0IHBhcnRpY3VsYXIgc2VjdXJpdHkKICAgICAgc29sdXRpb25zLiBUaGlzIHdp bGwgbW9zdCBjZXJ0YWlubHkgbm90IGJlIGEgY29tcGxldGUgcGljdHVyZSBhbmQgYWxzbwogICAg ICBiZWNvbWUgb2Jzb2xldGUgYXMgdGltZSBwcm9ncmVzcyBzaW5jZSB0aGUgdGltZSBvZiB3cml0 aW5nIHRoaXMKICAgICAgZG9jdW1lbnQuIFRoZSBnb2FsIHdpdGggaW5jbHVkaW5nIHN1Y2ggaW5m b3JtYXRpb24gaXMgdG8gaGVscCB0aGUKICAgICAgZGVzaWduZXIsIGdpdmVuIG11bHRpcGxlIHBv dGVudGlhbCBzb2x1dGlvbnMgdGhhdCBtZWV0cyB0aGUgc2VjdXJpdHkKICAgICAgZGVzaWduIGdv YWxzIG9uZSBjYW4gY29uc2lkZXIgdmFsdWVzIHN1Y2ggYXMgaW50ZXJvcGVyYWJpbGl0eSwgbWF0 dXJpdHkKICAgICAgb2YgaW1wbGVtZW50YXRpb25zIG9yIGV4cGVyaWVuY2VzIHdpdGggc29sdXRp b24gY29tcG9uZW50cy48L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iU2VjdXJlIFJUUCI+CiAg ICAgICAgPHQ+VGhlIDx4cmVmIHRhcmdldD0iUkZDMzcxMSI+U2VjdXJlIFJUUCAoU1JUUCkgcHJv dG9jb2w8L3hyZWY+IGlzIG9uZQogICAgICAgIG9mIHRoZSBtb3N0IGNvbW1vbmx5IHVzZWQgbWVj aGFuaXNtcyB0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSwKICAgICAgICBpbnRlZ3JpdHkgcHJv dGVjdGlvbiwgc291cmNlIGF1dGhlbnRpY2F0aW9uIGFuZCByZXBsYXkgcHJvdGVjdGlvbiBmb3IK ICAgICAgICBSVFAuIFNSVFAgd2FzIGRldmVsb3BlZCB3aXRoIFJUUCBoZWFkZXIgY29tcHJlc3Np b24gYW5kIHRoaXJkIHBhcnR5CiAgICAgICAgbW9uaXRvcnMgaW4gbWluZC4gVGh1cyB0aGUgUlRQ IGhlYWRlciBpcyBub3QgZW5jcnlwdGVkIGluIFJUUCBkYXRhCiAgICAgICAgcGFja2V0cywgYW5k IHRoZSBmaXJzdCA4IGJ5dGVzIG9mIHRoZSBmaXJzdCBSVENQIHBhY2tldCBoZWFkZXIgaW4gZWFj aAogICAgICAgIGNvbXBvdW5kIFJUQ1AgcGFja2V0IGFyZSBub3QgZW5jcnlwdGVkLiBUaGUgZW50 aXJldHkgb2YgUlRQIHBhY2tldHMKICAgICAgICBhbmQgY29tcG91bmQgUlRDUCBwYWNrZXRzIGFy ZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiBUaGlzIGFsbG93cyBSVFAKICAgICAgICBoZWFkZXIgY29t cHJlc3Npb24gdG8gd29yaywgYW5kIGxldHMgdGhpcmQgcGFydHkgbW9uaXRvcnMgZGV0ZXJtaW5l CiAgICAgICAgd2hhdCBSVFAgdHJhZmZpYyBmbG93cyBleGlzdCBiYXNlZCBvbiB0aGUgU1NSQyBm aWVsZHMsIGJ1dCBwcm90ZWN0cwogICAgICAgIHRoZSBzZW5zaXRpdmUgY29udGVudC48L3Q+Cgog ICAgICAgIDx0PlRoZSBzb3VyY2UgYXV0aGVudGljYXRpb24gZ3VhcmFudGVlcyBwcm92aWRlZCBi eSBTUlRQIGFyZSBoaWdobHkKICAgICAgICBkZXBlbmRlbnQgb24gdGhlIGNyeXB0b2dyYXBoaWMg dHJhbnNmb3JtIGFuZCBrZXktbWFuYWdlbWVudCBzY2hlbWUKICAgICAgICB1c2VkLiBJbiBzb21l IGNhc2VzIGFsbCBhIHJlY2VpdmVyIGNhbiBkZXRlcm1pbmUgaXMgd2hldGhlciB0aGUKICAgICAg ICBwYWNrZXRzIGNvbWUgZnJvbSBzb21lb25lIGluIHRoZSBncm91cCBzZWN1cml0eSBjb250ZXh0 LCBhbmQgbm90IHdoYXQKICAgICAgICBncm91cCBtZW1iZXIgc2VuZCB0aGUgcGFja2V0cy4gVGh1 cywgdGhlIHNvdXJjZSBhdXRoZW50aWNhdGlvbgogICAgICAgIGd1YXJhbnRlZXMgZGVwZW5kIGFs c28gb24gdGhlIHNlc3Npb24gdG9wb2xvZ3kuIFNvbWUgY3J5cHRvZ3JhcGhpYwogICAgICAgIHRy YW5zZm9ybSBoYXZlIHN0cm9uZ2VyIGF1dGhlbnRpY2F0aW9uIHByb3BlcnRpZXMgd2hpY2ggY2Fu IGd1YXJhbnRlZQogICAgICAgIGEgZ2l2ZW4gc291cmNlLCBldmVuIG92ZXIgYSBtdWx0aS1wYXJ0 eSBzZXNzaW9uLCBlLmcuIHRob3NlIGJhc2VkIG9uCiAgICAgICAgVEVTTEEgPHhyZWYgdGFyZ2V0 PSJSRkM0MzgzIi8+LjwvdD4KCiAgICAgICAgPHQ+U1JUUCBjYW4gZWFzaWx5IGJlIGV4dGVuZGVk IHdpdGggYWRkaXRpb25hbCBjcnlwdG9ncmFwaGljCiAgICAgICAgdHJhbnNmb3Jtcy4gQXQgdGhl IHRpbWUgb2YgdGhpcyB3cml0aW5nLCB0aGUgZm9sbG93aW5nIHRyYW5zZm9ybXMgYXJlCiAgICAg ICAgZGVmaW5lZCBvciB1bmRlciBkZWZpbml0aW9uOjxsaXN0IHN0eWxlPSJoYW5naW5nIj4KICAg ICAgICAgICAgPHQgaGFuZ1RleHQ9IkFFUyBDTSBhbmQgSE1BQy1TSEExOiI+QUVTIENvdW50ZXIg TW9kZSBlbmNyeXB0aW9uCiAgICAgICAgICAgIHdpdGggMTI4IGJpdHMga2V5cyBjb21iaW5lZCB3 aXRoIDEyOCBiaXRzIGtleWVkIEhNQUMtU0hBMSB1c2luZyA4MC0KICAgICAgICAgICAgb3IgMzIt Yml0cyBhdXRoZW50aWNhdGlvbiB0YWdzLiBUaGlzIGlzIHRoZSBkZWZhdWx0IGNyeXB0b2dyYXBo aWMKICAgICAgICAgICAgdHJhbnNmb3JtIHdoaWNoIG5lZWRzIHRvIGJlIHN1cHBvcnRlZC4gRGVm aW5lZCBpbiA8eHJlZgogICAgICAgICAgICB0YXJnZXQ9IlJGQzM3MTEiPlNSVFA8L3hyZWY+Ljwv dD4KCiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJBRVMtZjggYW5kIEhNQUMtU0hBLTE6Ij5BRVMg ZjggbW9kZSBlbmNyeXB0aW9uIHdpdGgKICAgICAgICAgICAgMTI4LWJpdCBrZXlzIGNvbWJpbmVk IHdpdGgga2V5ZWQgSE1BQy1TSEExIHVzaW5nIDgwLSBvciAzMi1iaXQKICAgICAgICAgICAgYXV0 aGVudGljYXRpb24uIERlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMzNzExIj5TUlRQPC94cmVm Pi48L3Q+CgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iVEVTTEE6Ij5BcyBhIGNvbXBsZW1lbnQg dG8gdGhlIHJlZ3VsYXIgc3ltbWV0cmljCiAgICAgICAgICAgIGtleWVkIGF1dGhlbnRpY2F0aW9u IHRyYW5zZm9ybXMsIGxpa2UgSE1BQy1TSEExLiBUaGUgVEVTTEEgYmFzZWQKICAgICAgICAgICAg YXV0aGVudGljYXRpb24gc2NoZW1lIGNhbiBwcm92aWRlIHBlci1zb3VyY2UgYXV0aGVudGljYXRp b24gaW4KICAgICAgICAgICAgc29tZSBncm91cCBjb21tdW5pY2F0aW9uIHNjZW5hcmlvcy4gVGhl IGRvd25zaWRlIGlzIG5lZWQgZm9yCiAgICAgICAgICAgIGJ1ZmZlcmluZyB0aGUgcGFja2V0cyBm b3IgYSB3aGlsZSBiZWZvcmUgYXV0aGVudGljaXR5IGNhbiBiZQogICAgICAgICAgICB2ZXJpZmll ZC4gVGhlIFRFU0xBIHRyYW5zZm9ybSBmb3IgU1JUUCBpcyBkZWZpbmVkIGluIDx4cmVmCiAgICAg ICAgICAgIHRhcmdldD0iUkZDNDM4MyIvPi48L3Q+CgogICAgICAgICAgICA8dCBoYW5nVGV4dD0i U0VFRDoiPkEgS29yZWFuIG5hdGlvbmFsIHN0YW5kYXJkIGNyeXB0b2dyYXBoaWMKICAgICAgICAg ICAgdHJhbnNmb3JtIHRoYXQgaXMgZGVmaW5lZCB0byBiZSB1c2VkIHdpdGggU1JUUCBpbiA8eHJl ZgogICAgICAgICAgICB0YXJnZXQ9IlJGQzU2NjkiLz4uIEl0IGhhcyB0aHJlZSBtb2Rlcywgb25l IHVzaW5nIFNIQS0xCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uLCBvbmUgdXNpbmcgQ291bnRl ciB3aXRoIENCQy1NQUMsIGFuZCBmaW5hbGx5IG9uZQogICAgICAgICAgICB1c2luZyBHYWxvaXMg Q291bnRlciBtb2RlLjwvdD4KCiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJBUklBOiI+QSA8eHJl ZgogICAgICAgICAgICB0YXJnZXQ9IkktRC5pZXRmLWF2dGNvcmUtYXJpYS1zcnRwIj5Lb3JlYW4g YmxvY2sgY2lwaGVyPC94cmVmPiwKICAgICAgICAgICAgdGhhdCBzdXBwb3J0cyAxMjgtLCAxOTIt IGFuZCAyNTYtYml0IGtleXMuIEl0IGFsc28gaGFzIHRocmVlIG1vZGVzLAogICAgICAgICAgICBD b3VudGVyIG1vZGUgd2hlcmUgY29tYmluZWQgd2l0aCBITUFDLVNIQTEgd2l0aCA4MCBvciAzMiBi aXRzCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHRhZ3MsIENvdW50ZXIgbW9kZSB3aXRoIENC Qy1NQUMgYW5kIEdhbG9pcyBDb3VudGVyCiAgICAgICAgICAgIG1vZGUuIEl0IGFsc28gZGVmaW5l cyBhIGRpZmZlcmVudCBrZXkgZGVyaXZhdGlvbiBmdW5jdGlvbiB0aGFuIHRoZQogICAgICAgICAg ICBBRVMgYmFzZWQgc3lzdGVtcy48L3Q+CgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iQUVTLTE5 MiBhbmQgQUVTLTI1NjoiPmNyeXB0b2dyYXBoaWMgdHJhbnNmb3JtcyBmb3IKICAgICAgICAgICAg U1JUUCBiYXNlZCBvbiBBRVMtMTkyIGFuZCBBRVMtMjU2IGNvdW50ZXIgbW9kZSBlbmNyeXB0aW9u IGFuZAogICAgICAgICAgICAxNjAtYml0IGtleWVkIEhNQUMtU0hBMSB3aXRoIDgwLSBhbmQgMzIt Yml0IGF1dGhlbnRpY2F0aW9uIHRhZ3MuCiAgICAgICAgICAgIFRodXMgcHJvdmlkaW5nIDE5MiBh bmQgMjU2IGJpdHMgZW5jcnlwdGlvbgogICAgICAgICAgICBrZXlzIGFuZCBOU0EgU3VpdGUgQiBp bmNsdWRlZCBjcnlwdG9ncmFwaGljIHRyYW5zZm9ybXMuIERlZmluZWQgaW4KICAgICAgICAgICAg PHhyZWYgdGFyZ2V0PSJSRkM2MTg4Ii8+LjwvdD4KCiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJB RVMtR0NNOiI+VGhlcmUgaXMgYWxzbyBvbmdvaW5nIHdvcmsgdG8gZGVmaW5lCiAgICAgICAgICAg IEFFUy1HQ00gKEdhbG9pcyBDb3VudGVyIE1vZGUpIGFuZCBBRVMtQ0NNIChDb3VudGVyIHdpdGgg Q0JDKQogICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBmb3IgQUVTLTEyOCBhbmQgQUVTLTI1Ni4g VGhpcyBhdXRoZW50aWNhdGlvbiBpcwogICAgICAgICAgICBpbmNsdWRlZCBpbiB0aGUgY2lwaGVy IHRleHQgd2hpY2ggYmVjb21lcyBleHBhbmRlZCB3aXRoIHRoZSBsZW5ndGgKICAgICAgICAgICAg b2YgdGhlIGF1dGhlbnRpY2F0aW9uIHRhZyBpbnN0ZWFkIG9mIHVzaW5nIHRoZSBTUlRQIGF1dGhl bnRpY2F0aW9uCiAgICAgICAgICAgIHRhZy4gVGhpcyBpcyBkZWZpbmVkIGluIDx4cmVmCiAgICAg ICAgICAgIHRhcmdldD0iSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWFlcy1nY20iLz4uPC90PgogICAg ICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAgPHQ+PHhyZWYgdGFyZ2V0PSJSRkM0NzcxIi8+IGRl ZmluZXMgYSB2YXJpYW50IG9mIHRoZSBhdXRoZW50aWNhdGlvbgogICAgICAgIHRhZyB0aGF0IGVu YWJsZXMgYSByZWNlaXZlciB0byBvYnRhaW4gdGhlIFJvbGwgb3ZlciBDb3VudGVyIGZvciB0aGUK ICAgICAgICBSVFAgc2VxdWVuY2UgbnVtYmVyIHRoYXQgaXMgcGFydCBvZiB0aGUgSW5pdGlhbGl6 YXRpb24gdmVjdG9yIChJVikgZm9yCiAgICAgICAgbWFueSBjcnlwdG9ncmFwaGljIHRyYW5zZm9y bXMuIFRoaXMgZW5hYmxlcyBxdWlja2VyIGFuZCBlYXNpZXIgb3B0aW9ucwogICAgICAgIGZvciBq b2luaW5nIGEgbG9uZyBsaXZlZCBzZWN1cmUgUlRQIGdyb3VwLCBmb3IgZXhhbXBsZSBhIGJyb2Fk Y2FzdAogICAgICAgIHNlc3Npb24uPC90PgoKICAgICAgICA8dD5SVFAgaGVhZGVyIGV4dGVuc2lv bnMgYXJlIG5vcm1hbGx5IGNhcnJpZWQgaW4gdGhlIGNsZWFyIGFuZCBvbmx5CiAgICAgICAgaW50 ZWdyaXR5IHByb3RlY3RlZCBpbiBTUlRQLiBUaGlzIGNhbiBiZSBwcm9ibGVtYXRpYyBpbiBzb21l IGNhc2VzLCBzbwogICAgICAgIDx4cmVmIHRhcmdldD0iUkZDNjkwNCIvPiBkZWZpbmVzIGFuIGV4 dGVuc2lvbiB0byBhbHNvIGVuY3J5cHQgc2VsZWN0ZWQKICAgICAgICBoZWFkZXIgZXh0ZW5zaW9u cy48L3Q+CgogICAgICAgIDx0PlNSVFAgaXMgc3BlY2lmaWVkIGFuZCBkZXBsb3llZCBpbiBhIG51 bWJlciBvZiBSVFAgdXNhZ2UgY29udGV4dHM7CiAgICAgICAgU2lnbmlmaWNhbnQgc3VwcG9ydCBp biBTSVAtZXN0YWJsaXNoZWQgVm9JUCBjbGllbnRzIGluY2x1ZGluZyBJTVM7CiAgICAgICAgPHhy ZWYgdGFyZ2V0PSJJLUQuaWV0Zi1tbXVzaWMtcmZjMjMyNmJpcyI+UlRTUDwveHJlZj4gYW5kIFJU UCBiYXNlZAogICAgICAgIG1lZGlhIHN0cmVhbWluZy4gVGh1cyBTUlRQIGluIGdlbmVyYWwgaXMg d2lkZWx5IGRlcGxveWVkLiBXaGVuIGl0CiAgICAgICAgY29tZXMgdG8gY3J5cHRvZ3JhcGhpYyB0 cmFuc2Zvcm1zIHRoZSBkZWZhdWx0IChBRVMgQ00gYW5kIEhNQUMtU0hBMSkKICAgICAgICBpcyB0 aGUgbW9zdCBjb21tb24gdXNlZC48L3Q+CgogICAgICAgIDx0PlNSVFAgZG9lcyBub3QgY29udGFp biBhbiBpbnRlZ3JhdGVkIGtleS1tYW5hZ2VtZW50IHNvbHV0aW9uLCBhbmQKICAgICAgICBpbnN0 ZWFkIHJlbGllcyBvbiBhbiBleHRlcm5hbCBrZXkgbWFuYWdlbWVudCBwcm90b2NvbC4gVGhlcmUg YXJlCiAgICAgICAgc2V2ZXJhbCBwcm90b2NvbHMgdGhhdCBjYW4gYmUgdXNlZC4gVGhlIGZvbGxv d2luZyBzZWN0aW9ucyBvdXRsaW5lCiAgICAgICAgc29tZSBwb3B1bGFyIHNjaGVtZXMuPC90PgoK ICAgICAgICA8c2VjdGlvbiB0aXRsZT0iS2V5IE1hbmFnZW1lbnQgZm9yIFNSVFA6IERUTFMtU1JU UCI+CiAgICAgICAgICA8dD5BIERhdGFncmFtIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSBleHRl bnNpb24gZXhpc3RzIGZvcgogICAgICAgICAgZXN0YWJsaXNoaW5nIFNSVFAga2V5cyA8eHJlZiB0 YXJnZXQ9IlJGQzU3NjMiLz48eHJlZgogICAgICAgICAgdGFyZ2V0PSJSRkM1NzY0Ii8+LiBUaGlz IGV4dGVuc2lvbiBwcm92aWRlcyBzZWN1cmUga2V5LWV4Y2hhbmdlCiAgICAgICAgICBiZXR3ZWVu IHR3byBwZWVycywgZW5hYmxpbmcgcGVyZmVjdCBmb3J3YXJkIHNlY3JlY3kgYW5kIGJpbmRpbmcK ICAgICAgICAgIHN0cm9uZyBpZGVudGl0eSB2ZXJpZmljYXRpb24gdG8gYW4gZW5kLXBvaW50LiBU aGUgZGVmYXVsdCBrZXkKICAgICAgICAgIGdlbmVyYXRpb24gd2lsbCBnZW5lcmF0ZSBhIGtleSB0 aGF0IGNvbnRhaW5zIG1hdGVyaWFsIGNvbnRyaWJ1dGVkIGJ5CiAgICAgICAgICBib3RoIHBlZXJz LiBUaGUga2V5LWV4Y2hhbmdlIGhhcHBlbnMgaW4gdGhlIG1lZGlhIHBsYW5lIGRpcmVjdGx5CiAg ICAgICAgICBiZXR3ZWVuIHRoZSBwZWVycy4gVGhlIGNvbW1vbiBrZXktZXhjaGFuZ2UgcHJvY2Vk dXJlcyB3aWxsIHRha2UgdHdvCiAgICAgICAgICByb3VuZCB0cmlwcyBhc3N1bWluZyBubyBsb3Nz ZXMuIFRMUyByZXN1bXB0aW9uIGNhbiBiZSB1c2VkIHdoZW4KICAgICAgICAgIGVzdGFibGlzaGlu ZyBhZGRpdGlvbmFsIG1lZGlhIHN0cmVhbXMgd2l0aCB0aGUgc2FtZSBwZWVyLCBhbmQKICAgICAg ICAgIHJlZHVjZXMgdGhlIHNldC11cCB0aW1lIHRvIG9uZSBSVFQgZm9yIHRoZXNlIHN0cmVhbXMu PC90PgoKICAgICAgICAgIDx0PlRoZSBhY3R1YWwgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBhbiBl c3RhYmxpc2hlZCBTUlRQIHNlc3Npb24KICAgICAgICAgIHVzaW5nIERUTFMgd2lsbCBkZXBlbmQg b24gdGhlIGNpcGhlciBzdWl0cyBvZmZlcmVkIGFuZCB1c2VkLiBGb3IKICAgICAgICAgIGV4YW1w bGUgc29tZSBwcm92aWRlIHBlcmZlY3QgZm9yd2FyZCBzZWNyZWN5IChQRlMpLCB3aGlsZSBvdGhl ciBkbwogICAgICAgICAgbm90LiBXaGVuIHVzaW5nIERUTFMsIHRoZSBhcHBsaWNhdGlvbiBkZXNp Z25lciBuZWVkcyB0byBzZWxlY3Qgd2hpY2gKICAgICAgICAgIGNpcGhlciBzdWl0cyBEVExTLVNS VFAgY2FuIG9mZmVyIGFuZCBhY2NlcHQgc28gdGhhdCB0aGUgZGVzaXJlZAogICAgICAgICAgc2Vj dXJpdHkgcHJvcGVydGllcyBhcmUgYWNoaWV2ZWQuPC90PgoKICAgICAgICAgIDx0PkRUTFMtU1JU UCBrZXkgbWFuYWdlbWVudCBjYW4gdXNlIHRoZSBzaWduYWxsaW5nIHByb3RvY29sIGluIHRocmVl CiAgICAgICAgICB3YXlzLiBGaXJzdCwgdG8gYWdyZWUgb24gdXNpbmcgRFRMUy1TUlRQIGZvciBt ZWRpYSBzZWN1cml0eS4KICAgICAgICAgIFNlY29uZGx5LCB0byBkZXRlcm1pbmUgdGhlIG5ldHdv cmsgbG9jYXRpb24gKGFkZHJlc3MgYW5kIHBvcnQpIHdoZXJlCiAgICAgICAgICBlYWNoIHNpZGUg aXMgcnVubmluZyBhIERUTFMgbGlzdGVuZXIgdG8gbGV0IHRoZSBwYXJ0cyBwZXJmb3JtIHRoZQog ICAgICAgICAga2V5LW1hbmFnZW1lbnQgaGFuZHNoYWtlcyB0aGF0IGdlbmVyYXRlIHRoZSBrZXlz IHVzZWQgYnkgU1JUUC4KICAgICAgICAgIEZpbmFsbHksIHRvIGV4Y2hhbmdlIGhhc2hlcyBvZiBl YWNoIHNpZGUncyBjZXJ0aWZpY2F0ZXMgdG8gZW5hYmxlCiAgICAgICAgICBlYWNoIHNpZGUgdG8g dmVyaWZ5IHRoYXQgdGhleSBoYXZlIGNvbm5lY3RlZCB0byB0aGUgb3RoZXIgYnkgc2lnbmFsbGlu ZwogICAgICAgICAgaW5kaWNhdGVkIHBvcnQgYW5kIG5vdCBhIG1hbiBpbiB0aGUgbWlkZGxlLiBU aGF0IHdheSBlbmFibGluZyBzb21lCiAgICAgICAgICBiaW5kaW5nIGJldHdlZW4gdGhlIGtleS1l eGNoYW5nZSBhbmQgdGhlIHNpZ25hbGxpbmcuIFRoaXMgdXNhZ2UgaXMKICAgICAgICAgIHdlbGwg ZGVmaW5lZCBmb3IgU0lQL1NEUCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzU3NjMiLz4sIGFuZCBpbiBt b3N0CiAgICAgICAgICBjYXNlcyBjYW4gYmUgYWRvcHRlZCBmb3IgdXNlIHdpdGggb3RoZXIgYmkt ZGlyZWN0aW9ucyBzaWduYWxsaW5nCiAgICAgICAgICBzb2x1dGlvbnMuPC90PgoKICAgICAgICAg IDx0PkRUTFMtU1JUUCB1c2FnZSBpcyBjbGVhcmx5IG9uIHRoZQogICAgICAgICAgcmlzZS4gSXQg aXMgbWFuZGF0b3J5IHRvIHN1cHBvcnQgaW4gV2ViUlRDLiBJdCBoYXMgZ3Jvd2luZyBzdXBwb3J0 CiAgICAgICAgICBhbW9uZyBTSVAgZW5kLXBvaW50cy4gRFRMUy1TUlRQIHdhcwogICAgICAgICAg ZGV2ZWxvcGVkIGluIElFVEYgcHJpbWFyaWx5IHRvIG1lZXQgc2VjdXJpdHkgcmVxdWlyZW1lbnRz IGZvcgogICAgICAgICAgU0lQLjwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0 aW9uIHRpdGxlPSJLZXkgTWFuYWdlbWVudCBmb3IgU1JUUDogTUlLRVkiPgogICAgICAgICAgPHQ+ PHhyZWYgdGFyZ2V0PSJSRkMzODMwIj5NdWx0aW1lZGlhIEludGVybmV0IEtleWluZyAoTUlLRVkp PC94cmVmPgogICAgICAgICAgaXMgYSBrZXlpbmcgcHJvdG9jb2wgdGhhdCBoYXMgc2V2ZXJhbCBt b2RlcyB3aXRoIGRpZmZlcmVudAogICAgICAgICAgcHJvcGVydGllcy4gTUlLRVkgY2FuIGJlIHVz ZWQgaW4gcG9pbnQtdG8tcG9pbnQgYXBwbGljYXRpb25zIHVzaW5nCiAgICAgICAgICBTSVAgYW5k IFJUU1AgKGUuZy4sIFZvSVAgY2FsbHMpLCBidXQgaXMgYWxzbyBzdWl0YWJsZSBmb3IgdXNlIGlu CiAgICAgICAgICBicm9hZGNhc3QgYW5kIG11bHRpY2FzdCBhcHBsaWNhdGlvbnMsIGFuZCBjZW50 cmFsaXplZCBncm91cAogICAgICAgICAgY29tbXVuaWNhdGlvbnMuPC90PgoKICAgICAgICAgIDx0 Pk1JS0VZIGNhbiBlc3RhYmxpc2ggbXVsdGlwbGUgc2VjdXJpdHkgY29udGV4dHMgb3IgY3J5cHRv Z3JhcGhpYwogICAgICAgICAgc2Vzc2lvbnMgd2l0aCBhIHNpbmdsZSBtZXNzYWdlLiBJdCBpcyB1 c2VhYmxlIGluIHNjZW5hcmlvcwogICAgICAgICAgd2hlcmUgb25lIGVudGl0eSBnZW5lcmF0ZXMg dGhlIGtleSBhbmQgbmVlZHMgdG8gZGlzdHJpYnV0ZSB0aGUga2V5CiAgICAgICAgICB0byBhIG51 bWJlciBvZiBwYXJ0aWNpcGFudHMuIFRoZSBkaWZmZXJlbnQgbW9kZXMgYW5kIHRoZSByZXN1bHRp bmcKICAgICAgICAgIHByb3BlcnRpZXMgYXJlIGhpZ2hseSBkZXBlbmRlbnQgb24gdGhlIGNyeXB0 b2dyYXBoaWMgbWV0aG9kIHVzZWQgdG8KICAgICAgICAgIGVzdGFibGlzaCB0aGUgVHJhZmZpYyBH ZW5lcmF0aW9uIEtleSAoVEdLKSB0aGF0IGlzIHVzZWQgdG8gZGVyaXZlCiAgICAgICAgICB0aGUg a2V5cyBhY3R1YWxseSB1c2VkIGJ5IHRoZSBzZWN1cml0eSBwcm90b2NvbCwgbGlrZSBTUlRQLjwv dD4KCiAgICAgICAgICA8dD5NSUtFWSBoYXMgdGhlIGZvbGxvd2luZyBtb2RlcyBvZiBvcGVyYXRp b246PGxpc3Qgc3R5bGU9ImhhbmdpbmciPgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJQcmUt U2hhcmVkIEtleToiPlVzZXMgYSBwcmUtc2hhcmVkIHNlY3JldCBmb3IKICAgICAgICAgICAgICBz eW1tZXRyaWMga2V5IGNyeXB0byB1c2VkIHRvIHNlY3VyZSBhIGtleWluZyBtZXNzYWdlIGNhcnJ5 aW5nCiAgICAgICAgICAgICAgdGhlIGFscmVhZHkgZ2VuZXJhdGVkIFRHSy4gVGhpcyBzeXN0ZW0g aXMgdGhlIG1vc3QgZWZmaWNpZW50CiAgICAgICAgICAgICAgZnJvbSB0aGUgcGVyc3BlY3RpdmUg b2YgaGF2aW5nIHNtYWxsIG1lc3NhZ2VzIGFuZCBwcm9jZXNzaW5nCiAgICAgICAgICAgICAgZGVt YW5kcy4gVGhlIGRvd25zaWRlIGlzIHNjYWxhYmlsaXR5LCB3aGVyZSB1c3VhbGx5IHRoZSBlZmZv cnQKICAgICAgICAgICAgICBmb3IgdGhlIHByb3Zpc2lvbmluZyBvZiBwcmUtc2hhcmVkIGtleXMg aXMgb25seSBtYW5hZ2VhYmxlIGlmCiAgICAgICAgICAgICAgdGhlIG51bWJlciBvZiBlbmRwb2lu dHMgaXMgc21hbGwuPC90PgoKICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0iUHVibGljIEtleSBl bmNyeXB0aW9uOiI+VXNlcyBhIHB1YmxpYyBrZXkgY3J5cHRvIHRvCiAgICAgICAgICAgICAgc2Vj dXJlIGEga2V5aW5nIG1lc3NhZ2UgY2FycnlpbmcgdGhlIGFscmVhZHktZ2VuZXJhdGVkIFRHSy4g VGhpcwogICAgICAgICAgICAgIGlzIG1vcmUgcmVzb3VyY2UgaW50ZW5zaXZlIGJ1dCBlbmFibGVz IHNjYWxhYmxlIHN5c3RlbXMuIEl0IGRvZXMKICAgICAgICAgICAgICByZXF1aXJlIGEgcHVibGlj IGtleSBpbmZyYXN0cnVjdHVyZSB0byBlbmFibGUgdmVyaWZpY2F0aW9uLjwvdD4KCiAgICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9IkRpZmZpZS1IZWxsbWFuOiI+VXNlcyBEaWZmaWUtSGVsbG1hbiBr ZXktYWdyZWVtZW50CiAgICAgICAgICAgICAgdG8gZ2VuZXJhdGUgdGhlIFRHSywgdGh1cyBwcm92 aWRpbmcgcGVyZmVjdCBmb3J3YXJkIHNlY3JlY3kuIFRoZQogICAgICAgICAgICAgIGRvd25zaWRl IGlzIGluY3JlYXNlZCByZXNvdXJjZSBjb25zdW1wdGlvbiBpbiBiYW5kd2lkdGggYW5kCiAgICAg ICAgICAgICAgcHJvY2Vzc2luZy4gVGhpcyBtZXRob2QgY2FuJ3QgYmUgdXNlZCB0byBlc3RhYmxp c2ggZ3JvdXAga2V5cyBhcwogICAgICAgICAgICAgIGVhY2ggcGFpciBvZiBwZWVycyBwZXJmb3Jt aW5nIHRoZSBNSUtFWSBleGNoYW5nZSB3aWxsIGVzdGFibGlzaAogICAgICAgICAgICAgIGRpZmZl cmVudCBrZXlzLjwvdD4KCiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IkhNQUMtQXV0aGVudGlj YXRlZCBEaWZmaWUtSGVsbG1hbjoiPjx4cmVmCiAgICAgICAgICAgICAgdGFyZ2V0PSJSRkM0NjUw Ii8+IGRlZmluZXMgYSB2YXJpYW50IG9mIHRoZSBEaWZmaWUtSGVsbG1hbgogICAgICAgICAgICAg IGV4Y2hhbmdlIHRoYXQgdXNlcyBhIHByZS1zaGFyZWQga2V5IGluIGEga2V5ZWQgSE1BQyB0byB2 ZXJpZnkKICAgICAgICAgICAgICBhdXRoZW50aWNpdHkgb2YgdGhlIGtleWluZyBtYXRlcmlhbCBp bnN0ZWFkIG9mIGEgZGlnaXRhbAogICAgICAgICAgICAgIHNpZ25hdHVyZSBhcyBpbiB0aGUgcHJl dmlvdXMgbWV0aG9kLiBUaGlzIG1ldGhvZCBpcyBzdGlsbAogICAgICAgICAgICAgIHJlc3RyaWN0 ZWQgdG8gcG9pbnQtdG8tcG9pbnQgdXNhZ2UuPC90PgoKICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0iUlNBLVI6Ij48eHJlZiB0YXJnZXQ9IlJGQzQ3MzgiPk1JS0VZLVJTQSBpbiBSZXZlcnNlCiAg ICAgICAgICAgICAgbW9kZTwveHJlZj4gaXMgYSB2YXJpYW50IG9mIHRoZSBwdWJsaWMga2V5IG1l dGhvZCB3aGljaCBkb2Vzbid0CiAgICAgICAgICAgICAgcmVseSBvbiB0aGUgaW5pdGlhdG9yIG9m IHRoZSBrZXktZXhjaGFuZ2Uga25vd2luZyB0aGUgcmVzcG9uZGVyJ3MKICAgICAgICAgICAgICBj ZXJ0aWZpY2F0ZS4gVGhpcyBtZXRob2QgbGV0cyBib3RoIHRoZSBpbml0aWF0b3IgYW5kIHRoZQog ICAgICAgICAgICAgIHJlc3BvbmRlciB0byBzcGVjaWZ5IHRoZSBUR0sgbWF0ZXJpYWwgZGVwZW5k aW5nIG9uIHVzZSBjYXNlLgogICAgICAgICAgICAgIFVzYWdlIG9mIHRoaXMgbW9kZSByZXF1aXJl cyBvbmUgcm91bmQtdHJpcCB0aW1lLjwvdD4KCiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlRJ Q0tFVDoiPjx4cmVmIHRhcmdldD0iUkZDNjA0MyIvPiBpcyBhIE1JS0VZCiAgICAgICAgICAgICAg ZXh0ZW5zaW9uIHVzaW5nIHRydXN0ZWQgY2VudHJhbGl6ZWQga2V5IG1hbmFnZW1lbnQgc2Vydmlj ZSBhbmQKICAgICAgICAgICAgICB0aWNrZXRzLCBsaWtlIEtlcmJlcm9zLjwvdD4KCiAgICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9IklCQUtFOiI+PHhyZWYgdGFyZ2V0PSJSRkM2MjY3Ii8+IHVzZXMg YSBrZXkKICAgICAgICAgICAgICBtYW5hZ2VtZW50IHNlcnZpY2VzIChLTVMpIGluZnJhc3RydWN0 dXJlIGJ1dCB3aXRoIGxvd2VyIGRlbWFuZAogICAgICAgICAgICAgIG9uIHRoZSBLTVMuIENsYWlt cyB0byBwcm92aWRlcyBib3RoIHBlcmZlY3QgZm9yd2FyZCBhbmQKICAgICAgICAgICAgICBiYWNr d2FyZHMgc2VjcmVjeSwgdGhlIGV4YWN0IG1lYW5pbmcgaXMgdW5jbGVhciAoU2VlIDx4cmVmCiAg ICAgICAgICAgICAgdGFyZ2V0PSJSRkM0OTQ5Ij5QZXJmZWN0IEZvcndhcmQgU2VjcmVjeSBpbjwv eHJlZj4pLjwvdD4KCiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlNBS0tFOiI+PHhyZWYgdGFy Z2V0PSJSRkM2NTA5Ii8+IHByb3ZpZGVzCiAgICAgICAgICAgICAgU2FrYWktS2FzYWhhcmEgS2V5 IEVuY3J5cHRpb24gaW4gTUlLRVkuIEJhc2VkIG9uIElkZW50aXR5LWJhc2VkCiAgICAgICAgICAg ICAgUHVibGljIEtleSBDcnlwdG9ncmFwaHkgYW5kIGEgS01TIGluZnJhc3RydWN0dXJlIHRvIGVz dGFibGlzaCBhCiAgICAgICAgICAgICAgc2hhcmVkIHNlY3JldCB2YWx1ZSBhbmQgY2VydGlmaWNh dGVsZXNzIHNpZ25hdHVyZXMgdG8gcHJvdmlkZQogICAgICAgICAgICAgIHNvdXJjZSBhdXRoZW50 aWNhdGlvbi4gSXRzIGZlYXR1cmVzIGluY2x1ZGUgc2ltcGxleCB0cmFuc21pc3Npb24sCiAgICAg ICAgICAgICAgc2NhbGFiaWxpdHksIGxvdy1sYXRlbmN5IGNhbGwgc2V0LXVwLCBhbmQgc3VwcG9y dCBmb3Igc2VjdXJlCiAgICAgICAgICAgICAgZGVmZXJyZWQgZGVsaXZlcnkuPC90PgogICAgICAg ICAgICA8L2xpc3Q+PC90PgoKICAgICAgICAgIDx0Pk1JS0VZIG1lc3NhZ2VzIGhhdmUgc2V2ZXJh bCBkZWZpbmVkIHRyYW5zcG9ydHMuIDx4cmVmCiAgICAgICAgICB0YXJnZXQ9IlJGQzQ1NjciLz4g ZGVmaW5lcyBob3cgTUlLRVkgbWVzc2FnZXMgY2FuIGJlIGVtYmVkZGVkIGluCiAgICAgICAgICBn ZW5lcmFsIFNEUCBmb3IgdXNhZ2Ugd2l0aCB0aGUgc2lnbmFsbGluZyBwcm90b2NvbHMgU0lQLCBT QVAgYW5kCiAgICAgICAgICBSVFNQLiBUaGVyZSBhbHNvIGV4aXN0IDNHUFAgZGVmaW5lZCB1c2Fn ZSBvZiBNSUtFWSB0aGF0IHNlbmRzCiAgICAgICAgICBNSUtFWSBtZXNzYWdlcyBkaXJlY3RseSBv dmVyIFVEUCB0byBrZXkgdGhlIHJlY2VpdmVycyBvZiA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJU M0dQUC4zMy4yNDYiPk11bHRpbWVkaWEgQnJvYWRjYXN0IGFuZCBNdWx0aWNhc3QgU2VydmljZQog ICAgICAgICAgKE1CTVMpPC94cmVmPi48L3Q+CgogICAgICAgICAgPHQ+TUlLRVkgd2l0aCBwcmUt c2hhcmVkIGtleXMgYXJlIHVzZWQgYnkgPHhyZWYKICAgICAgICAgIHRhcmdldD0iVDNHUFAuMzMu MjQ2Ij4zR1BQIE1CTVM8L3hyZWY+LiBXaGlsZSA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJJLUQu aWV0Zi1tbXVzaWMtcmZjMjMyNmJpcyI+UlRTUCAyLjA8L3hyZWY+IHNwZWNpZmllcyB1c2Ugb2YK ICAgICAgICAgIHRoZSBSU0EtUiBtb2RlLjwvdD4KCiAgICAgICAgICA8dD5CYXNlZCBvbiB0aGUg bWFueSBjaG9pY2VzLCBpdCBpcyBpbXBvcnRhbnQgdG8gY29uc2lkZXIgdGhlCiAgICAgICAgICBw cm9wZXJ0aWVzIG5lZWRlZCBpbiBvbmUncyBzb2x1dGlvbiBhbmQgYmFzZWQgb24gdGhhdCwgZXZh bHVhdGUgd2hpY2gKICAgICAgICAgIG1vZGVzIGFyZSBjYW5kaWRhdGVzIGZvciBvbmUncyB1c2Fn ZS4gTW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUKICAgICAgICAgIGFwcGxpY2FiaWxpdHkgb2YgdGhl IGRpZmZlcmVudCBNSUtFWSBtb2RlcyBjYW4gYmUgZm91bmQgaW4gPHhyZWYKICAgICAgICAgIHRh cmdldD0iUkZDNTE5NyIvPi48L3Q+CgogICAgICAgICAgPC90PlRoZXJlIGFyZSBzb21lIFNJUCBl bmQtcG9pbnRzIHRoYXQgc3VwcG9ydCBNSUtFWS4gVGhlCiAgICAgICAgICBtb2RlIHRoZXkgdXNl IGFyZSB1bmtub3duIHRvIHRoZSBhdXRob3JzLjwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAg ICAgIDxzZWN0aW9uIHRpdGxlPSJLZXkgTWFuYWdlbWVudCBmb3IgU1JUUDogU2VjdXJpdHkgRGVz Y3JpcHRpb25zIj4KICAgICAgICAgIDx0Pjx4cmVmIHRhcmdldD0iUkZDNDU2OCIvPiBwcm92aWRl cyBhIGtleWluZyBzb2x1dGlvbiBiYXNlZCBvbgogICAgICAgICAgc2VuZGluZyBwbGFpbiB0ZXh0 IGtleXMgaW4gPHhyZWYgdGFyZ2V0PSJSRkM0NTY2Ij5TRFA8L3hyZWY+LiBJdCBpcwogICAgICAg ICAgcHJpbWFyaWx5IHVzZWQgd2l0aCBTSVAgYW5kIFNEUCBPZmZlci9BbnN3ZXIsIGFuZCBpcyB3 ZWxsLWRlZmluZWQgaW4KICAgICAgICAgIHBvaW50LXRvLXBvaW50IHNlc3Npb25zIHdoZXJlIGVh Y2ggc2lkZSBkZWNsYXJlcyBpdHMgb3duIHVuaXF1ZSBrZXkuCiAgICAgICAgICBVc2luZyBTZWN1 cml0eSBEZXNjcmlwdGlvbnMgdG8gZXN0YWJsaXNoIGdyb3VwIGtleXMgaXMgbGVzcyB3ZWxsCiAg ICAgICAgICBkZWZpbmVkLCBhbmQgY2FuIGhhdmUgc2VjdXJpdHkgaXNzdWVzIGFzIHRoZSBTU1JD IHVuaXF1ZW5lc3MKICAgICAgICAgIHByb3BlcnR5IGNhbid0IGJlIGd1YXJhbnRlZWQuPC90PgoK ICAgICAgICAgIDx0PlNpbmNlIGtleXMgYXJlIHRyYW5zcG9ydGVkIGluIHBsYWluIHRleHQgaW4g U0RQLCB0aGV5IGNhbiBlYXNpbHkKICAgICAgICAgIGJlIGludGVyY2VwdGVkIHVubGVzcyB0aGUg U0RQIGNhcnJ5aW5nIHByb3RvY29sIHByb3ZpZGVzIHN0cm9uZwogICAgICAgICAgZW5kLXRvLWVu ZCBjb25maWRlbnRpYWxpdHkgYW5kIGF1dGhlbnRpY2F0aW9uIGd1YXJhbnRlZXMuIFRoaXMgaXMK ICAgICAgICAgIG5vdCBub3JtYWxseSB0aGUgY2FzZSwgd2hlcmUgaW5zdGVhZAogICAgICAgICAg aG9wLWJ5LWhvcCBzZWN1cml0eSBpcyBwcm92aWRlZCBiZXR3ZWVuIHNpZ25hbGxpbmcgbm9kZXMg dXNpbmcgVExTLgogICAgICAgICAgVGhpcyBsZWF2ZXMgdGhlIGtleWluZyBtYXRlcmlhbCBzZW5z aXRpdmUgdG8gY2FwdHVyZSBieSB0aGUKICAgICAgICAgIHRyYXZlcnNlZCBzaWduYWxsaW5nIG5v ZGVzLiBUaHVzLCBpbiBtb3N0IGNhc2VzLCB0aGUgc2VjdXJpdHkKICAgICAgICAgIHByb3BlcnRp ZXMgb2Ygc2VjdXJpdHkgZGVzY3JpcHRpb25zIGFyZSB3ZWFrLiBUaGUgdXNhZ2Ugb2Ygc2VjdXJp dHkKICAgICAgICAgIGRlc2NyaXB0aW9ucyB1c3VhbGx5IHJlcXVpcmVzIGFkZGl0aW9uYWwgc2Vj dXJpdHkgbWVhc3VyZXMsIGUuZy4gdGhlCiAgICAgICAgICBzaWduYWxsaW5nIG5vZGVzIGJlIHRy dXN0ZWQgYW5kIHByb3RlY3RlZCBieSBzdHJpY3QgYWNjZXNzIGNvbnRyb2wuCiAgICAgICAgICBV c2FnZSBvZiBzZWN1cml0eSBkZXNjcmlwdGlvbnMgcmVxdWlyZXMgY2FyZWZ1bCBkZXNpZ24gaW4g b3JkZXIgdG8KICAgICAgICAgIGVuc3VyZSB0aGF0IHRoZSBzZWN1cml0eSBnb2FscyBjYW4gYmUg bWV0LjwvdD4KCiAgICAgICAgICA8dD5TZWN1cml0eSBEZXNjcmlwdGlvbnMgaXMgdGhlIG1vc3Qg Y29tbW9ubHkgZGVwbG95ZWQga2V5aW5nCiAgICAgICAgICBzb2x1dGlvbiBmb3IgU0lQLWJhc2Vk IGVuZC1wb2ludHMsIHdoZXJlIGFsbW9zdCBhbGwgZW5kLXBvaW50cyB0aGF0IHN1cHBvcnQKICAg ICAgICAgIFNSVFAgYWxzbyBzdXBwb3J0IFNlY3VyaXR5IERlc2NyaXB0aW9ucy48L3Q+CiAgICAg ICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0iS2V5IE1hbmFnZW1lbnQgZm9y IFNSVFA6IEVuY3J5cHRlZCBLZXkgVHJhbnNwb3J0Ij4KICAgICAgICAgIDx0Pjx4cmVmIHRhcmdl dD0iSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWVrdCI+RW5jcnlwdGVkIEtleSBUcmFuc3BvcnQKICAg ICAgICAgIChFS1QpPC94cmVmPiBpcyBhbiBTUlRQIGV4dGVuc2lvbiB0aGF0IGVuYWJsZXMgZ3Jv dXAga2V5aW5nIGRlc3BpdGUKICAgICAgICAgIHVzaW5nIGEga2V5aW5nIG1lY2hhbmlzbSBsaWtl IERUTFMtU1JUUAogICAgICAgICAgdGhhdCBkb2Vzbid0IHN1cHBvcnQgZ3JvdXAga2V5cy4gSXQg aXMgZGVzaWduZWQgZm9yIGNlbnRyYWxpemVkIGNvbmZlcmVuY2luZywgYnV0IGNhbiBhbHNvCiAg ICAgICAgICBiZSB1c2VkIGluIHNlc3Npb25zIHdoZXJlIGVuZC1wb2ludHMgY29ubmVjdCB0byBh IGNvbmZlcmVuY2UKICAgICAgICAgIGJyaWRnZSBvciBhIGdhdGV3YXksIGFuZCBuZWVkIHRvIGJl IHByb3Zpc2lvbmVkIHdpdGggdGhlIGtleXMgZWFjaAogICAgICAgICAgcGFydGljaXBhbnQgb24g dGhlIGJyaWRnZSBvciBnYXRld2F5IHVzZXMgdG8gYXZvaWQgZGVjcnlwdGlvbi9lbmNyeXB0aW9u IGN5Y2xlcyBvbiB0aGUgYnJpZGdlIG9yIGdhdGV3YXkuIFRoaXMgY2FuIGVuYWJsZQogICAgICAg ICAgaW50ZXJ3b3JraW5nIGJldHdlZW4gRFRMUy1TUlRQIGFuZCBmb3IgZXhhbXBsZSBzZWN1cml0 eSBkZXNjcmlwdGlvbnMKICAgICAgICAgIG9yIG90aGVyIGtleWluZyBzeXN0ZW1zIHdoZXJlIGVp dGhlciBwYXJ0IGNhbiBzZXQgdGhlIGtleS48L3Q+CgogICAgICAgICAgPHQ+VGhlIG1lY2hhbmlz bSBpcyBiYXNlZCBvbiBlc3RhYmxpc2hpbmcgYW4gYWRkaXRpb25hbCBFS1Qga2V5CiAgICAgICAg ICB3aGljaCBldmVyeW9uZSB1c2VzIHRvIHByb3RlY3QgdGhlaXIgYWN0dWFsIHNlc3Npb24ga2V5 LiBUaGUgYWN0dWFsCiAgICAgICAgICBzZXNzaW9uIGtleSBpcyBzZW50IGluIGEgZXhwYW5kZWQg YXV0aGVudGljYXRpb24gdGFnIHRvIHRoZSBvdGhlcgogICAgICAgICAgc2Vzc2lvbiBwYXJ0aWNp cGFudHMuIFRoaXMga2V5IGlzIG9ubHkgc2VudCBvY2Nhc2lvbmFsbHkgb3IKICAgICAgICAgIHBl cmlvZGljYWxseSBkZXBlbmRpbmcgb24gdXNlIGNhc2VzIGFuZCBkZXBlbmRpbmcgb24gd2hhdCBy ZXF1aXJlbWVudHMKICAgICAgICAgIGV4aXN0IGZvciB0aW1lbHkgZGVsaXZlcnkgb3Igbm90aWZp Y2F0aW9uLjwvdD4KCiAgICAgICAgICA8dD5UaGUgb25seSBrbm93biBkZXBsb3ltZW50IG9mIEVL VCBzbyBmYXIgYXJlIGluIHNvbWUgQ2lzY28gVmlkZW8KICAgICAgICAgIENvbmZlcmVuY2luZyBw cm9kdWN0cy48L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0i S2V5IE1hbmFnZW1lbnQgZm9yIFNSVFA6IE90aGVyIHN5c3RlbXMiPgogICAgICAgICAgPHQ+VGhl IDx4cmVmIHRhcmdldD0iUkZDNjE4OSI+WlJUUDwveHJlZj4ga2V5LW1hbmFnZW1lbnQgc3lzdGVt IGZvcgogICAgICAgICAgU1JUUCB3YXMgcHJvcG9zZWQgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gRFRM Uy1TUlRQLiBJdCB3YXNuJ3QgYWRvcHRlZAogICAgICAgICAgYXMgYW4gSUVURiBzdGFuZGFyZHMg dHJhY2sgcHJvdG9jb2wsIGJ1dCB3YXMgaW5zdGVhZCBwdWJsaXNoZWQgYXMgYW4KICAgICAgICAg IGluZm9ybWF0aW9uYWwgUkZDLjwvdD4KCiAgICAgICAgICA8dD5BZGRpdGlvbmFsIHByb3ByaWV0 YXJ5IHNvbHV0aW9ucyBhcmUgYWxzbyBrbm93biB0byBleGlzdC48L3Q+CgogICAgICAgICAgPCEt LSBEYW4gV2luZyBzdWdnZXN0ZWQgbWVudGlvbmluZyBNaWNyb3NvZnQncyBNUy1TU1JUUCBoZXJl CiAgICAgICAgaHR0cDovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2NjNDMxNTA2 JTI4dj1vZmZpY2UuMTIlMjkuYXNweAogICAgICAgIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQncyBh IHN1ZmZpY2llbnRseSBzdGFibGUgcmVmZXJlbmNlLiBbY3NwXSAtLT4KICAgICAgICA8L3NlY3Rp b24+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJSVFAgTGVnYWN5IENv bmZpZGVudGlhbGl0eSI+CiAgICAgICAgPHQ+U2VjdGlvbiA5IG9mIHRoZSBSVFAgc3RhbmRhcmQg PHhyZWYgdGFyZ2V0PSJSRkMzNTUwIi8+IGRlZmluZXMgYQogICAgICAgIERFUyBvciAzREVTIGJh c2VkIGVuY3J5cHRpb24gb2YgUlRQIGFuZCBSVENQIHBhY2tldHMuIFRoaXMgbWVjaGFuaXNtCiAg ICAgICAgaXMga2V5ZWQgdXNpbmcgcGxhaW4gdGV4dCBrZXlzIGluIDx4cmVmIHRhcmdldD0iUkZD NDU2NiI+U0RQPC94cmVmPgogICAgICAgIHVzaW5nIHRoZSAiaz0iIFNEUCBmaWVsZC4gVGhpcyBt ZXRob2Qgb2YgcHJvdmlkaW5nIGNvbmZpZGVudGlhbGl0eSBoYXMKICAgICAgICBleHRyZW1lbHkg d2VhayBzZWN1cml0eSBwcm9wZXJ0aWVzIGFuZCBpcyBub3QgcmVjb21tZW5kZWQuPC90PgogICAg ICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iSVBzZWMiPgogICAgICAgIDx0Pjx4 cmVmIHRhcmdldD0iUkZDNDMwMSI+SVBzZWM8L3hyZWY+IGNhbiBiZSB1c2VkIGluZGVwZW5kZW50 IG9mIG1vZGUKICAgICAgICB0byBwcm90ZWN0IFJUUCBhbmQgUlRDUCBwYWNrZXRzIGluIHRyYW5z aXQgZnJvbSBvbmUgbmV0d29yayBpbnRlcmZhY2UKICAgICAgICB0byBhbm90aGVyLiBUaGlzIGNh biBiZSBzdWZmaWNpZW50IHdoZW4gdGhlIG5ldHdvcmsgaW50ZXJmYWNlcyBoYXZlIGEKICAgICAg ICBkaXJlY3QgcmVsYXRpb24sIG9yIGluIGEgc2VjdXJlZCBlbnZpcm9ubWVudCB3aGVyZSBpdCBj YW4gYmUKICAgICAgICBjb250cm9sbGVkIHdobyBjYW4gcmVhZCB0aGUgcGFja2V0cyBmcm9tIHRo b3NlIGludGVyZmFjZXMuPC90PgoKICAgICAgICA8dD5UaGUgbWFpbiBjb25jZXJuIHdpdGggdXNp bmcgSVBzZWMgdG8gcHJvdGVjdCBSVFAgdHJhZmZpYyBpcyB0aGF0IGluCiAgICAgICAgbW9zdCBj YXNlcyB1c2luZyBhIFZQTiBhcHByb2FjaCB0aGF0IHRlcm1pbmF0ZXMgdGhlIHNlY3VyaXR5CiAg ICAgICAgYXNzb2NpYXRpb24gYXQgc29tZSBub2RlIHByaW9yIHRvIHRoZSBSVFAgZW5kLXBvaW50 IGxlYXZlcyB0aGUgdHJhZmZpYwogICAgICAgIHZ1bG5lcmFibGUgdG8gYXR0YWNrIGJldHdlZW4g dGhlIFZQTiB0ZXJtaW5hdGlvbiBub2RlIGFuZCB0aGUKICAgICAgICBlbmQtcG9pbnQuIFRodXMg dXNhZ2Ugb2YgSVBzZWMgcmVxdWlyZXMgY2FyZWZ1bCB0aG91Z2h0IGFuZCBkZXNpZ24gb2YKICAg ICAgICBpdHMgdXNhZ2Ugc28gdGhhdCBpdCBtZWV0cyB0aGUgc2VjdXJpdHkgZ29hbHMuIEEgaW1w b3J0YW50CiAgICAgICAgcXVlc3Rpb24gaXMgaG93IG9uZSBlbnN1cmVzIHRoZSBJUHNlYyB0ZXJt aW5hdGluZyBwZWVyIGFuZCB0aGUgdWx0aW1hdGUKICAgICAgICBkZXN0aW5hdGlvbiBhcmUgdGhl IHNhbWUuPC90PgoKICAgICAgICA8dD5JUHNlYyB3aXRoIFJUUCBpcyBtb3JlIGNvbW1vbmx5IHVz ZWQgYXMgYSBzZWN1cml0eSBzb2x1dGlvbiBiZXR3ZWVuCiAgICAgICAgY2VudHJhbCBub2RlcyBp biBhbiBpbmZyYXN0cnVjdHVyZSB0aGF0IGV4Y2hhbmdlcyBtYW55IFJUUCBzZXNzaW9ucwogICAg ICAgIGFuZCBtZWRpYSBzdHJlYW1zIGJldHdlZW4gdGhlIHBlZXJzLiBUaGUgZXN0YWJsaXNobWVu dCBvZiBhIHNlY3VyZQogICAgICAgIHR1bm5lbCBiZXR3ZWVuIHRoZXNlIHBlZXJzIG1pbmltaXpl cyB0aGUga2V5LW1hbmFnZW1lbnQgb3ZlcmhlYWQKICAgICAgICBiZXR3ZWVuIHRoZXNlIHR3byBi b3hlcy48L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJEVExTIj4K ICAgICAgICA8dD48eHJlZiB0YXJnZXQ9IlJGQzYzNDciPkRhdGFncmFtIFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eSAoRFRMUykKICAgICAgICA8L3hyZWY+IGNhbiBwcm92aWRlIHBvaW50LXRvLXBv aW50IHNlY3VyaXR5IGZvciBSVFAgZmxvd3MuIFRoZSB0d28KICAgICAgICBwZWVycyBlc3RhYmxp c2ggYW4gRFRMUyBhc3NvY2lhdGlvbiBiZXR3ZWVuIGVhY2ggb3RoZXIsCiAgICAgICAgaW5jbHVk aW5nIHRoZSBwb3NzaWJpbGl0eSB0byBkbyBjZXJ0aWZpY2F0ZS1iYXNlZCBzb3VyY2UKICAgICAg ICBhdXRoZW50aWNhdGlvbiB3aGVuIGVzdGFibGlzaGluZyB0aGUgYXNzb2NpYXRpb24uIEFsbCBS VFAgYW5kIFJUQ1AKICAgICAgICBwYWNrZXRzIGZsb3dpbmcgd2lsbCBiZSBwcm90ZWN0ZWQgYnkg dGhpcyBEVExTIGFzc29jaWF0aW9uLjwvdD4KCiAgICAgICAgPHQ+Tm90ZTogdXNpbmcgRFRMUyBm b3IgUlRQIGZsb3dzIGlzIGRpZmZlcmVudCB0aGFuIHVzaW5nIERUTFMtU1JUUCBrZXkgbWFuYWdl bWVudC4KICAgICAgICBEVExTLVNSVFAgaGFzIHRoZSBjb3JlIGtleS1tYW5hZ2VtZW50IHN0ZXBz IGluIGNvbW1vbiB3aXRoIERUTFMsIGJ1dAogICAgICAgIERUTFMtU1JUUCB1c2VzIFNSVFAgZm9y IHRoZSBwZXIgcGFja2V0IHNlY3VyaXR5IG9wZXJhdGlvbnMsIHdoaWxlIERUTFMKICAgICAgICB1 c2VzIHRoZSBub3JtYWwgZGF0YWdyYW0gVExTIGRhdGEgcHJvdGVjdGlvbi4gV2hlbiB1c2luZyBE VExTLCBSVFAgYW5kCiAgICAgICAgUlRDUCBwYWNrZXRzIGFyZSBjb21wbGV0ZWx5IGVuY3J5cHRl ZCB3aXRoIG5vIGhlYWRlcnMgaW4gdGhlIGNsZWFyLAogICAgICAgIHdoaWxlIERUTFMtU1JUUCBs ZWF2ZXMgdGhlIGhlYWRlcnMgaW4gdGhlIGNsZWFyLjwvdD4KCiAgICAgICAgPHQ+RFRMUyBjYW4g dXNlIHNpbWlsYXIgdGVjaG5pcXVlcyB0byB0aG9zZSBhdmFpbGFibGUgZm9yIERUTFMtU1JUUCB0 bwogICAgICAgIGJpbmQgYSBzaWduYWxsaW5nLXNpZGUgYWdyZWVtZW50IHRvIGNvbW11bmljYXRl IHRvIHRoZSBjZXJ0aWZpY2F0ZXMKICAgICAgICB1c2VkIGJ5IHRoZSBlbmQtcG9pbnQgd2hlbiBk b2luZyB0aGUgRFRMUyBoYW5kc2hha2UuIFRoaXMgZW5hYmxlcyB1c2UKICAgICAgICB3aXRob3V0 IGhhdmluZyBhIGNlcnRpZmljYXRlLWJhc2VkIHRydXN0IGNoYWluIHRvIGEgdHJ1c3RlZAogICAg ICAgIGNlcnRpZmljYXRlIHJvb3QuPC90PgoKICAgICAgICA8dD5UaGVyZSBkb2VzIG5vdCBhcHBl YXIgdG8gYmUgc2lnbmlmaWNhbnQgdXNhZ2Ugb2YgUlRQIG92ZXIgRFRMUy48L3Q+CiAgICAgIDwv c2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJUTFMgb3ZlciBUQ1AiPgogICAgICAgIDx0 PldoZW4gUlRQIGlzIHNlbnQgb3ZlciA8eHJlZiB0YXJnZXQ9IlJGQzQ1NzEiPlRDUDwveHJlZj4g aXQgY2FuIGFsc28KICAgICAgICBiZSBzZW50IG92ZXIgPHhyZWYgdGFyZ2V0PSJSRkM0NTcyIj5U TFMgb3ZlciBUQ1A8L3hyZWY+LCB1c2luZyBUTFMgdG8KICAgICAgICBwcm92aWRlIHBvaW50IHRv IHBvaW50IHNlY3VyaXR5IHNlcnZpY2VzLiBUaGUgc2VjdXJpdHkgcHJvcGVydGllcyBUTFMKICAg ICAgICBwcm92aWRlcyBhcmUgY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBh bmQgcG9zc2libGUgc291cmNlCiAgICAgICAgYXV0aGVudGljYXRpb24gaWYgdGhlIGNsaWVudCBv ciBzZXJ2ZXIgY2VydGlmaWNhdGVzIGFyZSB2ZXJpZmllZCBhbmQKICAgICAgICBwcm92aWRlIGEg dXNhYmxlIGlkZW50aXR5LiBXaGVuIHVzZWQgaW4gbXVsdGktcGFydHkgc2NlbmFyaW9zIHVzaW5n IGEKICAgICAgICBjZW50cmFsIG5vZGUgZm9yIG1lZGlhIGRpc3RyaWJ1dGlvbiwgdGhlIHNlY3Vy aXR5IHByb3ZpZGUgaXMgb25seQogICAgICAgIGJldHdlZW4gdGhlIGNlbnRyYWwgbm9kZSBhbmQg dGhlIHBlZXJzLCBzbyB0aGUgc2VjdXJpdHkgcHJvcGVydGllcwogICAgICAgIGZvciB0aGUgd2hv bGUgc2Vzc2lvbiBhcmUgZGVwZW5kZW50IG9uIHdoYXQgdHJ1c3Qgb25lIGNhbiBwbGFjZSBpbiB0 aGUKICAgICAgICBjZW50cmFsIG5vZGUuPC90PgoKICAgICAgICA8dD48eHJlZiB0YXJnZXQ9IlJG QzIzMjYiPlJUU1AgMS4wPC94cmVmPiBhbmQgPHhyZWYKICAgICAgICB0YXJnZXQ9IkktRC5pZXRm LW1tdXNpYy1yZmMyMzI2YmlzIj4yLjA8L3hyZWY+IHNwZWNpZmllcyB0aGUgdXNhZ2Ugb2YKICAg ICAgICBSVFAgb3ZlciB0aGUgc2FtZSBUTFMvVENQIGNvbm5lY3Rpb24gdGhhdCB0aGUgUlRTUCBt ZXNzYWdlcyBhcmUgc2VudAogICAgICAgIG92ZXIuIEl0IGFwcGVhcnMgdGhhdCBSVFAgb3ZlciBU TFMvVENQIGlzIGFsc28gdXNlZCBpbiBzb21lIHByb3ByaWV0YXJ5CiAgICAgICAgc29sdXRpb25z IHRoYXQgdXNlcyBUTFMgdG8gYnlwYXNzIGZpcmV3YWxscy48L3Q+CiAgICAgIDwvc2VjdGlvbj4K CiAgICAgIDxzZWN0aW9uIHRpdGxlPSJQYXlsb2FkLW9ubHkgU2VjdXJpdHkgTWVjaGFuaXNtcyI+ CiAgICAgICAgPHQ+TWVjaGFuaXNtcyBoYXZlIGJlZW4gZGVmaW5lZCB0aGF0IGVuY3J5cHQgb25s eSB0aGUgcGF5bG9hZCBvZiB0aGUKICAgICAgICBSVFAgcGFja2V0cywgYW5kIGxlYXZlIHRoZSBS VFAgaGVhZGVycyBhbmQgUlRDUCBpbiB0aGUgY2xlYXIuIFRoZXJlCiAgICAgICAgYXJlIHNldmVy YWwgcmVhc29ucyB3aHkgdGhpcyBtaWdodCBiZSBhcHByb3ByaWF0ZSwgYnV0IGEgY29tbW9uCiAg ICAgICAgcmF0aW9uYWxlIGlzIHRvIGVuc3VyZSB0aGF0IHRoZSBjb250ZW50IHN0b3JlZCBpbiBS VFAgaGludCB0cmFja3MgaW4KICAgICAgICBSVFNQIHN0cmVhbWluZyBzZXJ2ZXJzIGhhcyB0aGUg bWVkaWEgY29udGVudCBpbiBhIHByb3RlY3RlZCBmb3JtYXQKICAgICAgICB0aGF0IGNhbm5vdCBi ZSByZWFkIGJ5IHRoZSBzdHJlYW1pbmcgc2VydmVyICh0aGlzIGlzIG1vc3RseSBkb25lIGluCiAg ICAgICAgdGhlIGNvbnRleHQgb2YgRGlnaXRhbCBSaWdodHMgTWFuYWdlbWVudCkuIFRoZXNlIGFw cHJvYWNoZXMgdGhlbiB1c2UKICAgICAgICBhIGtleS1tYW5hZ2VtZW50IHNvbHV0aW9uIGJldHdl ZW4gdGhlIHJpZ2h0cyBwcm92aWRlciBhbmQgdGhlCiAgICAgICAgY29uc3VtaW5nIGNsaWVudCB0 byBkZWxpdmVyIHRoZSBrZXkgdXNlZCB0byBwcm90ZWN0IHRoZSBjb250ZW50CiAgICAgICAgYW5k IGRvCiAgICAgICAgbm90IGluY2x1ZGUgdGhlIG1lZGlhIHNlcnZlciBpbiB0aGUgc2VjdXJpdHkg Y29udGV4dC4gU3VjaCBtZXRob2RzCiAgICAgICAgaGF2ZSBzZXZlcmFsIHNlY3VyaXR5IHdlYWtu ZXNzZXMgc3VjaCB0aGUgZmFjdCB0aGF0IHRoZSBzYW1lIGtleSBpcwogICAgICAgIGhhbmRlZCBv dXQgdG8gYSBwb3RlbnRpYWxseSBsYXJnZSBncm91cCBvZiByZWNlaXZpbmcgY2xpZW50cywKICAg ICAgICBpbmNyZWFzaW5nIHRoZSByaXNrIG9mIGEgbGVhay48L3Q+CgogICAgICAgIDx0PlVzZSBv ZiB0aGlzIHR5cGUgb2Ygc29sdXRpb24gY2FuIGJlIG9mIGludGVyZXN0IGluIGVudmlyb25tZW50 cwogICAgICAgIHRoYXQgYWxsb3cgbWlkZGxlYm94ZXMgdG8gcmV3cml0ZSB0aGUgUlRQIGhlYWRl cnMgYW5kIHNlbGVjdCB3aGljaAogICAgICAgIHN0cmVhbXMgYXJlIGRlbGl2ZXJlZCB0byBhbiBl bmQtcG9pbnQgKGUuZy4sIHNvbWUgdHlwZXMgb2YKICAgICAgICBjZW50cmFsaXNlZCB2aWRlbyBj b25mZXJlbmNlIHN5c3RlbXMpLiBUaGUgYWR2YW50YWdlIG9mIGVuY3J5cHRpbmcgYW5kCiAgICAg ICAgcG9zc2libHkgaW50ZWdyaXR5IHByb3RlY3RpbmcgdGhlIHBheWxvYWQgYnV0IG5vdCB0aGUg aGVhZGVycyBpcyB0aGF0CiAgICAgICAgdGhlIG1pZGRsZWJveCBjYW4ndCBlYXZlc2Ryb3Agb24g dGhlIG1lZGlhIGNvbnRlbnQsIGJ1dCBjYW4gc3RpbGwKICAgICAgICBwcm92aWRlIHN0cmVhbSBz d2l0Y2hpbmcgZnVuY3Rpb25hbGl0eS4gVGhlIGRvd25zaWRlIG9mIHN1Y2ggYSBzeXN0ZW0KICAg ICAgICBpcyB0aGF0IGl0IGxpa2VseSBuZWVkcyB0d28gbGV2ZWxzIG9mIHNlY3VyaXR5OiB0aGUg cGF5bG9hZCBsZXZlbAogICAgICAgIHNvbHV0aW9uIHRvIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5 IGFuZCBzb3VyY2UgYXV0aGVudGljYXRpb24sIGFuZCBhCiAgICAgICAgc2Vjb25kIGxheWVyIHdp dGggYWRkaXRpb25hbCB0cmFuc3BvcnQgc2VjdXJpdHkgZW5zdXJpbmcgc291cmNlCiAgICAgICAg YXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBvZiB0aGUgUlRQIGhlYWRlcnMgYXNzb2NpYXRl ZCB3aXRoIHRoZQogICAgICAgIGVuY3J5cHRlZCBwYXlsb2Fkcy4gVGhpcyBjYW4gYWxzbyByZXN1 bHRzIGluIHRoZSBuZWVkIHRvIGhhdmUgdHdvCiAgICAgICAgZGlmZmVyZW50IGtleS1tYW5hZ2Vt ZW50IHN5c3RlbXMgYXMgdGhlIGVudGl0eSBwcm90ZWN0aW5nIHRoZSBwYWNrZXRzCiAgICAgICAg YW5kIHBheWxvYWRzIGFyZSBkaWZmZXJlbnQgd2l0aCBkaWZmZXJlbnQgc2V0IG9mIGtleXMuPC90 PgoKICAgICAgICA8dD5UaGUgYXNwZWN0IG9mIHR3byB0aWVycyBvZiBzZWN1cml0eSBhcmUgcHJl c2VudCBpbiBJU01BY3J5cCAoc2VlCiAgICAgICAgPHhyZWYgdGFyZ2V0PSJzZWMtaXNtYSIvPikg YW5kIHRoZSBkZXByZWNhdGVkIDx4cmVmCiAgICAgICAgdGFyZ2V0PSJUM0dQUC4yNi4yMzRSOCI+ M0dQUCBQYWNrZXQgQmFzZWQgU3RyZWFtaW5nIFNlcnZpY2UKICAgICAgICBBbm5leC5LPC94cmVm PiBzb2x1dGlvbi48L3Q+CgogICAgICAgIDxzZWN0aW9uIGFuY2hvcj0ic2VjLWlzbWEiIHRpdGxl PSJJU01BIEVuY3J5cHRpb24gYW5kIEF1dGhlbnRpY2F0aW9uIj4KICAgICAgICAgIDx0PlRoZSBJ bnRlcm5ldCBTdHJlYW1pbmcgTWVkaWEgQWxsaWFuY2UgKElTTUEpIGhhcyBkZWZpbmVkIDx4cmVm CiAgICAgICAgICB0YXJnZXQ9IklTTUFDcnlwdDIiPklTTUEgRW5jcnlwdGlvbiBhbmQgQXV0aGVu dGljYXRpb24gMi4wPC94cmVmPi4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVz IGhvdyBvbmUgZW5jcnlwdHMgYW5kIHBhY2tldGl6ZXMgdGhlCiAgICAgICAgICBlbmNyeXB0ZWQg YXBwbGljYXRpb24gZGF0YSB1bml0cyAoQURVcykgaW4gYW4gUlRQIHBheWxvYWQgdXNpbmcgdGhl CiAgICAgICAgICA8eHJlZiB0YXJnZXQ9IlJGQzM2NDAiPk1QRUctNCBHZW5lcmljIHBheWxvYWQg Zm9ybWF0PC94cmVmPi4gVGhlIEFEVQogICAgICAgICAgdHlwZXMgdGhhdCBhcmUgYWxsb3dlZCBh cmUgdGhvc2UgdGhhdCBjYW4gYmUgc3RvcmVkIGFzIGVsZW1lbnRhcnkKICAgICAgICAgIHN0cmVh bXMgaW4gYW4gSVNPIE1lZGlhIEZpbGUgZm9ybWF0IGJhc2VkIGZpbGUuIElTTUFjcnlwIHVzZXMg U1JUUAogICAgICAgICAgZm9yIHBhY2tldCBsZXZlbCBpbnRlZ3JpdHkgYW5kIHNvdXJjZSBhdXRo ZW50aWNhdGlvbiBmcm9tIGEKICAgICAgICAgIHN0cmVhbWluZyBzZXJ2ZXIgdG8gdGhlIHJlY2Vp dmVyLjwvdD4KCiAgICAgICAgICA8dD5LZXktbWFuYWdlbWVudCBmb3IgYSBJU01BQ3J5cCBiYXNl ZCBzeXN0ZW0gY2FuIGJlIGFjaGlldmVkCiAgICAgICAgICB0aHJvdWdoIDx4cmVmIHRhcmdldD0i T01BRFJNdjIiPk9wZW4gTW9iaWxlIEFsbGlhbmNlIChPTUEpIERpZ2l0YWwKICAgICAgICAgIFJp Z2h0cyBNYW5hZ2VtZW50IDIuMDwveHJlZj4sIGZvciBleGFtcGxlLjwvdD4KICAgICAgICA8L3Nl Y3Rpb24+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNo b3I9InNlYy1hcHBsaWNhdGlvbnMiIHRpdGxlPSJTZWN1cmluZyBSVFAgQXBwbGljYXRpb25zIj4K ICAgICAgPHQ+SW4gdGhlIGZvbGxvd2luZyB3ZSBwcm92aWRlIGd1aWRlbGluZXMgZm9yIGhvdyB0 byBjaG9vc2UgYXBwcm9wcmlhdGUKICAgICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBmb3IgUlRQIGFw cGxpY2F0aW9ucy48L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iQXBwbGljYXRpb24gUmVxdWly ZW1lbnRzIj4KICAgICAgICA8dD5UaGlzIHNlY3Rpb24gZGlzY3Vzc2VzIGEgbnVtYmVyIG9mIGFw cGxpY2F0aW9uIHJlcXVpcmVtZW50cyB0aGF0CiAgICAgICAgbmVlZCBiZSBjb25zaWRlcmVkLiBB biBhcHBsaWNhdGlvbiBkZXNpZ25lciBjaG9vc2luZyBzZWN1cml0eQogICAgICAgIHNvbHV0aW9u cyByZXF1aXJlcyBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiB3aGF0IGxldmVsIG9mIHNlY3VyaXR5 IGlzCiAgICAgICAgbmVlZGVkIGFuZCB3aGF0IGJlaGF2aW91ciB0aGV5IHN0cml2ZSB0byBhY2hp ZXZlLjwvdD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IkNvbmZpZGVudGlhbGl0eSI+CiAgICAg ICAgICA8dD5XaGVuIGl0IGNvbWVzIHRvIGNvbmZpZGVudGlhbGl0eSBvZiBhbiBSVFAgc2Vzc2lv biB0aGVyZSBhcmUKICAgICAgICAgIHNldmVyYWwgYXNwZWN0cyB0byBjb25zaWRlcjo8bGlzdCBz dHlsZT0iaGFuZ2luZyI+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlByb2JhYmlsaXR5IG9m IGNvbXByb21pc2U6Ij5XaGVuIHVzaW5nIGVuY3J5cHRpb24KICAgICAgICAgICAgICB0byBwcm92 aWRlIG1lZGlhIGNvbmZpZGVudGlhbGl0eSwgaXQgaXMgbmVjZXNzYXJ5IHRvIGhhdmUgc29tZQog ICAgICAgICAgICAgIHJvdWdoIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5IGdvYWwgYW5k IGhvdyBsb25nIG9uZSBleHBlY3QKICAgICAgICAgICAgICB0aGUgcHJvdGVjdGVkIGNvbnRlbnQg dG8gcmVtYWluIGNvbmZpZGVudGlhbC4gTmF0aW9uYWwgb3Igb3RoZXIKICAgICAgICAgICAgICBy ZWd1bGF0aW9ucyBtaWdodCBwcm92aWRlZCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBvbiBhCiAg ICAgICAgICAgICAgcGFydGljdWxhciB1c2FnZSBvZiBhbiBSVFAuIEZyb20gdGhhdCwgb25lIGNh biBkZXRlcm1pbmUgd2hpY2gKICAgICAgICAgICAgICBlbmNyeXB0aW9uIGFsZ29yaXRobXMgYXJl IHRvIGJlIHVzZWQgZnJvbSB0aGUgc2V0IG9mIGF2YWlsYWJsZQogICAgICAgICAgICAgIHRyYW5z Zm9ybXMuPC90PgoKICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0iUG90ZW50aWFsIGZvciBvdGhl ciBsZWFrYWdlOiI+UlRQIGJhc2VkIHNlY3VyaXR5IGluCiAgICAgICAgICAgICAgbW9zdCBvZiBp dHMgZm9ybXMgc2ltcGx5IHdyYXBzIFJUUCBhbmQgUlRDUCBwYWNrZXRzIGludG8KICAgICAgICAg ICAgICBjcnlwdG9ncmFwaGljIGNvbnRhaW5lcnMuIFRoaXMgY29tbW9ubHkgbWVhbnMgdGhhdCB0 aGUgc2l6ZSBvZgogICAgICAgICAgICAgIHRoZSBvcmlnaW5hbCBSVFAgcGF5bG9hZCwgYW5kIGRl dGFpbHMgb2YgdGhlIFJUUCBhbmQgUlRDUAogICAgICAgICAgICAgIGhlYWRlcnMsIGFyZSB2aXNp YmxlIHRvIG9ic2VydmVycyBvZiB0aGUgcHJvdGVjdGVkIHBhY2tldCBmbG93LgogICAgICAgICAg ICAgIFRoaXMgY2FuIHByb3ZpZGUgaW5mb3JtYXRpb24gdG8gdGhvc2Ugb2JzZXJ2ZXJzLiBBIHdl bGwtCiAgICAgICAgICAgICAgZG9jdW1lbnRlZCBjYXNlIGlzIHRoZSByaXNrIHdpdGggdmFyaWFi bGUgYml0LXJhdGUgc3BlZWNoIGNvZGVjcwogICAgICAgICAgICAgIHRoYXQgcHJvZHVjZSBkaWZm ZXJlbnQgc2l6ZWQgcGFja2V0cyBiYXNlZCBvbiB0aGUgc3BlZWNoIGlucHV0CiAgICAgICAgICAg ICAgPHhyZWYgdGFyZ2V0PSJSRkM2NTYyIi8+LiBQb3RlbnRpYWwgdGhyZWF0cyBzdWNoIGFzIHRo ZXNlIG5lZWQKICAgICAgICAgICAgICB0byBiZSBjb25zaWRlcmVkIGFuZCwgaWYgdGhleSBhcmUg c2lnbmlmaWNhbnQsIHRoZW4gcmVzdHJpY3Rpb25zCiAgICAgICAgICAgICAgd2lsbCBiZSBuZWVk ZWQgb24gbW9kZSBjaG9pY2VzIGluIHRoZSBjb2RlYywgb3IgYWRkaXRpb25hbAogICAgICAgICAg ICAgIHBhZGRpbmcgd2lsbCBuZWVkIHRvIGJlIGFkZGVkIHRvIG1ha2UgYWxsIHBhY2tldHMgZXF1 YWwgc2l6ZSBhbmQKICAgICAgICAgICAgICByZW1vdmUgdGhlIGluZm9ybWF0aW9uYWwgbGVha2Fn ZS48L3Q+CgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSIiPkFub3RoZXIgY2FzZSBpcyBSVFAg aGVhZGVyIGV4dGVuc2lvbnMuIElmIFNSVFAgaXMKICAgICAgICAgICAgICB1c2VkLCBoZWFkZXIg ZXh0ZW5zaW9ucyBhcmUgbm9ybWFsbHkgbm90IHByb3RlY3RlZCBieSB0aGUKICAgICAgICAgICAg ICBzZWN1cml0eSBtZWNoYW5pc20gcHJvdGVjdGluZyB0aGUgUlRQIHBheWxvYWQuIElmIHRoZSBo ZWFkZXIKICAgICAgICAgICAgICBleHRlbnNpb24gY2FycmllcyBpbmZvcm1hdGlvbiB0aGF0IGlz IGNvbnNpZGVyZWQgc2Vuc2l0aXZlLCB0aGVuCiAgICAgICAgICAgICAgdGhlIGFwcGxpY2F0aW9u IG5lZWRzIHRvIGJlIG1vZGlmaWVkIHRvIGVuc3VyZSB0aGF0IG1lY2hhbmlzbXMKICAgICAgICAg ICAgICB1c2VkIHRvIHByb3RlY3QgYWdhaW5zdCBzdWNoIGluZm9ybWF0aW9uIGxlYWthZ2UgYXJl CiAgICAgICAgICAgICAgZW1wbG95ZWQuPC90PgoKICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0i V2hvIGhhcyBhY2Nlc3M6Ij5XaGVuIGNvbnNpZGVyaW5nIHRoZQogICAgICAgICAgICAgIGNvbmZp ZGVudGlhbGl0eSBwcm9wZXJ0aWVzIG9mIGEgc3lzdGVtLCBpdCBpcyBpbXBvcnRhbnQgdG8KICAg ICAgICAgICAgICBjb25zaWRlciB3aGVyZSB0aGUgbWVkaWEgaGFuZGxlZCBpbiB0aGUgY2xlYXIu IEZvciBleGFtcGxlLCBpZgogICAgICAgICAgICAgIHRoZSBzeXN0ZW0gaXMgYmFzZWQgb24gYW4g UlRQIG1peGVyIHRoYXQgbmVlZHMgdGhlIGtleXMgdG8KICAgICAgICAgICAgICBkZWNyeXB0IHRo ZSBtZWRpYSwgcHJvY2VzcywgYW5kIHJlcGFja2V0aXplIGl0LCB0aGVuIGlzIHRoZQogICAgICAg ICAgICAgIG1peGVyIHByb3ZpZGluZyB0aGUgc2VjdXJpdHkgZ3VhcmFudGVlcyBleHBlY3RlZCBi eSB0aGUgb3RoZXIKICAgICAgICAgICAgICBwYXJ0cyBvZiB0aGUgc3lzdGVtPyBGdXJ0aGVybW9y ZSwgaXQgaXMgaW1wb3J0YW50IHRvIGNvbnNpZGVyCiAgICAgICAgICAgICAgd2hvIGhhcyBhY2Nl c3MgdG8gdGhlIGtleXMuCiAgICAgICAgICAgICAgVGhlIHBvbGljaWVzIGZvciB0aGUgaGFuZGxp bmcgb2YgdGhlIGtleXMsIGFuZCB3aG8KICAgICAgICAgICAgICBjYW4gYWNjZXNzIHRoZSBrZXlz LCBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGFsb25nIHdpdGggdGhlCiAgICAgICAgICAgICAgY29u ZmlkZW50aWFsaXR5IGdvYWxzLjwvdD4KICAgICAgICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAg ICA8dD5BcyBjYW4gYmUgc2VlbiB0aGUgYWN0dWFsIGNvbmZpZGVudGlhbGl0eSBsZXZlbCBoYXMg bGlrZWx5IG1vcmUKICAgICAgICAgIHRvIGRvIHdpdGggdGhlIGFwcGxpY2F0aW9uJ3MgdXNhZ2Ug b2YgY2VudHJhbGl6ZWQgbm9kZXMsIGFuZCB0aGUKICAgICAgICAgIGRldGFpbHMgb2YgdGhlIGtl eS1tYW5hZ2VtZW50IHNvbHV0aW9uIGNob3NlbiwgdGhhbiB3aXRoIHRoZSBhY3R1YWwKICAgICAg ICAgIGNob2ljZSBvZiBlbmNyeXB0aW9uIGFsZ29yaXRobSAoYWx0aG91Z2gsIG9mIGNvdXJzZSwg dGhlIGVuY3J5cHRpb24KICAgICAgICAgIGFsZ29yaXRobSBuZWVkcyB0byBiZSBjaG9zZW4gYXBw cm9wcmlhdGVseSBmb3IgdGhlIGRlc2lyZWQgc2VjdXJpdHkKICAgICAgICAgIGxldmVsKS48L3Q+ CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0iSW50ZWdyaXR5Ij4K ICAgICAgICAgIDx0PlByb3RlY3Rpb24gYWdhaW5zdCBtb2RpZmljYXRpb24gb2YgY29udGVudCBi eSBhIHRoaXJkIHBhcnR5LCBvcgogICAgICAgICAgZHVlIHRvIGVycm9ycyBpbiB0aGUgbmV0d29y aywgaXMgYW5vdGhlciBmYWN0b3IgdG8gY29uc2lkZXIuIFRoZQogICAgICAgICAgZmlyc3QgYXNw ZWN0IHRoYXQgb25lIGNvbnNpZGVycyBpcyB3aGF0IHJlc2lsaWVuY2Ugb25lIGhhcyBhZ2FpbnN0 CiAgICAgICAgICBtb2RpZmljYXRpb25zIHRvIHRoZSBjb250ZW50LiBUaGlzIGNhbiBhZmZlY3Qg d2hhdCBjcnlwdG9ncmFwaGljCiAgICAgICAgICBhbGdvcml0aG0gaXMgdXNlZCwgYW5kIHRoZSBs ZW5ndGggb2YgdGhlIGludGVncml0eSB0YWdzLiBIb3dldmVyCiAgICAgICAgICBlcXVhbGx5LCBp bXBvcnRhbnQgaXMgdG8gY29uc2lkZXIgd2hvIGlzIHByb3ZpZGluZyB0aGUgaW50ZWdyaXR5CiAg ICAgICAgICBhc3NlcnRpb24sIHdoYXQgaXMgdGhlIHNvdXJjZSBvZiB0aGUgaW50ZWdyaXR5IHRh ZywgYW5kIHdoYXQgYXJlIHRoZQogICAgICAgICAgcmlza3Mgb2YgbW9kaWZpY2F0aW9ucyBoYXBw ZW5pbmcgcHJpb3IgdG8gdGhhdCBwb2ludCB3aGVyZQogICAgICAgICAgcHJvdGVjdGlvbiBpcyBh cHBsaWVkPyBSVFAgYXBwbGljYXRpb25zIHRoYXQgcmVseSBvbiBjZW50cmFsIG5vZGVzCiAgICAg ICAgICBuZWVkIHRvIGNvbnNpZGVyIGlmIGhvcC1ieS1ob3AgaW50ZWdyaXR5IGlzIGFjY2VwdGFi bGUsIG9yIGlmIHRydWUKICAgICAgICAgIGVuZC10by1lbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24g aXMgbmVlZGVkPyBJcyBpdCBpbXBvcnRhbnQgdG8gYmUKICAgICAgICAgIGFibGUgdG8gdGVsbCBp ZiBhIG1pZGRsZWJveCBoYXMgbW9kaWZpZWQgdGhlIGRhdGE/IFRoZXJlIGFyZSBzb21lCiAgICAg ICAgICB1c2VzIG9mIFJUUCB0aGF0IHJlcXVpcmUgdHJ1c3RlZCBtaWRkbGVib3hlcyB0aGF0IGNh biBtb2RpZnkgdGhlCiAgICAgICAgICBkYXRhIGluIGEgd2F5IHRoYXQgZG9lc24ndCBicmVhayBp bnRlZ3JpdHkgcHJvdGVjdGlvbiBhcyBzZWVuIGJ5IHRoZQogICAgICAgICAgcmVjZWl2ZXIsIGZv ciBleGFtcGxlIGxvY2FsIGFkdmVydGlzZW1lbnQgaW5zZXJ0aW9uIGluIElQVFYgc3lzdGVtczsK ICAgICAgICAgIHRoZXJlIGFyZSBhbHNvIHVzZXMgd2hlcmUgaXQgaXMgZXNzZW50aWFsIHRoYXQg c3VjaCBpbi1uZXR3b3JrCiAgICAgICAgICBtb2RpZmljYXRpb24gYmUgZGV0ZWN0YWJsZS4gUlRQ IGNhbiBzdXBwb3J0IGJvdGgsIHdpdGggYXBwcm9wcmlhdGUKICAgICAgICAgIGNob2ljZXMgb2Yg c2VjdXJpdHkgbWVjaGFuaXNtcy48L3Q+CgogICAgICAgICAgPHQ+SW50ZWdyaXR5IG9mIHRoZSBk YXRhIGlzIGNvbW1vbmx5IGNsb3NlbHkgdGllZCB0byB0aGUgcXVlc3Rpb24gb2YKICAgICAgICAg IHNvdXJjZSBhdXRoZW50aWNhdGlvbi4gVGhhdCBpcywgaXQgYmVjb21lcyBpbXBvcnRhbnQgdG8g a25vdyB3aG8KICAgICAgICAgIG1ha2VzIGFuIGludGVncml0eSBhc3NlcnRpb24gZm9yIHRoZSBk YXRhLjwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJTb3Vy Y2UgQXV0aGVudGljYXRpb24iPgogICAgICAgICAgPHQ+U291cmNlIGF1dGhlbnRpY2F0aW9uIGlz IGFib3V0IGRldGVybWluaW5nIHdobyBzZW50IGEgcGFydGljdWxhcgogICAgICAgICAgUlRQIG9y IFJUQ1AgcGFja2V0LiBJdCBpcyBub3JtYWxseSBjbG9zZWx5IHRpZWQgd2l0aCBpbnRlZ3JpdHks CiAgICAgICAgICBzaW5jZSB5b3UgYWxzbyB3YW50IHRvIGVuc3VyZSB0aGF0IHdoYXQgeW91IHJl Y2VpdmVkIGlzIHdoYXQgdGhlCiAgICAgICAgICBjbGFpbWVkIHNvdXJjZSByZWFsbHkgc2VudCwg c28gc291cmNlIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQKICAgICAgICAgIGludGVncml0eSBpcyBu b3QgcGFydGljdWxhcmx5IHVzZWZ1bC4gU2ltaWxhcmx5LAogICAgICAgICAgaW50ZWdyaXR5IHdp dGhvdXQgc291cmNlIGF1dGhlbnRpY2F0aW9uIGlzCiAgICAgICAgICBhbHNvIG5vdCBwYXJ0aWN1 bGFyIHVzZWZ1bDsgeW91IG5lZWQgdG8ga25vdyB3aG8gY2xhaW1zIHRoaXMgcGFja2V0CiAgICAg ICAgICB3YXNuJ3QgY2hhbmdlZC48L3Q+CgogICAgICAgICAgPHQ+U291cmNlIGF1dGhlbnRpY2F0 aW9uIGNhbiBiZSBhc3NlcnRlZCBpbiBzZXZlcmFsIGRpZmZlcmVudCB3YXlzOgogICAgICAgICAg PGxpc3Qgc3R5bGU9ImhhbmdpbmciPgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJCYXNlIGxl dmVsOiI+VXNpbmcgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc21zIHRoYXQKICAgICAgICAgICAgICBn aXZlIGF1dGhlbnRpY2F0aW9uIHdpdGggc29tZSB0eXBlIG9mIGtleS1tYW5hZ2VtZW50IHByb3Zp ZGVzIGFuCiAgICAgICAgICAgICAgaW1wbGljaXQgbWV0aG9kIGZvciBzb3VyY2UgYXV0aGVudGlj YXRpb24uIEFzc3VtaW5nIHRoYXQgdGhlCiAgICAgICAgICAgICAgbWVjaGFuaXNtIGhhcyBzdWZm aWNpZW50IHN0cmVuZ3RoIHRvIG5vdCBiZSBjaXJjdW12ZW50ZWQgaW4gdGhlCiAgICAgICAgICAg ICAgdGltZSBmcmFtZSB3aGVuIHlvdSB3b3VsZCBhY2NlcHQgdGhlIHBhY2tldCBhcyB2YWxpZCwg aXQgaXMKICAgICAgICAgICAgICBwb3NzaWJsZSB0byBhc3NlcnQgYSBzb3VyY2UtYXV0aGVudGlj YXRlZCBzdGF0ZW1lbnQ7IHRoaXMKICAgICAgICAgICAgICBtZXNzYWdlIGlzIGxpa2VseSBmcm9t IHNvbWVvbmUgdGhhdCBoYXMgdGhlCiAgICAgICAgICAgICAgY3J5cHRvZ3JhcGhpYyBrZXkocykg dG8gdGhpcyBjb21tdW5pY2F0aW9uLjwvdD4KCiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IiI+ V2hhdCB0aGF0IGFzc2VydGlvbiBhY3R1YWxseSBtZWFucyBpcyBoaWdobHkKICAgICAgICAgICAg ICBkZXBlbmRlbnQgb24gdGhlIGFwcGxpY2F0aW9uIGFuZCBob3cgaXQgaGFuZGxlcyB0aGUga2V5 cy4gSW4gYW4KICAgICAgICAgICAgICBhcHBsaWNhdGlvbiB3aGVyZSB0aGUga2V5LWhhbmRsaW5n IGlzIGxpbWl0ZWQgdG8gdHdvIHBlZXJzLCB0aGlzCiAgICAgICAgICAgICAgY2FuIGZvcm0gYSBi YXNpcyBmb3IgYSB0cnVzdCByZWxhdGlvbnNoaXAgdG8gdGhlIGxldmVsIHRoYXQgeW91CiAgICAg ICAgICAgICAgY2FuIHN0YXRlIGFzIHRoZSB0cmFmZmljIGlzIGF1dGhlbnRpY2F0ZWQgYW5kIG1h dGNoaW5nIHRoaXMKICAgICAgICAgICAgICBwYXJ0aWN1bGFyIGNvbnRleHQuIFRodXMsIGl0IGlz IGNvbWluZyBlaXRoZXIgZnJvbSBtZSBvciBmcm9tIG15CiAgICAgICAgICAgICAgcGVlciAoYXNz dW1pbmcgdGhhdCBuZWl0aGVyIGhhcyBzaGFyZWQgdGhlIGtleSB3aXRoIGFueW9uZQogICAgICAg ICAgICAgIGVsc2UpLiBIb3dldmVyLCBpbiBhIG11bHRpLXBhcnR5IHNjZW5hcmlvIHdoZXJlIHNl Y3VyaXR5CiAgICAgICAgICAgICAgY29udGV4dHMgYXJlIHNoYXJlZCBhbW9uZyBwYXJ0aWNpcGFu dHMsIG1vc3QgYmFzZS1sZXZlbAogICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHNvbHV0aW9u cyBjYW4ndCBldmVuIGFzc2VydCB0aGF0IHRoaXMgcGFja2V0IGlzCiAgICAgICAgICAgICAgZnJv bSB0aGUgc2FtZSBzb3VyY2UgYXMgdGhlIHByZXZpb3VzIHBhY2tldC48L3Q+CgogICAgICAgICAg ICAgIDx0IGhhbmdUZXh0PSJCaW5kaW5nIHRoZSBTb3VyY2U6Ij5BIHN0ZXAgdXAgaW4gdGhlIGFz c2VydGlvbgogICAgICAgICAgICAgIHRoYXQgY2FuIGJlIGRvbmUgaW4gYmFzZS1sZXZlbCBzeXN0 ZW1zIGlzIHRvIHRpZSB0aGUgc2lnbmFsbGluZwogICAgICAgICAgICAgIHRvIHRoZSBrZXktZXhj aGFuZ2UuIEhlcmUsIHRoZSBnb2FsIGlzIHRvIGF0IGxlYXN0IGJlIGFibGUgdG8KICAgICAgICAg ICAgICBhc3NlcnQgdGhhdCB0aGUgc2VuZGVyIG9mIHRoZSBwYWNrZXRzIGlzIHRoZSBzYW1lIGVu dGl0eSB0aGF0IEkKICAgICAgICAgICAgICBoYXZlIGVzdGFibGlzaGVkIHRoZSBzZXNzaW9uIHdp dGguIEZlYXNpYmxpdHkgaWYgdGhpcyBkZXBlbmRzCiAgICAgICAgICAgICAgb24gdGhlIHByb3Bl cnRpZXMgb2YgdGhlIGtleS1tYW5hZ2VtZW50IHN5c3RlbSB1c2VkLCB0aGUgYWJpbGl0eQogICAg ICAgICAgICAgIHRvIHRpZSB0aGUgc2lnbmFsbGluZyB0byBhIHBhcnRpY3VsYXIgcGVlciwgYW5k IHdoYXQgdHJ1c3QgeW91CiAgICAgICAgICAgICAgcGxhY2Ugb24gdGhlIGRpZmZlcmVudCBub2Rl cyBpbnZvbHZlZC48L3Q+CgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSIiPkZvciBleGFtcGxl LCBjb25zaWRlciBhIHBvaW50LXRvLXBvaW50CiAgICAgICAgICAgICAgY29tbXVuaWNhdGlvbiBz eXN0ZW0gdGhhdCB1c2VzIERUTFMtU1JUUCB1c2luZyBzZWxmLXNpZ25lZAogICAgICAgICAgICAg IGNlcnRpZmljYXRlcyBmb3Iga2V5IG1hbmFnZW1lbnQgYW5kIFNJUCBmb3Igc2lnbmFsbGluZy4g SW4gc3VjaAogICAgICAgICAgICAgIGEgc3lzdGVtIHRoZSBlbmQtcG9pbnRzIGZvciB0aGUgRFRM Uy1TUlRQIGhhbmRzaGFrZSBoYXZlCiAgICAgICAgICAgICAgc2VjdXJlbHktZXN0YWJsaXNoZWQg a2V5cyB0aGF0IGFyZSBub3QgdmlzaWJsZSB0byB0aGUgc2lnbmFsbGluZwogICAgICAgICAgICAg IG5vZGVzLiBIb3dldmVyLCBhcyB0aGUgY2VydGlmaWNhdGVzIHVzZWQgYnkgRFRMUyBhcmUgbm90 IGJvdW5kIHRvCiAgICAgICAgICAgICAgYW55IFBLSSwgdGhleSBjYW4ndCBiZSB2ZXJpZmllZC4g SW5zdGVhZCwgaGFzaGVzIG9mIHRoZQogICAgICAgICAgICAgIGNlcnRpZmljYXRlIGFyZSBzZW50 IG92ZXIgdGhlIHNpZ25hbGxpbmcgcGF0aC4gSWYgdGhlIHNpZ25hbGxpbmcKICAgICAgICAgICAg ICBjYW4gYmUgdHJ1c3RlZCBub3QgdG8gY29sbGFib3JhdGUgb24gcGVyZm9ybWluZyBhIG1hbi1p bi10aGUtCiAgICAgICAgICAgICAgbWlkZGxlIGF0dGFjayBieSBtb2RpZnlpbmcgdGhlIGhhc2hl cywgdGhlbiB0aGUgZW5kLXBvaW50cyBjYW4KICAgICAgICAgICAgICB2ZXJpZnkgdGhhdCB0aGV5 IGhhdmUgZXN0YWJsaXNoZWQga2V5cyB3aXRoIHRoZSBwZWVyIHRoZXkgYXJlCiAgICAgICAgICAg ICAgZG9pbmcgc2lnbmFsbGluZyB3aXRoLjwvdD4KCiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9 IiI+U3lzdGVtcyB3aGVyZSB0aGUga2V5LWV4Y2hhbmdlIGlzIGRvbmUgdXNpbmcgdGhlCiAgICAg ICAgICAgICAgc2lnbmFsbGluZyBzeXN0ZW1zLCBzdWNoIGFzIDx4cmVmIHRhcmdldD0iUkZDNDU2 OCI+U2VjdXJpdHkKICAgICAgICAgICAgICBEZXNjcmlwdGlvbnM8L3hyZWY+IG9yIDx4cmVmIHRh cmdldD0iUkZDNDU2NyI+TUlLRVkgZW1iZWRkZWQgaW4KICAgICAgICAgICAgICBTRFA8L3hyZWY+ LCBlbmFibGUgYSBkaXJlY3QgYmluZGluZyBiZXR3ZWVuIHNpZ25hbGxpbmcgYW5kCiAgICAgICAg ICAgICAga2V5LWV4Y2hhbmdlLiBJbmRlcGVuZGVudCBvZiBEVExTLVNSVFAgb3IgTUlLRVkgaW4g U0RQLCB0aGUKICAgICAgICAgICAgICBhY3R1YWwgc2VjdXJpdHkgZGVwZW5kcyBvbiB0aGUgdHJ1 c3Qgb25lIGNhbiBwbGFjZSBpbiB0aGUKICAgICAgICAgICAgICBzaWduYWxsaW5nIHN5c3RlbSB0 byBjb3JyZWN0bHkgYXNzb2NpYXRlIHRoZSBwZWVyJ3MgaWRlbnRpdHkKICAgICAgICAgICAgICB3 aXRoIHRoZSBrZXktZXhjaGFuZ2UuPC90PgoKICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0iVXNp bmcgSWRlbnRpdGllczoiPklmIHRoZSBhcHBsaWNhdGlvbnMgaGF2ZSBhY2Nlc3MKICAgICAgICAg ICAgICB0byBhIHN5c3RlbSB0aGF0IGNhbiBwcm92aWRlIHZlcmlmaWFibGUgaWRlbnRpdGllcywg dGhlbiB0aGUKICAgICAgICAgICAgICBzb3VyY2UgYXV0aGVudGljYXRpb24gY2FuIGJlIGJvdW5k IHRvIHRoYXQgaWRlbnRpdHkuIEZvcgogICAgICAgICAgICAgIGV4YW1wbGUsIGluIGEgcG9pbnQt dG8tcG9pbnQgY29tbXVuaWNhdGlvbiBldmVuIHN5bW1ldHJpYyBrZXkKICAgICAgICAgICAgICBj cnlwdG8sIHdoZXJlIHRoZSBrZXktbWFuYWdlbWVudCBjYW4gYXNzZXJ0IHRoYXQgdGhlIGtleSBo YXMKICAgICAgICAgICAgICBvbmx5IGJlZW4gZXhjaGFuZ2VkIHdpdGggYSBwYXJ0aWN1bGFyIGlk ZW50aXR5LCBjYW4gcHJvdmlkZSBhCiAgICAgICAgICAgICAgc3Ryb25nIGFzc2VydGlvbiBhYm91 dCB3aG8gaXMgc2VuZGluZyB0aGUgdHJhZmZpYy48L3Q+CgogICAgICAgICAgICAgIDx0IGhhbmdU ZXh0PSIiPk5vdGUgdGhhdCBhbGwgbGV2ZWxzIG9mIHRoZSBzeXN0ZW0gbXVjaCBoYXZlCiAgICAg ICAgICAgICAgbWF0Y2hpbmcgY2FwYWJpbGl0eSB0byBhc3NlcnQgaWRlbnRpdHkuIEhhdmluZyB0 aGUgc2lnbmFsbGluZwogICAgICAgICAgICAgIGFzc2VydCB0aGF0IHlvdSBpbmNsdWRlIGEgcGFy dGljdWxhciBpZGVudGl0eSBpbiBhIG11bHRpLXBhcnR5CiAgICAgICAgICAgICAgY29tbXVuaWNh dGlvbiBzZXNzaW9uIHdoZXJlIHRoZSBrZXktbWFuYWdlbWVudCBzeXN0ZW1zIGVzdGFibGlzaAog ICAgICAgICAgICAgIGtleXMgaW4gYSB3YXkgdGhhdCBvbmUgY2FuIGFzc2VydCB0aGF0IG9ubHkg dGhlIGdpdmVuIGlkZW50aXR5CiAgICAgICAgICAgICAgaGFzIHJlY2VpdmVkIHRoZSBrZXkuIFVz aW5nIGEgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGJ1aWx0IG9uIGEKICAgICAgICAgICAgICBn cm91cCBrZXkgdGhhdCBvdGhlcndpc2UgY2FuJ3QgcHJvdmlkZSBhbnkgYXNzZXJ0aW9uIGFib3V0 IHdobyBzZW50CiAgICAgICAgICAgICAgdGhlIHRyYWZmaWMgb3RoZXIgdGhhbiBhbnlvbmUgdGhh dCBnb3QgdGhlIGtleSwgcHJvdmlkZXMgbm8gc3Ryb25nZXIKICAgICAgICAgICAgICBhc3NlcnRp b24gb24gdGhlIG1lZGlhIGxldmVsIHRoYW46IFNvbWVvbmUgdGhhdCBoYXMgZ290dGVuIHRoZQog ICAgICAgICAgICAgIHNlY3VyaXR5IGNvbnRleHQgKGtleSkgc2VudCB0aGlzIHRyYWZmaWMuPC90 PgogICAgICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgICAgIDx0Lz4KICAgICAgICA8L3NlY3Rp b24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJJZGVudGl0eSI+CiAgICAgICAgICA8dD5UaGVy ZSBleGlzdCBtYW55IGRpZmZlcmVudCB0eXBlcyBvZiBpZGVudGl0eSBzeXN0ZW1zIHdpdGgKICAg ICAgICAgIGRpZmZlcmVudCBwcm9wZXJ0aWVzLiBCdXQgaW4gdGhlIGNvbnRleHQgb2YgUlRQIGFw cGxpY2F0aW9ucywgdGhlCiAgICAgICAgICBtb3N0IGltcG9ydGFudCBwcm9wZXJ0eSBpcyB0aGUg cG9zc2liaWxpdHkgdG8gcGVyZm9ybSBzb3VyY2UKICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIGFu ZCB2ZXJpZnkgc3VjaCBhc3NlcnRpb25zIGluIHJlbGF0aW9uIHRvIGFueSBjbGFpbWVkCiAgICAg ICAgICBpZGVudGl0aWVzLiBXaGF0IGFuIGlkZW50aXR5IHJlYWxseSBpcyBjYW4gYWxzbyB2YXJ5 IGJ1dCwgaW4gdGhlCiAgICAgICAgICBjb250ZXh0IG9mIGNvbW11bmljYXRpb24sIG9uZSBvZiB0 aGUgbW9zdCBvYnZpb3VzIGlzIHRoZSBpZGVudGl0eSBvZgogICAgICAgICAgdGhlIGh1bWFuIHVz ZXIgb25lIGNvbW11bmljYXRlcyB3aXRoLiBIb3dldmVyLCB0aGUgaHVtYW4gdXNlciBjYW4KICAg ICAgICAgIGFsc28gaGF2ZSBhZGRpdGlvbmFsIGlkZW50aXRpZXMgaW4gYSBwYXJ0aWN1bGFyIHJv bGUuIEZvciBleGFtcGxlLAogICAgICAgICAgdGhlIGh1bWFuIEFsaWNlLCBjYW4gYWxzbyBiZSBh IHBvbGljZSBvZmZpY2VyIGFuZCBpbiBzb21lIGNhc2VzIGhlcgogICAgICAgICAgaWRlbnRpdHkg YXMgcG9saWNlIG9mZmljZXIgd2lsbCBiZSBtb3JlIHJlbGV2YW50IHRoZW4gdGhhdCBzaGUgaXMK ICAgICAgICAgIEFsaWNlLiBUaGlzIGlzIGNvbW1vbiBpbiBjb250YWN0IHdpdGggb3JnYW5pemF0 aW9ucywgd2hlcmUgaXQgaXMKICAgICAgICAgIGltcG9ydGFudCB0byBwcm92ZSB0aGUgcGVyc29u cyByaWdodCB0byByZXByZXNlbnQgdGhlCiAgICAgICAgICBvcmdhbml6YXRpb24uPC90PgoKICAg ICAgICAgIDx0PlNvbWUgZXhhbXBsZXMgb2YgaWRlbnRpdHkgbWVjaGFuaXNtcyB0aGF0IG1heSBi ZSB1c2VkOjxsaXN0CiAgICAgICAgICAgICAgc3R5bGU9ImhhbmdpbmciPgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSJDZXJ0aWZpY2F0ZSBiYXNlZDoiPkEgY2VydGlmaWNhdGUgaXMgdXNlZCB0 byBwcm92ZQogICAgICAgICAgICAgIHRoZSBpZGVudGl0eSwgYnkgaGF2aW5nIGFjY2VzcyB0byB0 aGUgcHJpdmF0ZSBwYXJ0IG9mIHRoZQogICAgICAgICAgICAgIGNlcnRpZmljYXRlIG9uZSBjYW4g cGVyZm9ybSBzaWduaW5nIHRvIGFzc2VydCBvbmVzIGlkZW50aXR5LiBBbnkKICAgICAgICAgICAg ICBlbnRpdHkgaW50ZXJlc3RlZCBpbiB2ZXJpZnlpbmcgdGhlIGFzc2VydGlvbiB0aGVuIG5lZWRz IHRoZQogICAgICAgICAgICAgIHB1YmxpYyBwYXJ0IG9mIHRoZSBjZXJ0aWZpY2F0ZS4gQnkgaGF2 aW5nIHRoZSBjZXJ0aWZpY2F0ZSwgb25lCiAgICAgICAgICAgICAgY2FuIHZlcmlmeSB0aGUgc2ln bmluZyBhZ2FpbnN0IHRoZSBjZXJ0aWZpY2F0ZS4gVGhlIG5leHQgc3RlcCBpcwogICAgICAgICAg ICAgIHRvIGRldGVybWluZSBpZiBvbmUgdHJ1c3RzIHRoZSBjZXJ0aWZpY2F0ZSdzIHRydXN0IGNo YWluLgogICAgICAgICAgICAgIENvbW1vbmx5IGJ5IHByb3Zpc2lvbmluZyB0aGUgdmVyaWZpZXIg d2l0aCB0aGUgcHVibGljIHBhcnQgb2YgYQogICAgICAgICAgICAgIHJvb3QgY2VydGlmaWNhdGUs IHRoaXMgZW5hYmxlcyB0aGUgdmVyaWZpZXIgdG8gdmVyaWZ5IGEgdHJ1c3QKICAgICAgICAgICAg ICBjaGFpbiBmcm9tIHRoZSByb290IGNlcnRpZmljYXRlIGRvd24gdG8gdGhlIGlkZW50aXR5CiAg ICAgICAgICAgICAgY2VydGlmaWNhdGUuIEhvd2V2ZXIsIHRoZSB0cnVzdCBpcyBiYXNlZCBvbiBh bGwgc3RlcHMgaW4KICAgICAgICAgICAgICB0aGUgY2VydGlmaWNhdGUgY2hhaW4gYmVpbmcgdmVy aWZpYWJsZSBhbmQgdHJ1c3RlZC4gVGh1cwogICAgICAgICAgICAgIHByb3Zpc2lvbmluZyBvZiBy b290IGNlcnRpZmljYXRlcyBhbmQgdGhlIGFiaWxpdHkgdG8gcmV2b2tlCiAgICAgICAgICAgICAg Y29tcHJvbWlzZWQgY2VydGlmaWNhdGVzIGFyZSBhc3BlY3RzIHRoYXQgd2lsbCByZXF1aXJlCiAg ICAgICAgICAgICAgaW5mcmFzdHJ1Y3R1cmUuPC90PgoKICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0iT25saW5lIElkZW50aXR5IFByb3ZpZGVyczoiPkFuIG9ubGluZSBpZGVudGl0eQogICAgICAg ICAgICAgIHByb3ZpZGVyIChJZFApIGNhbiBhdXRoZW50aWNhdGUgYSB1c2VyJ3MgcmlnaHQgdG8g dXNlIGFuCiAgICAgICAgICAgICAgaWRlbnRpdHksIHRoZW4gcGVyZm9ybSBhc3NlcnRpb25zIG9u IHRoZWlyIGJlaGFsZiBvciBwcm92aXNpb24KICAgICAgICAgICAgICB0aGUgcmVxdWVzdGVyIHdp dGggc2hvcnQtdGVybSBjcmVkZW50aWFscyB0byBhc3NlcnQgdGhlaXIKICAgICAgICAgICAgICBp ZGVudGl0eS4gVGhlIHZlcmlmaWVyIGNhbiB0aGVuIGNvbnRhY3QgdGhlIElkUCB0byByZXF1ZXN0 CiAgICAgICAgICAgICAgdmVyaWZpY2F0aW9uIG9mIGEgcGFydGljdWxhciBpZGVudGl0eS4gSGVy ZSB0aGUgdHJ1c3QgaXMgaGlnaGx5CiAgICAgICAgICAgICAgZGVwZW5kZW50IG9uIGhvdyBtdWNo IG9uZSB0cnVzdHMgdGhlIElkUC4gVGhlIHN5c3RlbSBhbHNvCiAgICAgICAgICAgICAgYmVjb21l cyBkZXBlbmRlbnQgb24gaGF2aW5nIGFjY2VzcyB0byB0aGUgcmVsZXZhbnQgSWRQLjwvdD4KICAg ICAgICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAgICA8dD5JbiBhbGwgb2YgdGhlIGFib3ZlIGV4 YW1wbGVzLCBhbiBpbXBvcnRhbnQgcGFydCBvZiB0aGUgc2VjdXJpdHkKICAgICAgICAgIHByb3Bl cnRpZXMgYXJlIHJlbGF0ZWQgdG8gdGhlIG1ldGhvZCBmb3IgYXV0aGVudGljYXRpbmcgdGhlIGFj Y2VzcwogICAgICAgICAgdG8gdGhlIGlkZW50aXR5LjwvdD4KICAgICAgICA8L3NlY3Rpb24+Cgog ICAgICAgIDxzZWN0aW9uIHRpdGxlPSJQcml2YWN5Ij4KICAgICAgICAgIDx0PlJUUCBhcHBsaWNh dGlvbnMgbmVlZCB0byBjb25zaWRlciB3aGF0IHByaXZhY3kgZ29hbHMgdGhleSBoYXZlLgogICAg ICAgICAgQXMgUlRQIGFwcGxpY2F0aW9ucyBjb21tdW5pY2F0ZSBkaXJlY3RseSBiZXR3ZWVuIHBl ZXJzIGluIG1hbnkKICAgICAgICAgIGNhc2VzLCB0aGUgSVAgYWRkcmVzc2VzIG9mIGFueSBjb21t dW5pY2F0aW9uIHBlZXIgd2lsbCBiZSBhdmFpbGFibGUuCiAgICAgICAgICBUaGUgbWFpbiBwcml2 YWN5IGNvbmNlcm4gd2l0aCBJUCBhZGRyZXNzZXMgaXMgcmVsYXRlZCB0bwogICAgICAgICAgZ2Vv Z3JhcGhpY2FsIGxvY2F0aW9uIGFuZCB0aGUgcG9zc2liaWxpdHkgdG8gdHJhY2sgYSB1c2VyIG9m IGFuCiAgICAgICAgICBlbmQtcG9pbnQuIFRoZSBtYWluIHdheSBvZiBhdm9pZCBzdWNoIGNvbmNl cm5zIGlzIHRoZSBpbnRyb2R1Y3Rpb24KICAgICAgICAgIG9mIHJlbGF5IG9yIGNlbnRyYWxpemVk IG1lZGlhIG1peGVycyBvciBmb3J3YXJkZXJzIHRoYXQgaGlkZXMgdGhlCiAgICAgICAgICBhZGRy ZXNzIG9mIGEgcGVlciBmcm9tIGFueSBvdGhlciBwZWVyLiBUaGUgc2VjdXJpdHkgYW5kIHRydXN0 IHBsYWNlZAogICAgICAgICAgaW4gdGhlc2UgcmVsYXlzIG9idmlvdXNseSBuZWVkcyB0byBiZSBj YXJlZnVsbHkgY29uc2lkZXJlZC48L3Q+CgogICAgICAgICAgPHQ+UlRQIGl0c2VsZiBjYW4gY29u dHJpYnV0ZSB0byBlbmFibGluZyBhIHBhcnRpY3VsYXIgdXNlciB0byBiZQogICAgICAgICAgdHJh Y2tlZCBiZXR3ZWVuIGNvbW11bmljYXRpb24gc2Vzc2lvbnMgaWYgdGhlIENOQU1FIGlzIGdlbmVy YXRlZAogICAgICAgICAgYWNjb3JkaW5nIHRvIHRoZSBSVFAgc3BlY2lmaWNhdGlvbiBpbiB0aGUg Zm9ybSBvZiB1c2VyQGhvc3QuIFN1Y2gKICAgICAgICAgIFJUQ1AgQ05BTUVzIGFyZSBsaWtlbHkg bG9uZyB0ZXJtIHN0YWJsZSBvdmVyIG11bHRpcGxlIHNlc3Npb25zLAogICAgICAgICAgYWxsb3dp bmcgdHJhY2tpbmcgb2YgdXNlcnMuIFRoaXMgY2FuIGJlIGRlc2lyYWJsZSBmb3IgbG9uZy10ZXJt CiAgICAgICAgICBmYXVsdCB0cmFja2luZyBhbmQgZGlhZ25vc2lzLCBidXQgY2xlYXJseSBoYXMg cHJpdmFjeSBpbXBsaWNhdGlvbnMuCiAgICAgICAgICBJbnN0ZWFkIGNyeXB0b2dyYXBoaWNhbGx5 IHJhbmRvbSBvbmVzIGNvdWxkIGJlIHVzZWQgYXMgZGVmaW5lZCBieQogICAgICAgICAgPHhyZWYg dGFyZ2V0PSJJLUQuaWV0Zi1hdnRjb3JlLTYyMjJiaXMiPkd1aWRlbGluZXMgZm9yIENob29zaW5n IFJUUAogICAgICAgICAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgQ2Fub25pY2FsIE5hbWVzIChD TkFNRXMpPC94cmVmPi48L3Q+CgogICAgICAgICAgPHQ+SWYgdGhlcmUgZXhpc3QgcHJpdmFjeSBn b2FscywgdGhlc2UgbmVlZCB0byBiZSBjb25zaWRlcmVkLCBhbmQKICAgICAgICAgIHRoZSBzeXN0 ZW0gZGVzaWduZWQgd2l0aCB0aGVtIGluIG1pbmQuIEluIGFkZGl0aW9uIGNlcnRhaW4gUlRQCiAg ICAgICAgICBmZWF0dXJlcyBtaWdodCBoYXZlIHRvIGJlIGNvbmZpZ3VyZWQgdG8gc2FmZWd1YXJk IHByaXZhY3ksIG9yIGhhdmUKICAgICAgICAgIHJlcXVpcmVtZW50cyBvbiBob3cgdGhlIGltcGxl bWVudGF0aW9uIGlzIGRvbmUuPC90PgogICAgICAgIDwvc2VjdGlvbj4KICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9IkFwcGxpY2F0aW9uIFN0cnVjdHVyZSI+CiAgICAgICAg PHQ+V2hlbiBpdCBjb21lcyB0byBSVFAgc2VjdXJpdHksIHRoZSBtb3N0IGFwcHJvcHJpYXRlIHNv bHV0aW9uIGlzCiAgICAgICAgb2Z0ZW4gaGlnaGx5IGRlcGVuZGVudCBvbiB0aGUgdG9wb2xvZ3kg b2YgdGhlIGNvbW11bmljYXRpb24gc2Vzc2lvbi4KICAgICAgICBUaGUgc2lnbmFsbGluZyBhbHNv IGltcGFjdHMgd2hhdCBpbmZvcm1hdGlvbiBjYW4gYmUgcHJvdmlkZWQsIGFuZCBpZgogICAgICAg IHRoaXMgY2FuIGJlIGluc3RhbmNlIHNwZWNpZmljLCBvciBjb21tb24gZm9yIGEgZ3JvdXAuIElu IHRoZSBlbmQgdGhlCiAgICAgICAga2V5LW1hbmFnZW1lbnQgc3lzdGVtIHdpbGwgaGlnaGx5IGFm ZmVjdCB0aGUgc2VjdXJpdHkgcHJvcGVydGllcwogICAgICAgIGFjaGlldmVkIGJ5IHRoZSBhcHBs aWNhdGlvbi4gQXQgdGhlIHNhbWUgdGltZSwgdGhlIGNvbW11bmljYXRpb24KICAgICAgICBzdHJ1 Y3R1cmUgb2YgdGhlIGFwcGxpY2F0aW9uIGxpbWl0cyB3aGF0IGtleSBtYW5hZ2VtZW50IG1ldGhv ZHMgYXJlCiAgICAgICAgYXBwbGljYWJsZS4gQXMgZGlmZmVyZW50IGtleS1tYW5hZ2VtZW50IGhh dmUgZGlmZmVyZW50IHJlcXVpcmVtZW50cyBvbgogICAgICAgIHVuZGVybHlpbmcgaW5mcmFzdHJ1 Y3R1cmUgaXQgaXMgaW1wb3J0YW50IHRvIHRha2UgdGhhdCBhc3BlY3QgaW50bwogICAgICAgIGNv bnNpZGVyYXRpb24gZWFybHkgaW4gdGhlIGRlc2lnbi48L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSJJbnRlcm9wZXJhYmlsaXR5Ij4KICAgICAgICA8dD5GZXcgUlRQ IGFwcGxpY2F0aW9ucyBleGlzdCBhcyBpbmRlcGVuZGVudCBhcHBsaWNhdGlvbnMgdGhhdCBuZXZl cgogICAgICAgIGludGVyb3BlcmF0ZSB3aXRoIGFueXRoaW5nIGVsc2UuIFJhdGhlciwgdGhleSBl bmFibGUgY29tbXVuaWNhdGlvbgogICAgICAgIHdpdGggYSBwb3RlbnRpYWxseSBsYXJnZSBudW1i ZXIgb2Ygb3RoZXIgc3lzdGVtcy4gVG8gbWluaW1pemUgdGhlCiAgICAgICAgbnVtYmVyIG9mIHNl Y3VyaXR5IG1lY2hhbmlzbXMgdGhhdCBuZWVkIHRvIGJlIGltcGxlbWVudGVkLCBpdCBpcwogICAg ICAgIGltcG9ydGFudCB0byBjb25zaWRlciBpZiBvbmUgY2FuIHVzZSB0aGUgc2FtZSBzZWN1cml0 eSBtZWNoYW5pc21zIGFzCiAgICAgICAgb3RoZXIgYXBwbGljYXRpb25zLiBUaGlzIGNhbiBhbHNv IHJlZHVjZSBwcm9ibGVtcyBvZiBkZXRlcm1pbmluZwogICAgICAgIHdoYXQgc2VjdXJpdHkgbGV2 ZWwgaXMgYWN0dWFsbHkgbmVnb3RpYXRlZCBpbiBhIHBhcnRpY3VsYXIKICAgICAgICBzZXNzaW9u LjwvdD4KCiAgICAgICAgPHQ+VGhlIGRlc2lyZSB0byBiZSBpbnRlcm9wZXJhYmxlIGNhbiwgaW4g c29tZSBjYXNlcywgYmUgaW4gY29uZmxpY3QKICAgICAgICB3aXRoIHRoZSBzZWN1cml0eSByZXF1 aXJlbWVudHMgb2YgYW4gYXBwbGljYXRpb24uIFRvIG1lZXQKICAgICAgICB0aGUgc2VjdXJpdHkg Z29hbHMsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8gc2FjcmlmaWNlCiAgICAgICAgaW50ZXJvcGVy YWJpbGl0eS4gQWx0ZXJuYXRpdmVseSwgb25lIGNhbiBpbXBsZW1lbnQgbXVsdGlwbGUgc2VjdXJp dHkKICAgICAgICBtZWNoYW5pc21zLCB0aGlzIGhvd2V2ZXIgaW50cm9kdWNlcyB0aGUgY29tcGxp Y2F0aW9uIG9mIGVuc3VyaW5nIHRoYXQgdGhlIHVzZXIKICAgICAgICB1bmRlcnN0YW5kcyB3aGF0 IGl0IG1lYW5zIHRvIHVzZSBhIHBhcnRpY3VsYXIgc2VjdXJpdHkgc3lzdGVtLiBJbgogICAgICAg IGFkZGl0aW9uLCB0aGUgYXBwbGljYXRpb24gY2FuIHRoZW4gYmVjb21lIHZ1bG5lcmFibGUgdG8g YmlkLWRvd24KICAgICAgICBhdHRhY2suPC90PgogICAgICA8L3NlY3Rpb24+CiAgICA8L3NlY3Rp b24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtZXhhbXBsZXMiIHRpdGxlPSJFeGFtcGxlcyI+ CiAgICAgIDx0PkluIHRoZSBmb2xsb3dpbmcgd2UgZGVzY3JpYmUgYSBudW1iZXIgb2YgZXhhbXBs ZSBzZWN1cml0eSBzb2x1dGlvbnMKICAgICAgZm9yIGFwcGxpY2F0aW9ucyB1c2luZyBSVFAgc2Vy dmljZXMgb3IgZnJhbWV3b3Jrcy4gVGhlc2UgZXhhbXBsZXMgYXJlCiAgICAgIHByb3ZpZGVkIHRv IGlsbHVzdHJhdGUgdGhlIGNob2ljZXMgYXZhaWxhYmxlLiBUaGV5IGFyZSBub3Qgbm9ybWF0aXZl CiAgICAgIHJlY29tbWVuZGF0aW9ucyBmb3Igc2VjdXJpdHkuPC90PgoKICAgICAgPHNlY3Rpb24g dGl0bGU9Ik1lZGlhIFNlY3VyaXR5IGZvciBTSVAtZXN0YWJsaXNoZWQgU2Vzc2lvbnMgdXNpbmcg RFRMUy1TUlRQIj4KICAgICAgICA8dD5UaGUgSUVURiBldmFsdWF0ZWQgbWVkaWEgc2VjdXJpdHkg Zm9yIFJUUCBzZXNzaW9ucyBlc3RhYmxpc2hlZAogICAgICAgIHVzaW5nIHBvaW50LXRvLXBvaW50 IFNJUCBzZXNzaW9ucyBpbiAyMDA5LiBBIG51bWJlciBvZiByZXF1aXJlbWVudHMKICAgICAgICB3 ZXJlIGRldGVybWluZWQsIGFuZCBiYXNlZCBvbiB0aG9zZSwgdGhlIGV4aXN0aW5nIHNvbHV0aW9u cyBmb3IgbWVkaWEKICAgICAgICBzZWN1cml0eSBhbmQgZXNwZWNpYWxseSB0aGUga2V5aW5nIG1l dGhvZHMgd2VyZSBhbmFseXNlZC4gVGhlCiAgICAgICAgcmVzdWx0aW5nIHJlcXVpcmVtZW50cyBh bmQgYW5hbHlzaXMgd2VyZSBwdWJsaXNoZWQgaW4gPHhyZWYKICAgICAgICB0YXJnZXQ9IlJGQzU0 NzkiLz4uIEJhc2VkIG9uIHRoaXMgYW5hbHlzaXMgYW5kIHdvcmtpbmctZ3JvdXAKICAgICAgICBk aXNjdXNzaW9uLCBEVExTLVNSVFAgd2FzIGRldGVybWluZWQgdG8gYmUgdGhlIGJlc3Qgc29sdXRp b24uCiAgICAgICAgVGhlIHNlY3VyaXR5IHNvbHV0aW9uIGZvciBTSVAgdXNpbmcgRFRMUy1TUlRQ IGlzIGRlZmluZWQgaW4gdGhlCiAgICAgICAgPHhyZWYgdGFyZ2V0PSJSRkM1NzYzIj5GcmFtZXdv cmsgZm9yIEVzdGFibGlzaGluZyBhIFNlY3VyZSBSZWFsLXRpbWUKICAgICAgICBUcmFuc3BvcnQg UHJvdG9jb2wgKFNSVFApIFNlY3VyaXR5IENvbnRleHQgVXNpbmcgRGF0YWdyYW0gVHJhbnNwb3J0 CiAgICAgICAgTGF5ZXIgU2VjdXJpdHkgKERUTFMpPC94cmVmPi48L3Q+CiAgICAgICAgCiAgICAg ICAgPHQ+T24gYSBoaWdoIGxldmVsIHRoZSBmcmFtZXdvcmsgdXNlcyBTSVAgd2l0aCBTRFAKICAg ICAgICBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcyB0byBleGNoYW5nZSB0aGUgbmV0d29yayBhZGRy ZXNzZXMgd2hlcmUgdGhlCiAgICAgICAgc2VydmVyIGVuZC1wb2ludCB3aWxsIGhhdmUgYSBEVExT LVNSVFAgZW5hYmxlIHNlcnZlciBydW5uaW5nLiBUaGUgU0lQCiAgICAgICAgc2lnbmFsbGluZyBp cyBhbHNvIHVzZWQgdG8gZXhjaGFuZ2UgdGhlIGZpbmdlcnByaW50cyBvZiB0aGUKICAgICAgICBj ZXJ0aWZpY2F0ZSBlYWNoIGVuZC1wb2ludCB3aWxsIHVzZSBpbiB0aGUgRFRMUyBlc3RhYmxpc2ht ZW50IHByb2Nlc3MuCiAgICAgICAgV2hlbiB0aGUgc2lnbmFsbGluZyBpcyBzdWZmaWNpZW50bHkg Y29tcGxldGVkLCB0aGUgRFRMUy1TUlRQIGNsaWVudAogICAgICAgIHBlcmZvcm1zIERUTFMgaGFu ZHNoYWtlcyBhbmQgZXN0YWJsaXNoZXMgU1JUUCBzZXNzaW9uIGtleXMuIFRoZQogICAgICAgIGNs aWVudHMgYWxzbyB2ZXJpZnkgdGhlIGZpbmdlcnByaW50cyBvZiB0aGUgY2VydGlmaWNhdGVzIHRv IHZlcmlmeQogICAgICAgIHRoYXQgbm8gbWFuIGluIHRoZSBtaWRkbGUgaGFzIGluc2VydGVkIHRo ZW1zZWx2ZXMgaW50byB0aGUKICAgICAgICBleGNoYW5nZS48L3Q+CgogICAgICAgIDx0PkF0IHRo ZSBiYXNpYyBsZXZlbCBEVExTIGhhcyBhIG51bWJlciBvZiBnb29kIHNlY3VyaXR5IHByb3BlcnRp ZXMuCiAgICAgICAgRm9yIGV4YW1wbGUsIHRvIGVuYWJsZSBhIG1hbiBpbiB0aGUgbWlkZGxlIHNv bWVvbmUgaW4gdGhlIHNpZ25hbGxpbmcKICAgICAgICBwYXRoIG5lZWRzIHRvIHBlcmZvcm0gYW4g YWN0aXZlIGFjdGlvbiBhbmQgbW9kaWZ5IHRoZSBzaWduYWxsaW5nCiAgICAgICAgbWVzc2FnZS4g VGhlcmUgYWxzbyBleGlzdHMgYSBzb2x1dGlvbiB0aGF0IGVuYWJsZXMgdGhlIGZpbmdlcnByaW50 cyB0bwogICAgICAgIGJlIGJvdW5kIHRvIGlkZW50aXRpZXMgZXN0YWJsaXNoZWQgYnkgdGhlIGZp cnN0IHByb3h5IGZvciBlYWNoIHVzZXIKICAgICAgICA8eHJlZiB0YXJnZXQ9IlJGQzQ5MTYiPiA8 L3hyZWY+LiBUaGlzIHJlZHVjZXMgdGhlIG51bWJlciBvZiBub2RlcyB0aGUKICAgICAgICBjb25u ZWN0aW5nIHVzZXIgVXNlciBBZ2VudCBoYXMgdG8gdHJ1c3QgdG8gaW5jbHVkZSBqdXN0IHRoZSBm aXJzdCBob3AgcHJveHksIHJhdGhlcgogICAgICAgIHRoYW4gdGhlIGZ1bGwgc2lnbmFsbGluZyBw YXRoLjwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9Ik1lZGlhIFNl Y3VyaXR5IGZvciBXZWJSVEMgU2Vzc2lvbnMiPgogICAgICAgIDx0Pjx4cmVmIHRhcmdldD0iSS1E LmlldGYtcnRjd2ViLW92ZXJ2aWV3Ij5XZWIgUmVhbC1UaW1lCiAgICAgICAgQ29tbXVuaWNhdGlv bjwveHJlZj4gaXMgYSBzb2x1dGlvbiBwcm92aWRpbmcgd2ViIGFwcGxpY2F0aW9ucyB3aXRoCiAg ICAgICAgcmVhbC10aW1lIG1lZGlhIGRpcmVjdGx5IGJldHdlZW4gYnJvd3NlcnMuIFRoZSBSVFAt dHJhbnNwb3J0ZWQKICAgICAgICByZWFsLXRpbWUgbWVkaWEgaXMgcHJvdGVjdGVkIHVzaW5nIGEg bWFuZGF0b3J5IGFwcGxpY2F0aW9uIG9mCiAgICAgICAgU1JUUC4gVGhlIGRlZmF1bHQga2V5aW5n IG9mIFNSVFAgaXMgZG9uZSB1c2luZyBEVExTLVNSVFAuIFRoZSBzZWN1cml0eQogICAgICAgIGNv bmZpZ3VyYXRpb24gaXMgZnVydGhlciBkZWZpbmVkIGluIHRoZSA8eHJlZgogICAgICAgIHRhcmdl dD0iSS1ELmlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2giPldlYlJUQyBTZWN1cml0eQogICAgICAg IEFyY2hpdGVjdHVyZTwveHJlZj4uPC90PgoKICAgICAgICA8dD5UaGUgcGVlcnMnIGhhc2ggb2Yg dGhlaXIgY2VydGlmaWNhdGVzIGFyZSBwcm92aWRlZCB0byBhIEphdmFzY3JpcHQKICAgICAgICBh cHBsaWNhdGlvbiB0aGF0IGlzIHBhcnQgb2YgYSBjbGllbnQtc2VydmVyIHN5c3RlbSBwcm92aWRp bmcKICAgICAgICByZW5kZXp2b3VzIHNlcnZpY2VzIGZvciB0aGUgb25lcyBhIGdpdmVuIHBlZXIg d2FudHMgdG8gY29tbXVuaWNhdGUKICAgICAgICB3aXRoLiBUaHVzLCB0aGUgaGFuZGxpbmcgb2Yg dGhlIGhhc2hlcyBiZXR3ZWVuIHRoZSBwZWVycyBpcyBub3Qgd2VsbAogICAgICAgIGRlZmluZWQ7 IGl0IGJlY29tZXMgYSBtYXR0ZXIgb2YgdHJ1c3QgaW4gdGhlIGFwcGxpY2F0aW9uLiBCdXQsIHVu bGVzcwogICAgICAgIHRoZSBhcHBsaWNhdGlvbiBhbmQgaXRzIHNlcnZlciBpcyBpbnRlbmRpbmcg dG8gY29tcHJvbWlzZSB0aGUKICAgICAgICBjb21tdW5pY2F0aW9uIHNlY3VyaXR5LCB0aGV5IGNh biBwcm92aWRlIGEgc2VjdXJlIGFuZCBpbnRlZ3JpdHktCiAgICAgICAgcHJvdGVjdGVkIGV4Y2hh bmdlIG9mIHRoZSBjZXJ0aWZpY2F0ZSBoYXNoZXMgdGh1cyBwcmV2ZW50aW5nIGFueQogICAgICAg IG1hbi1pbi10aGUtbWlkZGxlIChNSVRNKSBmcm9tIGluc2VydGluZyBpdHNlbGYgaW4gdGhlIGtl eS1leGNoYW5nZS48L3Q+CgogICAgICAgIDx0PgogICAgICAgIFVubGVzcyBvbmUgdXNlcyBhIElk ZW50aXR5IHByb3ZpZGVyIGFuZCB0aGUgcHJvcG9zZWQgPHhyZWYKICAgICAgICB0YXJnZXQ9Ikkt RC5pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoIj5pZGVudGl0eSBzb2x1dGlvbjwveHJlZj4uIFRo ZSB3ZWIgYXBwbGljYXRpb24gc3RpbGwgaGFzIHRoZSBwb3NzaWJpbGl0eSB0byBpbnNlcnQgYSBN SVRNLiBJbgogICAgICAgIHRoaXMgc29sdXRpb24gdGhlIElkZW50aXR5IFByb3ZpZGVyIHdoaWNo IGlzIGEgdGhpcmQgcGFydHkgdG8gdGhlCiAgICAgICAgd2ViIGFwcGxpY2F0aW9uIHNpZ25zIHRo ZSBEVExTLVNSVFAgaGFzaCBjb21iaW5lZCB3aXRoIGEgc3RhdGVtZW50IG9uCiAgICAgICAgd2hp Y2ggdXNlciBpZGVudGl0eSB0aGF0IGhhcyBiZWVuIHVzZWQgdG8gc2lnbiB0aGUgaGFzaC4gVGhl IHJlY2VpdmVyCiAgICAgICAgb2Ygc3VjaCBhIElkZW50aXR5IGFzc2VydGlvbiB0aGVuIGluZGVw ZW5kZW50bHkgdmVyaWZpZXMgdGhlIHVzZXIKICAgICAgICBpZGVudGl0eSB0byBlbnN1cmUgdGhh dCBpdCBpcyB0aGUgaWRlbnRpdHkgaXQgaW50ZW5kZWQgdG8gY29tbXVuaWNhdGUKICAgICAgICBh bmQgdGhhdCB0aGUgY3J5cHRvZ3JhcGhpYyBhc3NlcnRpb24gaG9sZHMuIFRoaXMgd2F5IGEgdXNl ciBjYW4gYmUKICAgICAgICBjZXJ0YWluIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGFsc28gY2FuJ3Qg cGVyZm9ybSBhIE1JVE0gYW5kCiAgICAgICAgYWNxdWlyZSB0aGUga2V5cyB0byB0aGUgbWVkaWEg Y29tbXVuaWNhdGlvbi48L3Q+CgogICAgICAgIDx0PkluIHRoZSBkZXZlbG9wbWVudCBvZiBXZWJS VEMgdGhlcmUgaGFzIGFsc28gYmVlbiBhdHRlbnRpb24gZ2l2ZW4gdG8KICAgICAgICBwcml2YWN5 IGNvbnNpZGVyYXRpb25zLiBUaGUgbWFpbiBSVFAtcmVsYXRlZCBjb25jZXJucyB0aGF0IGhhdmUg YmVlbiByYWlzZWQgYXJlOjxsaXN0IHN0eWxlPSJoYW5naW5nIj4KICAgICAgICAgICAgPHQgaGFu Z1RleHQ9IkxvY2F0aW9uIERpc2Nsb3N1cmU6Ij5BcyBJQ0UgbmVnb3RpYXRpb24gcHJvdmlkZXMg SVAKICAgICAgICAgICAgYWRkcmVzc2VzIGFuZCBwb3J0cyBmb3IgdGhlIGJyb3dzZXIsIHRoaXMg bGVha3MgbG9jYXRpb24KICAgICAgICAgICAgaW5mb3JtYXRpb24gaW4gdGhlIHNpZ25hbGxpbmcg dG8gdGhlIHBlZXIuIFRvIHByZXZlbnQgdGhpcyBvbmUgY2FuCiAgICAgICAgICAgIGJsb2NrIHRo ZSB1c2FnZSBvZiBhbnkgSUNFIGNhbmRpZGF0ZSB0aGF0IGlzbid0IGEgcmVsYXkgY2FuZGlkYXRl LAogICAgICAgICAgICBpLmUuIHdoZXJlIHRoZSBJUCBhbmQgcG9ydCBwcm92aWRlZCBiZWxvbmcg dG8gdGhlIHNlcnZpY2UKICAgICAgICAgICAgcHJvdmlkZXJzIG1lZGlhIHRyYWZmaWMgcmVsYXku PC90PgoKICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlByZXZlbnQgdHJhY2tpbmcgYmV0d2VlbiBz ZXNzaW9uczoiPlJUUCBDTkFNRXMgYW5kCiAgICAgICAgICAgIERUTFMtU1JUUCBjZXJ0aWZpY2F0 ZXMgcHJvdmlkZSBpbmZvcm1hdGlvbiB0aGF0IGNvdWxkIHBvc3NpYmx5IGJlCiAgICAgICAgICAg IHJlLXVzZWQgYmV0d2VlbiBzZXNzaW9uIGluc3RhbmNlcy4gVGh1cyB0byBwcmV2ZW50IHRyYWNr aW5nLCB0aGUKICAgICAgICAgICAgc2FtZSBpbmZvcm1hdGlvbiBjYW4ndCBiZSByZS11c2VkIGJl dHdlZW4gZGlmZmVyZW50IGNvbW11bmljYXRpb24KICAgICAgICAgICAgc2Vzc2lvbnMuPC90Pgog ICAgICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAgPHQ+Tm90ZTogVGhlIGFib3ZlIGNhc2VzIGFy ZSBmb2N1c2VkIG9uIHByb3ZpZGluZyBwcml2YWN5IHRvd2FyZHMKICAgICAgICBvdGhlciBwYXJ0 aWVzIHRoYW4gdGhlIHdlYiBzZXJ2aWNlLjwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNl Y3Rpb24gYW5jaG9yPSJzZWMtZXhhbXBsZXMtcHNzIgogICAgICAgICAgICAgICB0aXRsZT0iM0dQ UCBQYWNrZXQgQmFzZWQgU3RyZWFtaW5nIFNlcnZpY2UgKFBTUykgIj4KICAgICAgICA8dD5UaGUg M0dQUCBSZWxlYXNlIDExIFBTUyBzcGVjaWZpY2F0aW9uIG9mIHRoZSBQYWNrZXQgQmFzZWQgU3Ry ZWFtaW5nCiAgICAgICAgU2VydmljZSA8eHJlZiB0YXJnZXQ9IlQzR1BQLjI2LjIzNFIxMSI+KFBT Uyk8L3hyZWY+IGRlZmluZXMsIGluIEFubmV4IFIsCiAgICAgICAgYSBzZXQgb2Ygc2VjdXJpdHkg bWVjaGFuaXNtcy4gVGhlc2Ugc2VjdXJpdHkgbWVjaGFuaXNtcyBhcmUgY29uY2VybmVkCiAgICAg ICAgd2l0aCBwcm90ZWN0aW5nIHRoZSBjb250ZW50IGZyb20gYmVpbmcgY2FwdHVyZWQsIGkuZS4g RGlnaXRhbCBSaWdodHMKICAgICAgICBNYW5hZ2VtZW50LiBJZiB0aGVzZSBnb2FscyBhcmUgdG8g YmUgbWVldCB3aXRoIHRoZSBzcGVjaWZpZWQgc29sdXRpb24KICAgICAgICB0aGVyZSBuZWVkcyB0 byBleGlzdCB0cnVzdCBpbiB0aGF0IG5laXRoZXIgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZQog ICAgICAgIGNsaWVudCBub3IgdGhlIHBsYXRmb3JtIHRoZSBhcHBsaWNhdGlvbiBydW5zIGNhbiBi ZSBhY2Nlc3NlZCBvcgogICAgICAgIG1vZGlmaWVkIGJ5IHRoZSBhdHRhY2tlci48L3Q+CgogICAg ICAgIDx0PlBTUyBpcyA8eHJlZiB0YXJnZXQ9IlJGQzIzMjYiPlJUU1AgMS4wPC94cmVmPiBjb250 cm9sbGVkIG1lZGlhCiAgICAgICAgc3RyZWFtaW5nIG92ZXIgUlRQLiBUaHVzIGFuIFJUU1AgY2xp ZW50IHdob3NlIHVzZXIgd2FudHMgdG8gYWNjZXNzIGEKICAgICAgICBwcm90ZWN0ZWQgY29udGVu dCB3aWxsIHJlcXVlc3QgYSBzZXNzaW9uIGRlc2NyaXB0aW9uICg8eHJlZgogICAgICAgIHRhcmdl dD0iUkZDNDU2NiI+U0RQPC94cmVmPikgZm9yIHRoZSBwcm90ZWN0ZWQgY29udGVudC4gVGhpcyBT RFAgd2lsbAogICAgICAgIGluZGljYXRlIHRoYXQgdGhlIG1lZGlhIGlzIDx4cmVmIHRhcmdldD0i SVNNQUNyeXB0MiI+SVNNQSBDcnlwdAogICAgICAgIDIuMDwveHJlZj4gcHJvdGVjdGVkIG1lZGlh IGVuY29kaW5nIGFwcGxpY2F0aW9uIHVuaXRzIChBVXMpLiBUaGUKICAgICAgICBrZXkocykgdXNl ZCB0byBwcm90ZWN0IHRoZSBtZWRpYSBhcmUgcHJvdmlkZWQgaW4gZWl0aGVyIG9mIHR3byB3YXlz LgogICAgICAgIElmIGEgc2luZ2xlIGtleSBpcyB1c2VkIHRoZW4gdGhlIGNsaWVudCB1c2VzIHNv bWUgRFJNIHN5c3RlbSB0bwogICAgICAgIHJldHJpZXZlIHRoZSBrZXkgYXMgaW5kaWNhdGVkIGlu IHRoZSBTRFAuIENvbW1vbmx5IDx4cmVmCiAgICAgICAgdGFyZ2V0PSJPTUFEUk12MiI+T01BIERS TSB2MjwveHJlZj4gd2lsbCBiZSB1c2VkIHRvIHJldHJpZXZlIHRoZSBrZXkuCiAgICAgICAgSWYg bXVsdGlwbGUga2V5cyBhcmUgdG8gYmUgdXNlZCwgdGhlbiBhbiBhZGRpdGlvbmFsIFJUU1Agc3Ry ZWFtCiAgICAgICAgZm9yIGtleS11cGRhdGVzIGluIHBhcmFsbGVsIHdpdGggdGhlIG1lZGlhIHN0 cmVhbXMgaXMgZXN0YWJsaXNoZWQsCiAgICAgICAgd2hlcmUga2V5IHVwZGF0ZXMgYXJlIHNlbnQg dG8gdGhlIGNsaWVudCB1c2luZyBTaG9ydCBUZXJtIEtleSBNZXNzYWdlcwogICAgICAgIGRlZmlu ZWQgaW4gdGhlICJTZXJ2aWNlIGFuZCBDb250ZW50IFByb3RlY3Rpb24gZm9yIE1vYmlsZSBCcm9h ZGNhc3QKICAgICAgICBTZXJ2aWNlcyIgc2VjdGlvbiBvZiB0aGUgPHhyZWYgdGFyZ2V0PSJPTUFC Q0FTVCI+T01BIE1vYmlsZSBCcm9hZGNhc3QKICAgICAgICBTZXJ2aWNlczwveHJlZj4uPC90PgoK ICAgICAgICA8dD5Xb3J0aCBub3RpbmcgaXMgdGhhdCB0aGlzIHNvbHV0aW9uIGRvZXNuJ3QgcHJv dmlkZSBhbnkgaW50ZWdyaXR5CiAgICAgICAgdmVyaWZpY2F0aW9uIG1ldGhvZCBmb3IgdGhlIFJU UCBoZWFkZXIgYW5kIHBheWxvYWQgaGVhZGVyIGluZm9ybWF0aW9uLAogICAgICAgIG9ubHkgdGhl IGVuY29kZWQgbWVkaWEgQVUgaXMgcHJvdGVjdGVkLiAzR1BQIGhhcyBub3QgZGVmaW5lZCBhbnkK ICAgICAgICByZXF1aXJlbWVudCBmb3Igc3VwcG9ydGluZyBhbnkgc29sdXRpb24gdGhhdCBjb3Vs ZCBwcm92aWRlCiAgICAgICAgdGhhdCBzZXJ2aWNlLiBUaHVzLCByZXBsYXkgb3IgaW5zZXJ0aW9u IGF0dGFja3MgYXJlIHBvc3NpYmxlLiBBbm90aGVyCiAgICAgICAgcHJvcGVydHkgaXMgdGhhdCB0 aGUgbWVkaWEgY29udGVudCBjYW4gYmUgcHJvdGVjdGVkIGJ5IHRoZSBvbmVzCiAgICAgICAgcHJv dmlkaW5nIHRoZSBtZWRpYSwgc28gdGhhdCB0aGUgb3BlcmF0b3JzIG9mIHRoZSBSVFNQIHNlcnZl ciBoYXMgbm8KICAgICAgICBhY2Nlc3MgdG8gdW5wcm90ZWN0ZWQgY29udGVudC4gSW5zdGVhZCBh bGwgdGhhdCB3YW50IHRvIGFjY2VzcyB0aGUKICAgICAgICBtZWRpYSBtdXN0IGNvbnRhY3QgdGhl IERSTSBrZXlpbmcgc2VydmVyIGFuZCBpZiB0aGUgZGV2aWNlCiAgICAgICAgaXMgYWNjZXB0YWJs ZSB0aGV5IHdpbGwgYmUgZ2l2ZW4gdGhlIGtleSB0byBkZWNyeXB0IHRoZSBtZWRpYS48L3Q+Cgog ICAgICAgIDx0PlRvIHByb3RlY3Qgc2lnbmFsbGluZywgUlRTUCAxLjAgc3VwcG9ydHMgdGhlIHVz YWdlIG9mIFRMUy4gVGhpcwogICAgICAgIGlzLCBob3dldmVyLCBub3QgZXhwbGljaXRseSBkaXNj dXNzZWQgaW4gdGhlIFBTUyBzcGVjaWZpY2F0aW9uLiBVc2FnZSBvZgogICAgICAgIFRMUyBjYW4g cHJldmVudCBib3RoIG1vZGlmaWNhdGlvbiBvZiB0aGUgc2Vzc2lvbiBkZXNjcmlwdGlvbgogICAg ICAgIGluZm9ybWF0aW9uIGFuZCBoZWxwIG1haW50YWluIHNvbWUgcHJpdmFjeSBvZiB3aGF0IGNv bnRlbnQgdGhlIHVzZXIgaXMKICAgICAgICB3YXRjaGluZyBhcyBhbGwgVVJMcyB3b3VsZCB0aGVu IGJlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0ZWQuPC90PgogICAgICA8L3NlY3Rpb24+CgogICAg ICA8c2VjdGlvbiB0aXRsZT0iUlRTUCAyLjAiPgogICAgICAgIDx0Pjx4cmVmIHRhcmdldD0iSS1E LmlldGYtbW11c2ljLXJmYzIzMjZiaXMiPlJlYWwtdGltZSBTdHJlYW1pbmcKICAgICAgICBQcm90 b2NvbCAyLjA8L3hyZWY+IG9mZmVycyBhbiBpbnRlcmVzdGluZyBjb21wYXJpc29uIHRvIHRoZSA8 eHJlZgogICAgICAgIHRhcmdldD0ic2VjLWV4YW1wbGVzLXBzcyI+UFNTIHNlcnZpY2U8L3hyZWY+ IHRoYXQgaXMgYmFzZWQgb24gUlRTUCAxLjAKICAgICAgICBhbmQgc2VydmljZSByZXF1aXJlbWVu dHMgcGVyY2VpdmVkIGJ5IG1vYmlsZSBvcGVyYXRvcnMuIEEgbWFqb3IKICAgICAgICBkaWZmZXJl bmNlIGJldHdlZW4gUlRTUCAxLjAgYW5kIFJUU1AgMi4wIGlzIHRoYXQgMi4wCiAgICAgICAgc3Bl Y2lmaWVzIGhvdyBvbmUgdHJhbnNwb3J0IG1lZGlhIG92ZXIgUlRQIGl0IGFsc28KICAgICAgICBk ZWZpbmVzIHNlY3VyaXR5IG1lY2hhbmlzbXMgZm9yIHRoZSBSVFAtdHJhbnNwb3J0ZWQgbWVkaWEK ICAgICAgICBzdHJlYW1zLjwvdD4KCiAgICAgICAgPHQ+VGhlIHNlY3VyaXR5IGdvYWxzIGZvciBS VFAgaW4gUlRTUCAyLjAgaXMgdG8gZW5zdXJlIHRoYXQgdGhlcmUgaXMKICAgICAgICBjb25maWRl bnRpYWxpdHksIGludGVncml0eSBhbmQgc291cmNlIGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gdGhl IFJUU1AKICAgICAgICBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQuIFRoaXMgdG8gcHJldmVudCBlYXZl c2Ryb3BwaW5nIG9uIHdoYXQgdGhlIHVzZXIKICAgICAgICBpcyB3YXRjaGluZyBmb3IgcHJpdmFj eSByZWFzb25zIGFuZCB0byBwcmV2ZW50IHJlcGxheSBvciBpbmplY3Rpb24KICAgICAgICBhdHRh Y2tzIG9uIHRoZSBtZWRpYSBzdHJlYW0uIFRvIHJlYWNoIHRoZXNlIGdvYWxzLCB0aGUgc2lnbmFs bGluZwogICAgICAgIGFsc28gaGFzIHRvIGJlIHByb3RlY3RlZCwgcmVxdWlyaW5nIHRoZSB1c2Ug b2YgVExTIGJldHdlZW4gdGhlIGNsaWVudCBhbmQKICAgICAgICBzZXJ2ZXIuPC90PgoKICAgICAg ICA8dD5Vc2luZyBUTFMtcHJvdGVjdGVkIHNpZ25hbGxpbmcgdGhlIGNsaWVudCBhbmQgc2VydmVy IGFncmVlIG9uIHRoZQogICAgICAgIG1lZGlhIHRyYW5zcG9ydCBtZXRob2Qgd2hlbiBkb2luZyB0 aGUgU0VUVVAgcmVxdWVzdCBhbmQgcmVzcG9uc2UuIFRoZQogICAgICAgIHNlY3VyZWQgbWVkaWEg dHJhbnNwb3J0IGlzIFNSVFAgKFNBVlAvUlRQKSBub3JtYWxseSBvdmVyIFVEUC4gVGhlIGtleQog ICAgICAgIG1hbmFnZW1lbnQgZm9yIFNSVFAgaXMgTUlLRVkgdXNpbmcgUlNBLVIgbW9kZS4gVGhl IFJTQS1SIG1vZGUgaXMKICAgICAgICBzZWxlY3RlZCBhcyBpdCBhbGxvd3MgdGhlIFJUU1AgU2Vy dmVyIHRvIHNlbGVjdCB0aGUga2V5IGRlc3BpdGUKICAgICAgICBoYXZpbmcgdGhlIFJUU1AgQ2xp ZW50IGluaXRpYXRlIHRoZSBNSUtFWSBleGNoYW5nZS4gSXQgYWxzbyBlbmFibGVzCiAgICAgICAg dGhlIHJldXNlIG9mIHRoZSBSVFNQIHNlcnZlcnMgVExTIGNlcnRpZmljYXRlIHdoZW4gY3JlYXRp bmcgdGhlIE1JS0VZCiAgICAgICAgbWVzc2FnZXMgdGh1cyBlbnN1cmluZyBhIGJpbmRpbmcgYmV0 d2VlbiB0aGUgUlRTUCBzZXJ2ZXIgYW5kIHRoZQogICAgICAgIGtleSBleGNoYW5nZS4gQXNzdW1p bmcgdGhlIFNFVFVQIHByb2Nlc3Mgd29ya3MsIHRoaXMgd2lsbCBlc3RhYmxpc2ggYQogICAgICAg IFNSVFAgY3J5cHRvIGNvbnRleHQgdG8gYmUgdXNlZCBiZXR3ZWVuIHRoZSBSVFNQIFNlcnZlciBh bmQgdGhlIENsaWVudAogICAgICAgIGZvciB0aGUgUlRQIHRyYW5zcG9ydGVkIG1lZGlhIHN0cmVh bXMuPC90PgogICAgICA8L3NlY3Rpb24+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5j aG9yPSJJQU5BIiB0aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9ucyI+CiAgICAgIDx0PlRoaXMgZG9j dW1lbnQgbWFrZXMgbm8gcmVxdWVzdCBvZiBJQU5BLjwvdD4KCiAgICAgIDx0Pk5vdGUgdG8gUkZD IEVkaXRvcjogdGhpcyBzZWN0aW9uIGNhbiBiZSByZW1vdmVkIG9uIHB1YmxpY2F0aW9uIGFzIGFu CiAgICAgIFJGQy48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMt c2VjdXJpdHkiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyI+CiAgICAgIDx0PlRoaXMg ZW50aXJlIGRvY3VtZW50IGlzIGFib3V0IHNlY3VyaXR5LiBQbGVhc2UgcmVhZCBpdC48L3Q+CiAg ICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtYWNrIiB0aXRsZT0iQWNrbm93 bGVkZ2VtZW50cyI+CiAgICAgIDx0PldlIHRoYW5rIHRoZSBJRVNHIGZvciB0aGVpciBjYXJlZnVs IHJldmlldyBvZiA8eHJlZgogICAgICB0YXJnZXQ9IkktRC5pZXRmLWF2dC1zcnRwLW5vdC1tYW5k YXRvcnkiLz4gd2hpY2ggbGVkIHRvIHRoZSB3cml0aW5nIG9mCiAgICAgIHRoaXMgbWVtby48L3Q+ CgogICAgICA8dD5UaGUgYXV0aG9ycyB3aXNoZWQgdG8gdGhhbmsgQ2hyaXN0aWFuIENvcnJlbGwg Zm9yIHJldmlldyBhbmQgZ3JlYXQKICAgICAgcHJvcG9zYWxzIGZvciBpbXByb3ZlbWVudHMgb2Yg dGhlIHRleHQuPC90PgogICAgPC9zZWN0aW9uPgogIDwvbWlkZGxlPgoKICA8YmFjaz4KICAgIDxy ZWZlcmVuY2VzIHRpdGxlPSJJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIj4KICAgICAgPD9yZmMgaW5j bHVkZT0ncmVmZXJlbmNlLlJGQy4xMTEyJz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVu Y2UuUkZDLjIzMjYnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuMzM2NSc/ PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy4zNTUwJz8+CgogICAgICA8P3Jm YyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjM2NDAnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3Jl ZmVyZW5jZS5SRkMuMzcxMSc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy4z ODMwJz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjQzMDEnPz4KCiAgICAg IDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNDM4Myc/PgoKICAgICAgPD9yZmMgaW5jbHVk ZT0ncmVmZXJlbmNlLlJGQy40NTY2Jz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2Uu UkZDLjQ1NjcnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNDU2OCc/PgoK ICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy40NTcxJz8+CgogICAgICA8P3JmYyBp bmNsdWRlPSdyZWZlcmVuY2UuUkZDLjQ1NzInPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVy ZW5jZS5SRkMuNDYwNyc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy40NjUw Jz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjQ3MzgnPz4KCiAgICAgIDw/ cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNDc3MSc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0n cmVmZXJlbmNlLlJGQy40OTE2Jz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZD LjQ5NDknPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNTExNyc/PgoKICAg ICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy41MTk3Jz8+CgogICAgICA8P3JmYyBpbmNs dWRlPSdyZWZlcmVuY2UuUkZDLjU0NzknPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5j ZS5SRkMuNTY2OSc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy41NzYwJz8+ CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjU3NjMnPz4KCiAgICAgIDw/cmZj IGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNTc2NCc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVm ZXJlbmNlLlJGQy42MDQzJz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjYx ODgnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNjE4OSc/PgoKICAgICAg PD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy42MjY3Jz8+CgogICAgICA8P3JmYyBpbmNsdWRl PSdyZWZlcmVuY2UuUkZDLjYzNDcnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5S RkMuNjUwOSc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy42NTYyJz8+Cgog ICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjY5MDQnPz4KCiAgICAgIDw/cmZjIGlu Y2x1ZGU9J3JlZmVyZW5jZS5JLUQuaWV0Zi1hdnQtc3J0cC1ub3QtbWFuZGF0b3J5Jz8+CgogICAg ICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuSS1ELmlldGYtYXZ0Y29yZS1hcmlhLXNydHAnPz4K CiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5JLUQuaWV0Zi1hdnRjb3JlLXNydHAtYWVz LWdjbSc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLkktRC5pZXRmLWF2dGNvcmUt c3J0cC1la3QnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5JLUQuaWV0Zi1tbXVz aWMtcmZjMjMyNmJpcyc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLkktRC5pZXRm LXJ0Y3dlYi1vdmVydmlldyc/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLkktRC5p ZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoJz8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVu Y2UuSS1ELmlldGYtYXZ0Y29yZS02MjIyYmlzJz8+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0i SVNNQUNyeXB0MiI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPklTTUEgRW5jcnlw dGlvbiBhbmQgQXV0aGVudGljYXRpb24sIFZlcnNpb24gMi4wIHJlbGVhc2UKICAgICAgICAgIHZl cnNpb248L3RpdGxlPgoKICAgICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IkludGVybmV0IFN0cmVh bWluZyBNZWRpYSBBbGxpYW5jZSAoSVNNQSkiPgogICAgICAgICAgICA8b3JnYW5pemF0aW9uLz4K ICAgICAgICAgIDwvYXV0aG9yPgoKICAgICAgICAgIDxkYXRlIG1vbnRoPSJOb3ZlbWJlciIgeWVh cj0iMjAwNyIvPgogICAgICAgIDwvZnJvbnQ+CgogICAgICAgIDxmb3JtYXQgdGFyZ2V0PSJodHRw Oi8vd3d3Lm1wZWdpZi5vcmcvbTRpZi9ib2QvSVNNQS9JU01BX0UlMjZBc3BlYzIuMC5wZGYiCiAg ICAgICAgICAgICAgICB0eXBlPSJQREYiLz4KICAgICAgPC9yZWZlcmVuY2U+CgogICAgICA8cmVm ZXJlbmNlIGFuY2hvcj0iT01BRFJNdjIiPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRs ZT5PTUEgRGlnaXRhbCBSaWdodHMgTWFuYWdlbWVudCBWMi4wPC90aXRsZT4KCiAgICAgICAgICA8 YXV0aG9yIGZ1bGxuYW1lPSJPcGVuIE1vYmlsZSBBbGxpYW5jZSI+CiAgICAgICAgICAgIDxvcmdh bml6YXRpb24+T3BlbiBNb2JpbGUgQWxsaWFuY2U8L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwv YXV0aG9yPgoKICAgICAgICAgIDxkYXRlIGRheT0iMjMiIG1vbnRoPSJKdWx5IiB5ZWFyPSIyMDA4 Ii8+CiAgICAgICAgPC9mcm9udD4KCiAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly93d3cu b3Blbm1vYmlsZWFsbGlhbmNlLm9yZy90ZWNobmljYWwvcmVsZWFzZV9wcm9ncmFtL2RybV92Ml8w LmFzcHgiCiAgICAgICAgICAgICAgICB0eXBlPSJIVE1MIi8+CiAgICAgIDwvcmVmZXJlbmNlPgoK ICAgICAgPHJlZmVyZW5jZSBhbmNob3I9Ik9NQUJDQVNUIj4KICAgICAgICA8ZnJvbnQ+CiAgICAg ICAgICA8dGl0bGU+T01BIE1vYmlsZSBCcm9hZGNhc3QgU2VydmljZXMgVjEuMDwvdGl0bGU+Cgog ICAgICAgICAgPGF1dGhvciBmdWxsbmFtZT0iT3BlbiBNb2JpbGUgQWxsaWFuY2UiPgogICAgICAg ICAgICA8b3JnYW5pemF0aW9uPk9wZW4gTW9iaWxlIEFsbGlhbmNlPC9vcmdhbml6YXRpb24+CiAg ICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAgICA8ZGF0ZSBkYXk9IjEiIG1vbnRoPSJGZWJydWFy eSIgeWVhcj0iMjAwOSIvPgogICAgICAgIDwvZnJvbnQ+CgogICAgICAgIDxmb3JtYXQgdGFyZ2V0 PSJodHRwOi8vdGVjaG5pY2FsLm9wZW5tb2JpbGVhbGxpYW5jZS5vcmcvVGVjaG5pY2FsL3JlbGVh c2VfcHJvZ3JhbS9iY2FzdF92MV8wLmFzcHgiCiAgICAgICAgICAgICAgICB0eXBlPSJIVE1MIi8+ CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlQzR1BQLjI2LjIz NFI4Ij4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+VGVjaG5pY2FsIFNwZWNpZmlj YXRpb24gR3JvdXAgU2VydmljZXMgYW5kIFN5c3RlbSBBc3BlY3RzOwogICAgICAgICAgVHJhbnNw YXJlbnQgZW5kLXRvLWVuZCBQYWNrZXQtc3dpdGNoZWQgU3RyZWFtaW5nIFNlcnZpY2UgKFBTUyk7 CiAgICAgICAgICBQcm90b2NvbHMgYW5kIGNvZGVjczwvdGl0bGU+CgogICAgICAgICAgPGF1dGhv ciBmdWxsbmFtZT0iM0dQUCI+CiAgICAgICAgICAgIDxvcmdhbml6YXRpb24+M0dQUDwvb3JnYW5p emF0aW9uPgogICAgICAgICAgPC9hdXRob3I+CgogICAgICAgICAgPGRhdGUgbW9udGg9IlNlcHRl bWJlciIgeWVhcj0iMjAwOSIvPgogICAgICAgIDwvZnJvbnQ+CgogICAgICAgIDxzZXJpZXNJbmZv IG5hbWU9IjNHUFAgVFMiIHZhbHVlPSIyNi4yMzQgOC40LjAiLz4KCiAgICAgICAgPGZvcm1hdCB0 YXJnZXQ9Imh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1NwZWNzL2h0bWwtaW5mby8yMzIzNC5odG0i CiAgICAgICAgICAgICAgICB0eXBlPSJIVE1MIi8+CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAg PHJlZmVyZW5jZSBhbmNob3I9IlQzR1BQLjI2LjIzNFIxMSI+CiAgICAgICAgPGZyb250PgogICAg ICAgICAgPHRpdGxlPlRlY2huaWNhbCBTcGVjaWZpY2F0aW9uIEdyb3VwIFNlcnZpY2VzIGFuZCBT eXN0ZW0gQXNwZWN0czsKICAgICAgICAgIFRyYW5zcGFyZW50IGVuZC10by1lbmQgUGFja2V0LXN3 aXRjaGVkIFN0cmVhbWluZyBTZXJ2aWNlIChQU1MpOwogICAgICAgICAgUHJvdG9jb2xzIGFuZCBj b2RlY3M8L3RpdGxlPgoKICAgICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IjNHUFAiPgogICAgICAg ICAgICA8b3JnYW5pemF0aW9uPjNHUFA8L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwvYXV0aG9y PgoKICAgICAgICAgIDxkYXRlIG1vbnRoPSJTZXB0ZW1iZXIiIHllYXI9IjIwMTIiLz4KICAgICAg ICA8L2Zyb250PgoKICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSIzR1BQIFRTIiB2YWx1ZT0iMjYu MjM0IDExLjEuMCIvPgoKICAgICAgICA8Zm9ybWF0IHRhcmdldD0iaHR0cDovL3d3dy4zZ3BwLm9y Zy9mdHAvU3BlY3MvaHRtbC1pbmZvLzIzMjM0Lmh0bSIKICAgICAgICAgICAgICAgIHR5cGU9IkhU TUwiLz4KICAgICAgPC9yZWZlcmVuY2U+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iVDNHUFAu MjYuMzQ2Ij4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+TXVsdGltZWRpYSBCcm9h ZGNhc3QvTXVsdGljYXN0IFNlcnZpY2UgKE1CTVMpOyBQcm90b2NvbHMgYW5kCiAgICAgICAgICBj b2RlY3M8L3RpdGxlPgoKICAgICAgICAgIDxhdXRob3I+CiAgICAgICAgICAgIDxvcmdhbml6YXRp b24+M0dQUDwvb3JnYW5pemF0aW9uPgogICAgICAgICAgPC9hdXRob3I+CgogICAgICAgICAgPGRh dGUgZGF5PSIyMCIgbW9udGg9Ik1hcmNoIiB5ZWFyPSIyMDEzIi8+CiAgICAgICAgPC9mcm9udD4K CiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iM0dQUCBUUyIgdmFsdWU9IjI2LjM0NiAxMC43LjAi Lz4KCiAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1NwZWNz L2h0bWwtaW5mby8yNjM0Ni5odG0iCiAgICAgICAgICAgICAgICB0eXBlPSJIVE1MIi8+CiAgICAg IDwvcmVmZXJlbmNlPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlQzR1BQLjMzLjI0NiI+CiAg ICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPjNHIFNlY3VyaXR5OyBTZWN1cml0eSBvZiBN dWx0aW1lZGlhIEJyb2FkY2FzdC9NdWx0aWNhc3QKICAgICAgICAgIFNlcnZpY2UgKE1CTVMpPC90 aXRsZT4KCiAgICAgICAgICA8YXV0aG9yPgogICAgICAgICAgICA8b3JnYW5pemF0aW9uPjNHUFA8 L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwvYXV0aG9yPgoKICAgICAgICAgIDxkYXRlIGRheT0i MjEiIG1vbnRoPSJEZWNlbWJlciIgeWVhcj0iMjAxMiIvPgogICAgICAgIDwvZnJvbnQ+CgogICAg ICAgIDxzZXJpZXNJbmZvIG5hbWU9IjNHUFAgVFMiIHZhbHVlPSIzMy4yNDYgMTAuMS4wIi8+Cgog ICAgICAgIDxmb3JtYXQgdGFyZ2V0PSJodHRwOi8vd3d3LjNncHAub3JnL2Z0cC9TcGVjcy9odG1s LWluZm8vMzMyNDYuaHRtIgogICAgICAgICAgICAgICAgdHlwZT0iSFRNTCIvPgogICAgICA8L3Jl ZmVyZW5jZT4KICAgIDwvcmVmZXJlbmNlcz4KICA8L2JhY2s+CjwvcmZjPgo= --e89a8ff1cc9e4dddcf04e05651a8-- From kevin.gross@avanw.com Sun Jun 30 05:51:38 2013 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 DC37121F994A for ; Sun, 30 Jun 2013 05:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, 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 JDOzwTOd6TbQ for ; Sun, 30 Jun 2013 05:51:33 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8986D21F994C for ; Sun, 30 Jun 2013 05:51:33 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta09.emeryville.ca.mail.comcast.net with comcast id ucme1l0020vp7WLA9crYrq; Sun, 30 Jun 2013 12:51:32 +0000 Received: from mail-oa0-f51.google.com ([209.85.219.51]) by omta05.emeryville.ca.mail.comcast.net with comcast id ucpV1l00i177q698RcpWtS; Sun, 30 Jun 2013 12:49:31 +0000 Received: by mail-oa0-f51.google.com with SMTP id i4so3888671oah.10 for ; Sun, 30 Jun 2013 05:49:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vasYF8M4/QfxAGEAnNfIhpY3tIzyaYRIJzk3ddYU7q8=; b=IuXdhWtDxupzwxOLc1RMXDQiUKxeX25He5qE6fgj20aJnu6DCeG6QzI0d+mXF9E01p Y2VfwALSDnjKw2jv7t6KxXkhlxpHRuP9UaD63A6JHoCCbxf78PYlK02ozR5kZg5RkavB fSxIH/rnt5zym+WbcYlzUSCVkUkMyCSFpW6K/lYXra9con6NJQmidoF02cgv0HfyIo9a nTMt/6GiQ+otBNXvNLoLUHRUWUr2o06nkUJyCedkFZTRfwdAJTOi26EiEkwLad89xLeP qFgUzqZfGZ5bTeKJXwVuLCncLZuxYtuKodd0gM60I+jRba9RGVpV9A9mXj2ul5HG0fTo Fj2A== MIME-Version: 1.0 X-Received: by 10.60.97.34 with SMTP id dx2mr8081385oeb.54.1372596569488; Sun, 30 Jun 2013 05:49:29 -0700 (PDT) Received: by 10.182.149.98 with HTTP; Sun, 30 Jun 2013 05:49:29 -0700 (PDT) In-Reply-To: References: <20130612173141.16659.99790.idtracker@ietfa.amsl.com> Date: Sun, 30 Jun 2013 06:49:29 -0600 Message-ID: From: Kevin Gross To: gjshep@gmail.com Content-Type: multipart/alternative; boundary=089e011619bef1c5f904e05e8aba DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372596692; bh=vasYF8M4/QfxAGEAnNfIhpY3tIzyaYRIJzk3ddYU7q8=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=l66/OSsXM+T/zTxfN+yqdEPmobvUo5+imWF7MxT5JAsrVgouaJ4yK4tyMJlOesE4W WTkURbEz3yeKw0cpc6zx/90q6Xax9PTu4u2Weu1TdD45lfpogcPWqMysaFeja0TYQy t937Kur556B5RwQ5mPSDmrIUXMBRTVvlNKtaNIXMNgQz3DmbYgcMCglLebY2bb2X3I owrD4HdYMkayppHDqmwGctaKsDZxa9ehLG3GwCO0M12q8hhdkmAw8yEt6/UvJHF6+D UopVGARmcPnfq8Dts8qL0GdZ0fpcIrDMyECRNyVPZpWzJ9MVTDADKE4fYp0lmqG/Rd /3KO4CL1iiptA== Cc: joel jaeggli , rmcat WG , "avt@ietf.org" Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-shepherd-multicast-udp-guidelines-01.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: Sun, 30 Jun 2013 12:51:38 -0000 --089e011619bef1c5f904e05e8aba Content-Type: text/plain; charset=ISO-8859-1 It seems like this overlaps with what RMCAT is working on. We're trying to quantify fairness to some degree. I have, for no scientific reason proposed a factor of 3. How did you settle on a factor of 10 in your proposal? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Jun 12, 2013 at 11:35 AM, Greg Shepherd wrote: > Please read and comment. I'd like to present this in Berlin, and get ample > feedback before then in order to help this progress as quickly as possible. > In addition to its overall value, it will be a helpful document in > addressing outstanding Discuss issues in the RFC Editors' queue. > > Thanks, > Greg > > ---------- Forwarded message ---------- > From: > Date: Wed, Jun 12, 2013 at 10:31 AM > Subject: New Version Notification for > draft-shepherd-multicast-udp-guidelines-01.txt > To: Greg Shepherd > > > > A new version of I-D, draft-shepherd-multicast-udp-guidelines-01.txt > has been successfully submitted by Greg Shepherd and posted to the > IETF repository. > > Filename: draft-shepherd-multicast-udp-guidelines > Revision: 01 > Title: Multicast UDP Usage Guidelines for Application Designers > Creation date: 2013-06-12 > Group: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-shepherd-multicast-udp-guidelines-01.txt > Status: > http://datatracker.ietf.org/doc/draft-shepherd-multicast-udp-guidelines > Htmlized: > http://tools.ietf.org/html/draft-shepherd-multicast-udp-guidelines-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-shepherd-multicast-udp-guidelines-01 > > Abstract: > The multi-recipient nature of Multicast prevents the use of any pont- > to-point connection-oriented transport, therefore restricts all > Multicast data to be sent over the User Datagram Protocol (UDP). UDP > provides a minimal message-passing transport that has no inherent > congestion control mechanisms. Because congestion control is > critical to the stable operation of the Internet, applications and > upper-layer protocols that choose to use Multicast UDP as an Internet > service must employ mechanisms to prevent congestion collapse and to > establish some degree of fairness with concurrent traffic. This > document provides guidelines on the use of UDP for the designers of > multicast applications and higher-level protocols. > > > > > The IETF Secretariat > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --089e011619bef1c5f904e05e8aba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It seems like this overlaps with what RMCAT is working on.= We're trying to quantify fairness to some degree. I have, for no scien= tific reason proposed a factor of 3. How did you settle on a factor of 10 i= n your proposal?

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


On Wed, Jun 12, 2013 at 11:35 AM, Greg S= hepherd <gjshep@gmail.com> wrote:
Please read and comment. I'd like to present this in B= erlin, and get ample feedback before then in order to help this progress as= quickly as possible. In addition to its overall value, it will be a helpfu= l document in addressing outstanding Discuss issues in the RFC Editors'= queue.

Thanks,
Greg

---= ------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jun 12, 2013 at 10:31 AM
Subject: New Version Notification fo= r draft-shepherd-multicast-udp-guidelines-01.txt
To: Greg Shepherd <<= a href=3D"mailto:gjshep@gmail.com" target=3D"_blank">gjshep@gmail.com&g= t;



A new version of I-D, draft-shepherd-multicast-udp-guidelines-01.txt
has been successfully submitted by Greg Shepherd and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-shepherd-multicast-udp-guidelines
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Multicast UDP Usage Guidelines for Application D= esigners
Creation date: =A0 2013-06-12
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.ietf.org/internet-drafts/draft-shepherd-multicast-udp-guidelines-01.txt<= /a>
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ie= tf.org/doc/draft-shepherd-multicast-udp-guidelines
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/htm= l/draft-shepherd-multicast-udp-guidelines-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ie= tf.org/rfcdiff?url2=3Ddraft-shepherd-multicast-udp-guidelines-01

Abstract:
=A0 =A0The multi-recipient nature of Multicast prevents the use of any pont= -
=A0 =A0to-point connection-oriented transport, therefore restricts all
=A0 =A0Multicast data to be sent over the User Datagram Protocol (UDP). =A0= UDP
=A0 =A0provides a minimal message-passing transport that has no inherent =A0 =A0congestion control mechanisms. =A0Because congestion control is
=A0 =A0critical to the stable operation of the Internet, applications and =A0 =A0upper-layer protocols that choose to use Multicast UDP as an Interne= t
=A0 =A0service must employ mechanisms to prevent congestion collapse and to=
=A0 =A0establish some degree of fairness with concurrent traffic. =A0This =A0 =A0document provides guidelines on the use of UDP for the designers of<= br> =A0 =A0multicast applications and higher-level protocols.




The IETF Secretariat



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


--089e011619bef1c5f904e05e8aba-- From gjshep@gmail.com Sun Jun 30 06:17:12 2013 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 DA1C321F9A34; Sun, 30 Jun 2013 06:17:12 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIvaF0bu7nO5; Sun, 30 Jun 2013 06:17:11 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69F21F9A15; Sun, 30 Jun 2013 06:17:10 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so2966982wgg.8 for ; Sun, 30 Jun 2013 06:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Umvl1tQ9oi/bWnNyWuVDVA88C7sjr4CxFRV6lpAntE0=; b=ywohY9IoYZodXRr6Dk34WIZR1PTB1NG4bBTURHuMMYdaT492O1b+BF09M1pguMDZlA 0PnePoyBDDsgVV0E7xn7EV2e+xxZq9CSSUmQ+Kh06MynJgVtdjcy3X7wFhGeNnghQS0B z6biKO5nr0F/Cf0/qYYEqsDyrjAIogKPaLOEYu8hwj5Au2gX7fPVe1iFXeK9FuOB+oAs TQB18BWt1Kl3+3t42AKSJP+miA188i1PP04zJEYko7eQHi+O40ovYiNL8XjXbsXsmwca l3vCLoHHWh7TWKfqhl5YqVVlhYAUPmW45JucNfaAhqyCnEyeMICvjYV559FwoJPueWXi q1Cw== MIME-Version: 1.0 X-Received: by 10.194.174.38 with SMTP id bp6mr17563536wjc.83.1372598230204; Sun, 30 Jun 2013 06:17:10 -0700 (PDT) Received: by 10.180.189.12 with HTTP; Sun, 30 Jun 2013 06:17:10 -0700 (PDT) In-Reply-To: References: <20130612173141.16659.99790.idtracker@ietfa.amsl.com> Date: Sun, 30 Jun 2013 06:17:10 -0700 Message-ID: From: Greg Shepherd To: Kevin Gross Content-Type: multipart/alternative; boundary=089e0141aa2aee48fe04e05eed72 Cc: joel jaeggli , rmcat WG , "avt@ietf.org" Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-shepherd-multicast-udp-guidelines-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 13:17:13 -0000 --089e0141aa2aee48fe04e05eed72 Content-Type: text/plain; charset=ISO-8859-1 This is not a solutions draft, but merely guidelines. It borrows liberally from RFC5405 in cases there a recommended solution doesn't exist. I wouldn't say this overlaps with any solutions draft as it only directs each case to the available solutions then provides guidelines if for some reason using an available solution is not possible. Greg On Sun, Jun 30, 2013 at 5:49 AM, Kevin Gross wrote: > It seems like this overlaps with what RMCAT is working on. We're trying to > quantify fairness to some degree. I have, for no scientific reason proposed > a factor of 3. How did you settle on a factor of 10 in your proposal? > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > On Wed, Jun 12, 2013 at 11:35 AM, Greg Shepherd wrote: > >> Please read and comment. I'd like to present this in Berlin, and get >> ample feedback before then in order to help this progress as quickly as >> possible. In addition to its overall value, it will be a helpful document >> in addressing outstanding Discuss issues in the RFC Editors' queue. >> >> Thanks, >> Greg >> >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Jun 12, 2013 at 10:31 AM >> Subject: New Version Notification for >> draft-shepherd-multicast-udp-guidelines-01.txt >> To: Greg Shepherd >> >> >> >> A new version of I-D, draft-shepherd-multicast-udp-guidelines-01.txt >> has been successfully submitted by Greg Shepherd and posted to the >> IETF repository. >> >> Filename: draft-shepherd-multicast-udp-guidelines >> Revision: 01 >> Title: Multicast UDP Usage Guidelines for Application Designers >> Creation date: 2013-06-12 >> Group: Individual Submission >> Number of pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-shepherd-multicast-udp-guidelines-01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-shepherd-multicast-udp-guidelines >> Htmlized: >> http://tools.ietf.org/html/draft-shepherd-multicast-udp-guidelines-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-shepherd-multicast-udp-guidelines-01 >> >> Abstract: >> The multi-recipient nature of Multicast prevents the use of any pont- >> to-point connection-oriented transport, therefore restricts all >> Multicast data to be sent over the User Datagram Protocol (UDP). UDP >> provides a minimal message-passing transport that has no inherent >> congestion control mechanisms. Because congestion control is >> critical to the stable operation of the Internet, applications and >> upper-layer protocols that choose to use Multicast UDP as an Internet >> service must employ mechanisms to prevent congestion collapse and to >> establish some degree of fairness with concurrent traffic. This >> document provides guidelines on the use of UDP for the designers of >> multicast applications and higher-level protocols. >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > --089e0141aa2aee48fe04e05eed72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is not a solutions draft, but merely guidelines. It b= orrows liberally from RFC5405 in cases there a recommended solution doesn&#= 39;t exist. I wouldn't say this overlaps with any solutions draft as it= only directs each case to the available solutions then provides guidelines= if for some reason using an available solution is not possible.

Greg


On Sun, Jun 30, 2013 at 5:49 AM, Kevin Gross <kevin.= gross@avanw.com> wrote:
It seems like this overlaps= with what RMCAT is working on. We're trying to quantify fairness to so= me degree. I have, for no scientific reason proposed a factor of 3. How did= you settle on a factor of 10 in your proposal?

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


On Wed, Jun 12, 2= 013 at 11:35 AM, Greg Shepherd <gjshep@gmail.com> wrote:
<= /div>
Please read and comment. I'd like to present this in B= erlin, and get ample feedback before then in order to help this progress as= quickly as possible. In addition to its overall value, it will be a helpfu= l document in addressing outstanding Discuss issues in the RFC Editors'= queue.

Thanks,
Greg

---= ------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jun 12, 2013 at 10:31 AM
Subject: New Version Notification fo= r draft-shepherd-multicast-udp-guidelines-01.txt
To: Greg Shepherd <<= a href=3D"mailto:gjshep@gmail.com" target=3D"_blank">gjshep@gmail.com&g= t;



A new version of I-D, draft-shepherd-multicast-udp-guidelines-01.txt
has been successfully submitted by Greg Shepherd and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-shepherd-multicast-udp-guidelines
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Multicast UDP Usage Guidelines for Application D= esigners
Creation date: =A0 2013-06-12
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.ietf.org/internet-drafts/draft-shepherd-multicast-udp-guidelines-01.txt<= /a>
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ie= tf.org/doc/draft-shepherd-multicast-udp-guidelines
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/htm= l/draft-shepherd-multicast-udp-guidelines-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ie= tf.org/rfcdiff?url2=3Ddraft-shepherd-multicast-udp-guidelines-01

Abstract:
=A0 =A0The multi-recipient nature of Multicast prevents the use of any pont= -
=A0 =A0to-point connection-oriented transport, therefore restricts all
=A0 =A0Multicast data to be sent over the User Datagram Protocol (UDP). =A0= UDP
=A0 =A0provides a minimal message-passing transport that has no inherent =A0 =A0congestion control mechanisms. =A0Because congestion control is
=A0 =A0critical to the stable operation of the Internet, applications and =A0 =A0upper-layer protocols that choose to use Multicast UDP as an Interne= t
=A0 =A0service must employ mechanisms to prevent congestion collapse and to=
=A0 =A0establish some degree of fairness with concurrent traffic. =A0This =A0 =A0document provides guidelines on the use of UDP for the designers of<= br> =A0 =A0multicast applications and higher-level protocols.




The IETF Secretariat



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



--089e0141aa2aee48fe04e05eed72--