From nobody Wed Apr 15 17:38:04 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010491ACEE4; Wed, 15 Apr 2015 17:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaeATZKi1ybm; Wed, 15 Apr 2015 17:38:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E987C1ACEE0; Wed, 15 Apr 2015 17:38:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416003801.24359.45159.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 17:38:01 -0700 From: IETF Secretariat Archived-At: Subject: [siprec] ID Tracker State Update Notice: X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 00:38:03 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ From nobody Fri Apr 17 15:40:03 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0C1A8AC6 for ; Fri, 17 Apr 2015 15:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9F3whLFZVzy for ; Fri, 17 Apr 2015 15:39:59 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD05E1A8AC4 for ; Fri, 17 Apr 2015 15:39:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DBC022077C for ; Fri, 17 Apr 2015 18:39:58 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 17 Apr 2015 18:39:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=sI3 1CFFkGWK1sKAkGZn62oFKimg=; b=3dovjUgEk0wtjqy5IBVXCipOapYALLSCkWQ /WT0qz/p/+oN9K2nmvkqF+cKOhNrC5VOOzGAVr4hTlZT1QmDQ9ZihX3Qvsf/igF4 pFsP/pZLVnTC0hduhb74W1aHeNehBd28ghsHb1ApdXdkwmgSVCKu3zDG7H5mjM1z AnHpx/uE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=sI31CFFkGWK1sKAkGZn62oFKimg=; b=NT3Iz Jk7JIhNbQAF+SO+YffB/QCFgKz8RoNNkc0dtypdDMtlb/FgXu0duL7AQeqYB/icR v+BrxzLlUksfwZ72VWOQ7xa72T4NR0hII02xOSgVbNTvbKBRFvzOFWl5Um0zQRkT //I6bN0J2ZQWNiZKDWYNz0CJ4roXX5UvWncV9U= X-Sasl-enc: RWTVdHBk5nUMoyqu9pespce34LbX/Q738ltOvI4WWooP 1429310398 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.188]) by mail.messagingengine.com (Postfix) with ESMTPA id 261E3C00015 for ; Fri, 17 Apr 2015 18:39:57 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 17 Apr 2015 15:39:56 -0700 To: siprec@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 22:40:02 -0000 I have reviewed this document in preparation for IETF LC. Overall it is = in good shape. I have a few substantive questions/comments I=92d like to = discuss before issuing the IETF LC and a bunch of nits. Substantive issues: General: I think this document is missing a clear, concise explanation of why the = protocol cannot be used for wiretapping. The pieces of this explanation = are almost all there in sections 5, 6, and 7, but given the existence of = RFC 2804 and general sensitivity towards this issue, I think the = document needs to be more explicit about the expected mechanics of the = recording indication and preference mechanisms in situations where all = involved UAs are recording-aware and where they are not. A simple = statement is missing about how it is not possible to use this protocol = as standardized without the SRC sending an indication that recording is = occurring to every participant in the session. Furthermore, it seems = like there are some situations where if a user does not want to be = recorded, his only option is to terminate the session. This arises when = an SRC does not honor a UA's recording preference set to off, and also = possibly when a UA is not recording-aware, right? Those two situations = need to be described explicitly. I would suggest adding the explanation to 5.3 and summarizing it in a = sentence in the abstract and in the introduction. Sec 6.1.2: "For the communication session, the SRC MUST provide recording indication to all participants in the CS. A participant UA in a CS can indicate that it is recording-aware by providing the "record- aware" option tag, and the SRC MUST provide recording indications in the new SDP a=3Drecord attribute described in the SDP Handling = section. In the absence of the "record-aware" option tag, meaning that the participant UA is not recording-aware, an SRC MUST provide recording indications through other means such as playing a tone in-band, if the SRC is required to do so (e.g. based on policies)." The requirements established in this paragraph are a little confusing. = First it says the SRC MUST provide recording indication to all = participants. Then later it says the SRC MUST provide recording = indications through other means ... if required to do so by policy. That = sounds like a conditional MUST, which doesn't make sense (since MUST = means an absolute requirement), and it also contradicts the MUST in the = first sentence. Shouldn't the if clause in the last sentence be dropped? Section 6.3: "A recording-aware UA MUST be prepared to provide a recording indication to the end user through an appropriate user interface" "MUST be prepared to" is a strange construction. I think "MUST provide" = is what is meant here. Section 7.2: "The SRS SHOULD NOT add recorded streams in the recording session when SRS sends a new SDP offer. Similarly, when the SRS starts a recording session, the SRS SHOULD initiate the INVITE without an SDP offer to let the SRC generate the SDP offer with recorded streams." I'm not clear on why these are SHOULD-level requirements, or what the = exception cases are and what the SRC is expected to do in those = exception cases. Could you explain? Section 8.1: Some of the text here seems like it boils down to saying "it's important = to use RTP correctly," without really saying anything specific to siprec = or explaining the rationale for a given recommendation as it relates to = recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I = would suggest adding recording-specific rationales or removing this = text. Nits: Sec 5.2: OLD These metadata updates are normally incremental updates to the initial metadata snapshot to optimize on the size of updates, however, the SRC may also decide to send a new metadata snapshot anytime. NEW These metadata updates are normally incremental updates to the initial metadata snapshot to optimize on the size of updates. However, the SRC may also decide to send a new metadata snapshot any time. =20 OLD such as the attributes of the recorded media stream are located in the SDP of the recording session. NEW such as the attributes of the recorded media stream, are located in the SDP of the recording session. =20 Sec 7.1.2 and 7.3.2: The /=3D in the ABNF should be =3D/ Sec 8.1.2: s/However, as this is not a requirement/However, as these are not = requirements/ Sec 8.1.4: s/when acting a mixer/when acting as a mixer/ Sec 8.2.1.1 and 8.2.1.2: OLD A Recording aware UA SHOULD be prepared to process the RTCP Receiver Reports from the SRS, whereas a recording unaware UA may discard such RTCP packets as not of relevance. NEW A UA SHOULD process the RTCP Receiver Reports from the SRS if it is = recording-aware. Sec 8.2.2: s/from different UA/from different UAs/ Sec 8.3: The text in this section seems duplicative of the packet loss text in = the subsections of 8.2. It should only appear in one place or the other = but not both. Sec 8.4.2: s/In doing to/In doing so/ Sec 8.5: s/an video/a video/ Sec 10: s/When there is no communication sessions/When there is no communication = session/ Sec 11.1.1: OLD When present in a Require header in a request, it indicates that the UAS = MUST be either a SRC or SRS NEW When present in a Require header in a request, it indicates that the UAS = is either an SRC or SRS= From nobody Sat Apr 18 12:43:59 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DA11A8738 for ; Sat, 18 Apr 2015 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_16=0.6, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd1XgnCmzyk8 for ; Sat, 18 Apr 2015 12:43:57 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105951A8725 for ; Sat, 18 Apr 2015 12:43:56 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-01v.sys.comcast.net with comcast id HXjl1q0022GyhjZ01Xjw2Z; Sat, 18 Apr 2015 19:43:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id HXjv1q00F3Ge9ey01Xjw9E; Sat, 18 Apr 2015 19:43:56 +0000 Message-ID: <5532B3FA.2010804@alum.mit.edu> Date: Sat, 18 Apr 2015 15:43:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429386236; bh=4OpekiifbtOFyBvhP11eFRAo50s+3e1y/6H28jIQeDc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c/hQOQaQ1VpJqdpcRIfBgiPZq8YbnsHwhtZZv+M0mswPU/OkeSvpCujThFl5lj3Kw 4oePOlW7hVV11+ktc2GgPMzWuYRGzvajlTWQ+9FQKApoJRFInQthzN3NQww8ENWy06 V1VI22RLRe4QtliYBwG9St2nIwoB7EXFoTr9GmGnaA5KqYqXtMu0/sd8E94L8aiRjg x0HFAUQXiM6Y2BsuvzxZne99duvpk5bS5C9M1Kll3sc0+++m2ZGk2xGjW2Qy3P3JIg 6abstej0MXiIxtcRjHRXVZsznSdq/TXyMIZZdy48QGivCo9v4oXlXrZOzbvnoqQ7c5 pTtXTg98a2z7w== Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 19:43:59 -0000 Alissa, Regarding notification of recording... This is indeed a complex subject, especially in the case of participants that are not recording-aware. Some of the cases that were considered: - typical automation scenarios, where there is a disclaimer given "this call *may* be recorded". That might happen before it is even decided whether to include a recorder. - contractual cases, where participants are made aware separately from any particular call. For instance, a call center agent is well aware that recording will go on. And a call center agent cannot, in practice, be notified in the media, for each call. - IIUC there isn't established law about *how* to notify in-band for media other than audio. Much of this can be mitigated with recording-aware UAs with flexible UIs that can display recording status. But we can't assume that even call center agents will have recording-aware devices. Ultimately this is a *legal* issue more than a technical issue. In band notification is not always required, or desirable. So we tried to put in good mechanisms for the recording-aware, but for others ISTM that the ultimate answer is "consult your lawyer". Thanks, Paul On 4/17/15 6:39 PM, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF LC. Overall it is in good shape. I have a few substantive questions/comments I’d like to discuss before issuing the IETF LC and a bunch of nits. > > Substantive issues: > > General: > I think this document is missing a clear, concise explanation of why the protocol cannot be used for wiretapping. The pieces of this explanation are almost all there in sections 5, 6, and 7, but given the existence of RFC 2804 and general sensitivity towards this issue, I think the document needs to be more explicit about the expected mechanics of the recording indication and preference mechanisms in situations where all involved UAs are recording-aware and where they are not. A simple statement is missing about how it is not possible to use this protocol as standardized without the SRC sending an indication that recording is occurring to every participant in the session. Furthermore, it seems like there are some situations where if a user does not want to be recorded, his only option is to terminate the session. This arises when an SRC does not honor a UA's recording preference set to off, and also possibly when a UA is not recording-aware, right? Those two situations need to be d e scribed explicitly. > > I would suggest adding the explanation to 5.3 and summarizing it in a sentence in the abstract and in the introduction. > > Sec 6.1.2: > "For the communication session, the SRC MUST provide recording > indication to all participants in the CS. A participant UA in a CS > can indicate that it is recording-aware by providing the "record- > aware" option tag, and the SRC MUST provide recording indications in > the new SDP a=record attribute described in the SDP Handling section. > In the absence of the "record-aware" option tag, meaning that the > participant UA is not recording-aware, an SRC MUST provide recording > indications through other means such as playing a tone in-band, if > the SRC is required to do so (e.g. based on policies)." > > The requirements established in this paragraph are a little confusing. First it says the SRC MUST provide recording indication to all participants. Then later it says the SRC MUST provide recording indications through other means ... if required to do so by policy. That sounds like a conditional MUST, which doesn't make sense (since MUST means an absolute requirement), and it also contradicts the MUST in the first sentence. Shouldn't the if clause in the last sentence be dropped? > > Section 6.3: > "A recording-aware UA MUST be prepared to provide a recording > indication to the end user through an appropriate user interface" > > "MUST be prepared to" is a strange construction. I think "MUST provide" is what is meant here. > > Section 7.2: > "The SRS SHOULD NOT add recorded streams in the recording session when > SRS sends a new SDP offer. Similarly, when the SRS starts a > recording session, the SRS SHOULD initiate the INVITE without an SDP > offer to let the SRC generate the SDP offer with recorded streams." > > I'm not clear on why these are SHOULD-level requirements, or what the exception cases are and what the SRC is expected to do in those exception cases. Could you explain? > > Section 8.1: > Some of the text here seems like it boils down to saying "it's important to use RTP correctly," without really saying anything specific to siprec or explaining the rationale for a given recommendation as it relates to recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I would suggest adding recording-specific rationales or removing this text. > > > Nits: > > Sec 5.2: > > OLD > These metadata > updates are normally incremental updates to the initial metadata > snapshot to optimize on the size of updates, however, the SRC may > also decide to send a new metadata snapshot anytime. > > NEW > These metadata > updates are normally incremental updates to the initial metadata > snapshot to optimize on the size of updates. However, the SRC may > also decide to send a new metadata snapshot any time. > > OLD > such as the attributes of the recorded media stream > are located in the SDP of the recording session. > > NEW > such as the attributes of the recorded media stream, > are located in the SDP of the recording session. > > Sec 7.1.2 and 7.3.2: > > The /= in the ABNF should be =/ > > Sec 8.1.2: > s/However, as this is not a requirement/However, as these are not requirements/ > > Sec 8.1.4: > s/when acting a mixer/when acting as a mixer/ > > Sec 8.2.1.1 and 8.2.1.2: > > OLD > A Recording aware UA SHOULD be prepared to > process the RTCP Receiver Reports from the SRS, whereas a recording > unaware UA may discard such RTCP packets as not of relevance. > > NEW > A UA SHOULD process the RTCP Receiver Reports from the SRS if it is recording-aware. > > Sec 8.2.2: > s/from different UA/from different UAs/ > > Sec 8.3: > The text in this section seems duplicative of the packet loss text in the subsections of 8.2. It should only appear in one place or the other but not both. > > Sec 8.4.2: > s/In doing to/In doing so/ > > Sec 8.5: > s/an video/a video/ > > Sec 10: > s/When there is no communication sessions/When there is no communication session/ > > Sec 11.1.1: > > OLD > When present in a Require header in a request, it indicates that the UAS MUST be either a SRC or SRS > > NEW > When present in a Require header in a request, it indicates that the UAS is either an SRC or SRS > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From nobody Sun Apr 19 14:06:19 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C39E1A1BE4 for ; Sun, 19 Apr 2015 14:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DMbXJ_xh0Ym for ; Sun, 19 Apr 2015 14:06:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CF21A1BD1 for ; Sun, 19 Apr 2015 14:06:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 559692030F for ; Sun, 19 Apr 2015 17:06:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 19 Apr 2015 17:06:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=mpkckjPOgokmL0jEEe+y6+KNaiA=; b=x+vkoA hNc99YyCtnNXKHIkT5q3rPg/xe7kH6aLZv/1UC6iZv0eEsHHa/j3ZIhhLU/53v4Z E0++TAf8bxFz01C2lwKBXNRdrL9vZ2qcuPpCJoz88QwOjRlCPl18ejftVOC2xDZJ nz/zR7baR/YkAmYyxq8M/JIYrdc4MtF6ND54A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=mpkckjPOgokmL0j EEe+y6+KNaiA=; b=g325q++5svuaiq8+9VAiberxeAW6scfDxwWfXyQVamlNSdX wfOV4VgECWLoYv1BVvaTWtqgmTxn37jku8ZCcdGqKpItKR0fPfPrvd9LHm6WZP+g oO1cHVkGhGGaq1dtCFrMBIyn+Kv2d3t07YcJSjiIPhqRCJCxbixGIO/mXf60= X-Sasl-enc: 0ggBOqqqn/h6UMwyOFfxDfkjBxU7ezRwDQWlmKJoVt3m 1429477572 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A5DF680106; Sun, 19 Apr 2015 17:06:12 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <5532B3FA.2010804@alum.mit.edu> Date: Sun, 19 Apr 2015 14:06:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5532B3FA.2010804@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: siprec@ietf.org Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 21:06:18 -0000 Hi Paul, What you say below is all fine, but is not clear in the document. My = assumption is that this document is intended to align with RFC 6341, = which left use cases where users are not informed about recording = outside of its scope, and with RFC 7245, which claims that the intended = use of the SIPREC architecture is "only for the case where the users are = aware that they are being recorded.=94 In some cases the assumption may = be that that awareness is gained through an out-of-band mechanism. But = that needs to be explained in the document. Alissa=20 On Apr 18, 2015, at 12:43 PM, Paul Kyzivat = wrote: > Alissa, >=20 > Regarding notification of recording... >=20 > This is indeed a complex subject, especially in the case of = participants that are not recording-aware. Some of the cases that were = considered: >=20 > - typical automation scenarios, where there is a disclaimer given > "this call *may* be recorded". That might happen before it is even > decided whether to include a recorder. >=20 > - contractual cases, where participants are made aware separately > from any particular call. For instance, a call center agent is > well aware that recording will go on. And a call center agent > cannot, in practice, be notified in the media, for each call. >=20 > - IIUC there isn't established law about *how* to notify in-band > for media other than audio. >=20 > Much of this can be mitigated with recording-aware UAs with flexible = UIs that can display recording status. But we can't assume that even = call center agents will have recording-aware devices. >=20 > Ultimately this is a *legal* issue more than a technical issue. In = band notification is not always required, or desirable. >=20 > So we tried to put in good mechanisms for the recording-aware, but for = others ISTM that the ultimate answer is "consult your lawyer". >=20 > Thanks, > Paul >=20 > On 4/17/15 6:39 PM, Alissa Cooper wrote: >> I have reviewed this document in preparation for IETF LC. Overall it = is in good shape. I have a few substantive questions/comments I=92d like = to discuss before issuing the IETF LC and a bunch of nits. >>=20 >> Substantive issues: >>=20 >> General: >> I think this document is missing a clear, concise explanation of why = the protocol cannot be used for wiretapping. The pieces of this = explanation are almost all there in sections 5, 6, and 7, but given the = existence of RFC 2804 and general sensitivity towards this issue, I = think the document needs to be more explicit about the expected = mechanics of the recording indication and preference mechanisms in = situations where all involved UAs are recording-aware and where they are = not. A simple statement is missing about how it is not possible to use = this protocol as standardized without the SRC sending an indication that = recording is occurring to every participant in the session. Furthermore, = it seems like there are some situations where if a user does not want to = be recorded, his only option is to terminate the session. This arises = when an SRC does not honor a UA's recording preference set to off, and = also possibly when a UA is not recording-aware, right? Those two = situations need to be d > e > scribed explicitly. >>=20 >> I would suggest adding the explanation to 5.3 and summarizing it in a = sentence in the abstract and in the introduction. >>=20 >> Sec 6.1.2: >> "For the communication session, the SRC MUST provide recording >> indication to all participants in the CS. A participant UA in a = CS >> can indicate that it is recording-aware by providing the "record- >> aware" option tag, and the SRC MUST provide recording indications = in >> the new SDP a=3Drecord attribute described in the SDP Handling = section. >> In the absence of the "record-aware" option tag, meaning that the >> participant UA is not recording-aware, an SRC MUST provide = recording >> indications through other means such as playing a tone in-band, if >> the SRC is required to do so (e.g. based on policies)." >>=20 >> The requirements established in this paragraph are a little = confusing. First it says the SRC MUST provide recording indication to = all participants. Then later it says the SRC MUST provide recording = indications through other means ... if required to do so by policy. That = sounds like a conditional MUST, which doesn't make sense (since MUST = means an absolute requirement), and it also contradicts the MUST in the = first sentence. Shouldn't the if clause in the last sentence be dropped? >>=20 >> Section 6.3: >> "A recording-aware UA MUST be prepared to provide a recording >> indication to the end user through an appropriate user interface" >>=20 >> "MUST be prepared to" is a strange construction. I think "MUST = provide" is what is meant here. >>=20 >> Section 7.2: >> "The SRS SHOULD NOT add recorded streams in the recording session = when >> SRS sends a new SDP offer. Similarly, when the SRS starts a >> recording session, the SRS SHOULD initiate the INVITE without an = SDP >> offer to let the SRC generate the SDP offer with recorded = streams." >>=20 >> I'm not clear on why these are SHOULD-level requirements, or what the = exception cases are and what the SRC is expected to do in those = exception cases. Could you explain? >>=20 >> Section 8.1: >> Some of the text here seems like it boils down to saying "it's = important to use RTP correctly," without really saying anything specific = to siprec or explaining the rationale for a given recommendation as it = relates to recording. This is particularly true for 8.1.3, 8.1.5, and = 8.1.7.2. I would suggest adding recording-specific rationales or = removing this text. >>=20 >>=20 >> Nits: >>=20 >> Sec 5.2: >>=20 >> OLD >> These metadata >> updates are normally incremental updates to the initial metadata >> snapshot to optimize on the size of updates, however, the SRC may >> also decide to send a new metadata snapshot anytime. >>=20 >> NEW >> These metadata >> updates are normally incremental updates to the initial metadata >> snapshot to optimize on the size of updates. However, the SRC may >> also decide to send a new metadata snapshot any time. >>=20 >> OLD >> such as the attributes of the recorded media stream >> are located in the SDP of the recording session. >>=20 >> NEW >> such as the attributes of the recorded media stream, >> are located in the SDP of the recording session. >>=20 >> Sec 7.1.2 and 7.3.2: >>=20 >> The /=3D in the ABNF should be =3D/ >>=20 >> Sec 8.1.2: >> s/However, as this is not a requirement/However, as these are not = requirements/ >>=20 >> Sec 8.1.4: >> s/when acting a mixer/when acting as a mixer/ >>=20 >> Sec 8.2.1.1 and 8.2.1.2: >>=20 >> OLD >> A Recording aware UA SHOULD be prepared to >> process the RTCP Receiver Reports from the SRS, whereas a = recording >> unaware UA may discard such RTCP packets as not of relevance. >>=20 >> NEW >> A UA SHOULD process the RTCP Receiver Reports from the SRS if it is = recording-aware. >>=20 >> Sec 8.2.2: >> s/from different UA/from different UAs/ >>=20 >> Sec 8.3: >> The text in this section seems duplicative of the packet loss text in = the subsections of 8.2. It should only appear in one place or the other = but not both. >>=20 >> Sec 8.4.2: >> s/In doing to/In doing so/ >>=20 >> Sec 8.5: >> s/an video/a video/ >>=20 >> Sec 10: >> s/When there is no communication sessions/When there is no = communication session/ >>=20 >> Sec 11.1.1: >>=20 >> OLD >> When present in a Require header in a request, it indicates that the = UAS MUST be either a SRC or SRS >>=20 >> NEW >> When present in a Require header in a request, it indicates that the = UAS is either an SRC or SRS >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From nobody Sun Apr 19 15:19:07 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E87B1A8A5A for ; Sun, 19 Apr 2015 15:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_16=0.6, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET-aoMikRvsm for ; Sun, 19 Apr 2015 15:19:03 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB951A8A58 for ; Sun, 19 Apr 2015 15:19:03 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-08v.sys.comcast.net with comcast id HyJr1q00327uzMh01yK2ML; Sun, 19 Apr 2015 22:19:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id HyK21q00C3Ge9ey01yK2DC; Sun, 19 Apr 2015 22:19:02 +0000 Message-ID: <553429D5.7010401@alum.mit.edu> Date: Sun, 19 Apr 2015 18:19:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alissa Cooper References: <5532B3FA.2010804@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429481942; bh=4OH0w8efHhi7KBm0MLskPUwWTld0V/Epxd0MFsetDZw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pkoD+2q166h95TosMjNjZQf8YhOs+SpdETmOOwCjy4+e9R+PQZ1NOELobf3lk+zWg vHUb1mjoM8ZBGxSb2SGFEDQu1d/6il/4MWAjeRSlExwhTU2KHXB2FuhFDmelowJRyF jrhMzw8GbUPR+SrAa3kMdqRMQmUSzNlS06BSgv/El5iEvSdPpGA+fH0C/W55pidZE3 GjCc63pRELftTAiB8TpszWkWu+ADFrJIDiA334KZd3IIcEB83wsxRyWbCTubSf4lrY UOKEBtay/dbwxN5Csd7twlA1Le+BvhAB1ev5Cz16UoNbPCCsMT4tINqPu7p2pCQ+vp BBVNdDW1GfaCw== Archived-At: Cc: siprec@ietf.org Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 22:19:06 -0000 Alissa, On 4/19/15 5:06 PM, Alissa Cooper wrote: > Hi Paul, > > What you say below is all fine, but is not clear in the document. My assumption is that this document is intended to align with RFC 6341, which left use cases where users are not informed about recording outside of its scope, and with RFC 7245, which claims that the intended use of the SIPREC architecture is "only for the case where the users are aware that they are being recorded.” In some cases the assumption may be that that awareness is gained through an out-of-band mechanism. But that needs to be explained in the document. OK. In any case, these were just my personal comments.I certainly don't object to having stuff similar to what I mentioned being included in the text. So I will wait for the chairs and authors to comment. Thanks, Paul > Alissa > > On Apr 18, 2015, at 12:43 PM, Paul Kyzivat wrote: > >> Alissa, >> >> Regarding notification of recording... >> >> This is indeed a complex subject, especially in the case of participants that are not recording-aware. Some of the cases that were considered: >> >> - typical automation scenarios, where there is a disclaimer given >> "this call *may* be recorded". That might happen before it is even >> decided whether to include a recorder. >> >> - contractual cases, where participants are made aware separately >> from any particular call. For instance, a call center agent is >> well aware that recording will go on. And a call center agent >> cannot, in practice, be notified in the media, for each call. >> >> - IIUC there isn't established law about *how* to notify in-band >> for media other than audio. >> >> Much of this can be mitigated with recording-aware UAs with flexible UIs that can display recording status. But we can't assume that even call center agents will have recording-aware devices. >> >> Ultimately this is a *legal* issue more than a technical issue. In band notification is not always required, or desirable. >> >> So we tried to put in good mechanisms for the recording-aware, but for others ISTM that the ultimate answer is "consult your lawyer". >> >> Thanks, >> Paul >> >> On 4/17/15 6:39 PM, Alissa Cooper wrote: >>> I have reviewed this document in preparation for IETF LC. Overall it is in good shape. I have a few substantive questions/comments I’d like to discuss before issuing the IETF LC and a bunch of nits. >>> >>> Substantive issues: >>> >>> General: >>> I think this document is missing a clear, concise explanation of why the protocol cannot be used for wiretapping. The pieces of this explanation are almost all there in sections 5, 6, and 7, but given the existence of RFC 2804 and general sensitivity towards this issue, I think the document needs to be more explicit about the expected mechanics of the recording indication and preference mechanisms in situations where all involved UAs are recording-aware and where they are not. A simple statement is missing about how it is not possible to use this protocol as standardized without the SRC sending an indication that recording is occurring to every participant in the session. Furthermore, it seems like there are some situations where if a user does not want to be recorded, his only option is to terminate the session. This arises when an SRC does not honor a UA's recording preference set to off, and also possibly when a UA is not recording-aware, right? Those two situations need to be d >> e >> scribed explicitly. >>> >>> I would suggest adding the explanation to 5.3 and summarizing it in a sentence in the abstract and in the introduction. >>> >>> Sec 6.1.2: >>> "For the communication session, the SRC MUST provide recording >>> indication to all participants in the CS. A participant UA in a CS >>> can indicate that it is recording-aware by providing the "record- >>> aware" option tag, and the SRC MUST provide recording indications in >>> the new SDP a=record attribute described in the SDP Handling section. >>> In the absence of the "record-aware" option tag, meaning that the >>> participant UA is not recording-aware, an SRC MUST provide recording >>> indications through other means such as playing a tone in-band, if >>> the SRC is required to do so (e.g. based on policies)." >>> >>> The requirements established in this paragraph are a little confusing. First it says the SRC MUST provide recording indication to all participants. Then later it says the SRC MUST provide recording indications through other means ... if required to do so by policy. That sounds like a conditional MUST, which doesn't make sense (since MUST means an absolute requirement), and it also contradicts the MUST in the first sentence. Shouldn't the if clause in the last sentence be dropped? >>> >>> Section 6.3: >>> "A recording-aware UA MUST be prepared to provide a recording >>> indication to the end user through an appropriate user interface" >>> >>> "MUST be prepared to" is a strange construction. I think "MUST provide" is what is meant here. >>> >>> Section 7.2: >>> "The SRS SHOULD NOT add recorded streams in the recording session when >>> SRS sends a new SDP offer. Similarly, when the SRS starts a >>> recording session, the SRS SHOULD initiate the INVITE without an SDP >>> offer to let the SRC generate the SDP offer with recorded streams." >>> >>> I'm not clear on why these are SHOULD-level requirements, or what the exception cases are and what the SRC is expected to do in those exception cases. Could you explain? >>> >>> Section 8.1: >>> Some of the text here seems like it boils down to saying "it's important to use RTP correctly," without really saying anything specific to siprec or explaining the rationale for a given recommendation as it relates to recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I would suggest adding recording-specific rationales or removing this text. >>> >>> >>> Nits: >>> >>> Sec 5.2: >>> >>> OLD >>> These metadata >>> updates are normally incremental updates to the initial metadata >>> snapshot to optimize on the size of updates, however, the SRC may >>> also decide to send a new metadata snapshot anytime. >>> >>> NEW >>> These metadata >>> updates are normally incremental updates to the initial metadata >>> snapshot to optimize on the size of updates. However, the SRC may >>> also decide to send a new metadata snapshot any time. >>> >>> OLD >>> such as the attributes of the recorded media stream >>> are located in the SDP of the recording session. >>> >>> NEW >>> such as the attributes of the recorded media stream, >>> are located in the SDP of the recording session. >>> >>> Sec 7.1.2 and 7.3.2: >>> >>> The /= in the ABNF should be =/ >>> >>> Sec 8.1.2: >>> s/However, as this is not a requirement/However, as these are not requirements/ >>> >>> Sec 8.1.4: >>> s/when acting a mixer/when acting as a mixer/ >>> >>> Sec 8.2.1.1 and 8.2.1.2: >>> >>> OLD >>> A Recording aware UA SHOULD be prepared to >>> process the RTCP Receiver Reports from the SRS, whereas a recording >>> unaware UA may discard such RTCP packets as not of relevance. >>> >>> NEW >>> A UA SHOULD process the RTCP Receiver Reports from the SRS if it is recording-aware. >>> >>> Sec 8.2.2: >>> s/from different UA/from different UAs/ >>> >>> Sec 8.3: >>> The text in this section seems duplicative of the packet loss text in the subsections of 8.2. It should only appear in one place or the other but not both. >>> >>> Sec 8.4.2: >>> s/In doing to/In doing so/ >>> >>> Sec 8.5: >>> s/an video/a video/ >>> >>> Sec 10: >>> s/When there is no communication sessions/When there is no communication session/ >>> >>> Sec 11.1.1: >>> >>> OLD >>> When present in a Require header in a request, it indicates that the UAS MUST be either a SRC or SRS >>> >>> NEW >>> When present in a Require header in a request, it indicates that the UAS is either an SRC or SRS >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > From nobody Mon Apr 20 16:26:56 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8C61B34A4 for ; Mon, 20 Apr 2015 16:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOB05sEamgZN for ; Mon, 20 Apr 2015 16:26:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914721B34A3 for ; Mon, 20 Apr 2015 16:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9331; q=dns/txt; s=iport; t=1429572412; x=1430782012; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9IffiNFt0Aj1AuEJvzVZfP1yV7OoYWPoPgWBitG/y2A=; b=TaQ6ozE3820CCaHciialMrBIRbnZURY2kAxqLpb9z6RwOujFbEt2SlKZ nXDnMQE5ZYsBiETOswRHKu8xis9zmEworpoLbRkCWpgFaNTCC+N74IYht qFLUS45G5/H9DQAf90zJyobXy0Fn+7V888ZEjuqZHVx/sagfAoZ8emINa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CKBQBrijVV/5pdJa1RCoMMUlwFxxoKhTZOAoE8PBABAQEBAQEBfYQhAQEEAQEBZAcbAgEIRicLJQIEARKIKw3KQwEBAQEBAQEDAQEBAQEBARcEizeEJyo6hC0Fiw2EAIIehXKEL4EfgzyMeYNOIoNzb4FEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,611,1422921600"; d="scan'208";a="142930180" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2015 23:26:51 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3KNQppL002363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Apr 2015 23:26:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.36]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 20 Apr 2015 18:26:51 -0500 From: "Charles Eckel (eckelcu)" To: Alissa Cooper , "siprec@ietf.org" Thread-Topic: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 Thread-Index: AQHQeV90HF4W57aPCE6BhC5WhfOBBZ1WbqyA Date: Mon, 20 Apr 2015 23:26:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.154.176.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4BD9168997C14342B6C3197E564E334E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 23:26:55 -0000 Hi Alissa,=20 Thank for your thorough review and detailed comments. Please see how I propose to address each comment inline. On 4/17/15, 3:39 PM, "Alissa Cooper" wrote: >I have reviewed this document in preparation for IETF LC. Overall it is >in good shape. I have a few substantive questions/comments I=B9d like to >discuss before issuing the IETF LC and a bunch of nits. > >Substantive issues: > >General: >I think this document is missing a clear, concise explanation of why the >protocol cannot be used for wiretapping. The pieces of this explanation >are almost all there in sections 5, 6, and 7, but given the existence of >RFC 2804 and general sensitivity towards this issue, I think the document >needs to be more explicit about the expected mechanics of the recording >indication and preference mechanisms in situations where all involved UAs >are recording-aware and where they are not. A simple statement is missing >about how it is not possible to use this protocol as standardized without >the SRC sending an indication that recording is occurring to every >participant in the session. Furthermore, it seems like there are some >situations where if a user does not want to be recorded, his only option >is to terminate the session. This arises when an SRC does not honor a >UA's recording preference set to off, and also possibly when a UA is not >recording-aware, right? Those two situations need to be described >explicitly. > >I would suggest adding the explanation to 5.3 and summarizing it in a >sentence in the abstract and in the introduction. Append the follow to the Abstract: This document only considers active recording, where the SRC purposefully streams media to a SRS. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document. Change section 5.3 as follows: OLD The recording attribute is a declaration by the SRC in the CS to indicate whether recording is taking place. The recording preference attribute is a declaration by the recording- aware UA in the CS to indicate the recording preference. NEW The recording attribute is a declaration by the SRC in the CS to indicate whether recording is taking place. The recording preference attribute is a declaration by the recording- aware UA in the CS to indicate the recording preference. A UA that does not want to be recorded may still be notified recording is occurring for a number of reasons (e.g. it was not capable of indicating its preference, its preference was ignored, etc.) If this occurs, the UA=B9= s only mechanism to avoid being recorded is to terminate its participation in the session. > >Sec 6.1.2: >"For the communication session, the SRC MUST provide recording > indication to all participants in the CS. A participant UA in a CS > can indicate that it is recording-aware by providing the "record- > aware" option tag, and the SRC MUST provide recording indications in > the new SDP a=3Drecord attribute described in the SDP Handling section. > In the absence of the "record-aware" option tag, meaning that the > participant UA is not recording-aware, an SRC MUST provide recording > indications through other means such as playing a tone in-band, if > the SRC is required to do so (e.g. based on policies)." > >The requirements established in this paragraph are a little confusing. >First it says the SRC MUST provide recording indication to all >participants. Then later it says the SRC MUST provide recording >indications through other means ... if required to do so by policy. That >sounds like a conditional MUST, which doesn't make sense (since MUST >means an absolute requirement), and it also contradicts the MUST in the >first sentence. Shouldn't the if clause in the last sentence be dropped? I suggest changing to: In the absence of the "record-aware" option tag, meaning that the participant UA is not recording-aware, an SRC MUST provide recording indications through other means, such as playing a tone in-band, having a signed participant contract in place, etc. > >Section 6.3: >"A recording-aware UA MUST be prepared to provide a recording > indication to the end user through an appropriate user interface" > >"MUST be prepared to" is a strange construction. I think "MUST provide" >is what is meant here. Agreed. > >Section 7.2: >"The SRS SHOULD NOT add recorded streams in the recording session when > SRS sends a new SDP offer. Similarly, when the SRS starts a > recording session, the SRS SHOULD initiate the INVITE without an SDP > offer to let the SRC generate the SDP offer with recorded streams." > >I'm not clear on why these are SHOULD-level requirements, or what the >exception cases are and what the SRC is expected to do in those exception >cases. Could you explain? Me neither. We use tight language in section 9.2 already. Changing both from SHOULD to MUST works for me. > >Section 8.1: >Some of the text here seems like it boils down to saying "it's important >to use RTP correctly," without really saying anything specific to siprec >or explaining the rationale for a given recommendation as it relates to >recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I >would suggest adding recording-specific rationales or removing this text. Sections 8.1.3 states, The SSRC may also be used to separate different sources of media within a single RTP session. For this reason as well as for conflict resolution, it is important that the SRC, SRS, and Recording aware UAs handle changes in SSRC values and properly identify the reason of the change. The CNAME values carried in RTCP facilitate this identification. I think this is a compelling enough reason to call out SSRC handling here. Section 8.1.5 states, End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets if there are more than 31 such sources. How about I add, The ability to identify individual contributing sources is important in the content of SIPREC. This may sometimes be achieved at the signaling level using metadata, as described in [I-D.ietf-siprec-metadata]. SDES provides a mechanism at the RTP level. Section 8.1.7.2 is one of the mechanism to recover from problems with the video stream. How about I extend as follows: Appropriate use of PLI and FIR is important to ensure with minimum overhead that the recorded video is usable (e.g. the necessary reference frames exist for a player to render the recorded video). > > >Nits: > >Sec 5.2: > >OLD >These metadata > updates are normally incremental updates to the initial metadata > snapshot to optimize on the size of updates, however, the SRC may > also decide to send a new metadata snapshot anytime. > >NEW >These metadata > updates are normally incremental updates to the initial metadata > snapshot to optimize on the size of updates. However, the SRC may > also decide to send a new metadata snapshot any time. > =20 >OLD >such as the attributes of the recorded media stream > are located in the SDP of the recording session. > >NEW >such as the attributes of the recorded media stream, > are located in the SDP of the recording session. > =20 >Sec 7.1.2 and 7.3.2: > >The /=3D in the ABNF should be =3D/ > >Sec 8.1.2: >s/However, as this is not a requirement/However, as these are not >requirements/ > >Sec 8.1.4: >s/when acting a mixer/when acting as a mixer/ > >Sec 8.2.1.1 and 8.2.1.2: > >OLD >A Recording aware UA SHOULD be prepared to > process the RTCP Receiver Reports from the SRS, whereas a recording > unaware UA may discard such RTCP packets as not of relevance. > >NEW >A UA SHOULD process the RTCP Receiver Reports from the SRS if it is >recording-aware. > >Sec 8.2.2: >s/from different UA/from different UAs/ > >Sec 8.3: >The text in this section seems duplicative of the packet loss text in the >subsections of 8.2. It should only appear in one place or the other but >not both. Good catch. It originally existed in section 8.3 only. We decided it would be better to handle this in the previous subsections but forgot to remove section 8.3. > >Sec 8.4.2: >s/In doing to/In doing so/ > >Sec 8.5: >s/an video/a video/ > >Sec 10: >s/When there is no communication sessions/When there is no communication >session/ > >Sec 11.1.1: > >OLD >When present in a Require header in a request, it indicates that the UAS >MUST be either a SRC or SRS > >NEW >When present in a Require header in a request, it indicates that the UAS >is either an SRC or SRS These all look fine to me. Cheers, Charles >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Tue Apr 21 08:33:21 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010DD1ACE92 for ; Tue, 21 Apr 2015 08:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pyxyUdWdgWI for ; Tue, 21 Apr 2015 08:33:18 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492EF1ACE8F for ; Tue, 21 Apr 2015 08:32:33 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-10v.sys.comcast.net with comcast id JfWY1q0045BUCh401fYYAl; Tue, 21 Apr 2015 15:32:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id JfYY1q0073Ge9ey01fYYpn; Tue, 21 Apr 2015 15:32:32 +0000 Message-ID: <55366D8F.1070109@alum.mit.edu> Date: Tue, 21 Apr 2015 11:32:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 15:33:20 -0000 Comments on a few of these: On 4/20/15 7:26 PM, Charles Eckel (eckelcu) wrote: > Change section 5.3 as follows: > OLD > The recording attribute is a declaration by > the SRC in the CS to indicate whether recording is taking place. > The recording preference attribute is a declaration by the recording- > aware UA in the CS to indicate the recording preference. > > > NEW > The recording attribute is a declaration by > the SRC in the CS to indicate whether recording is taking place. > The recording preference attribute is a declaration by the recording- > aware UA in the CS to indicate the recording preference. perhaps "indicate *it's* recording preference"? > A UA that does not want to be recorded may still be notified recording > is occurring for a number of reasons (e.g. it was not capable of indicating > its preference, its preference was ignored, etc.) If this occurs, the UA¹s > only mechanism to avoid being recorded is to terminate its participation in > the session. >> Section 6.3: >> "A recording-aware UA MUST be prepared to provide a recording >> indication to the end user through an appropriate user interface" >> >> "MUST be prepared to" is a strange construction. I think "MUST provide" >> is what is meant here. > > Agreed. I think the concern here is that this might be construed to require a real-time notification. A recording-aware UA could be configured by its user to manage recording policy on behalf of the user. For instance, the user may set policy that recording is ok at all times, or that recording is ok when connected to certain parties. In such cases it might not indicate this actively. An extreme example is a special purpose UA for financial service workers. Calls are typically *required* to be recorded. The UA may itself *be* an SRC that records all calls, or a UA intended to be used where an SRC is in all calls. So the user doesn't expect or need an explicit indication. Do we want to preclude such devices? >> Section 7.2: >> "The SRS SHOULD NOT add recorded streams in the recording session when >> SRS sends a new SDP offer. Similarly, when the SRS starts a >> recording session, the SRS SHOULD initiate the INVITE without an SDP >> offer to let the SRC generate the SDP offer with recorded streams." >> >> I'm not clear on why these are SHOULD-level requirements, or what the >> exception cases are and what the SRC is expected to do in those exception >> cases. Could you explain? > > Me neither. We use tight language in section 9.2 already. Changing both > from SHOULD to MUST works for me. There was considerable discussion of cases where the SRS wants to take the initiative of connecting to an SRC for purposes of recording. We ultimately ruled it out of scope, because we couldn't figure out how the SRC could signal what calls should be recorded. But it was my impression that this is a valid use case in some environments, and so may be the subject of future work, or of proprietary extensions. I *guess* that the SHOULD-level here was to provide a little wiggle room for extensions here. Note that if this the SHOULD were violated the SRC still has the option of rejecting the added streams. Since in general it wouldn't know what to do with them that is probably what it would do. So IMO SHOULD is ok here. Thanks, Paul From nobody Wed Apr 22 14:01:56 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA4C1A88FF for ; Wed, 22 Apr 2015 14:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_f4nrvkRluj for ; Wed, 22 Apr 2015 14:01:50 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF981A88F3 for ; Wed, 22 Apr 2015 14:01:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2C65820865 for ; Wed, 22 Apr 2015 17:01:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 22 Apr 2015 17:01:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=4HSId +WeJgRtYVMFTC3EivQTDeE=; b=33f++fk4hohK1kndcfrWSHAY71V7rfPeWZH0L ivstIPPx4nFFCzR5eRiL9C1mbXbrBm6y5zGQktLzZy7G8NiJ6DHQ1O9T2DAO9POF HwSPBwkhbvx/T3S2cVa5LeMiwOfUZSLXkEdgfRakxPPndpJsQuXn8HrBzl5kK5bj 8vBwOI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=4HSId+WeJgRtYVMFTC3EivQTDeE=; b=T07sz tT8HNl4pe2bh0iQPzK55AwAb9JmX7Et+n14qbegvYjvVNrDyDUUfBKPfABKwtXLJ w1+lH0wI3PXSEjDN+QJQjiFSlnibx1B2E8/dPhpFXNWC4CgEjrW0LL74RAlrCCOO 7o9TpRS1uZm8iWsl6/8JaLoNeyD8isEiEIkwP4= X-Sasl-enc: 90FUXGcqC0USngKd7W/pwYtgGc+FEf9acS8467+XVg+W 1429736508 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 184E4C00013; Wed, 22 Apr 2015 17:01:47 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6469306-1E1D-464F-B2BF-E81F7C602A97" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Wed, 22 Apr 2015 14:01:45 -0700 Message-Id: References: To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "siprec@ietf.org" Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:01:55 -0000 --Apple-Mail=_A6469306-1E1D-464F-B2BF-E81F7C602A97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Charles. I=92ll respond to the ones that Paul did not comment on = and await further response from you to Paul on the others. On Apr 20, 2015, at 4:26 PM, Charles Eckel (eckelcu) = wrote: > Hi Alissa,=20 >=20 > Thank for your thorough review and detailed comments. Please see how I > propose to address each comment inline. >=20 > On 4/17/15, 3:39 PM, "Alissa Cooper" wrote: >=20 >> I have reviewed this document in preparation for IETF LC. Overall it = is >> in good shape. I have a few substantive questions/comments I=B9d like = to >> discuss before issuing the IETF LC and a bunch of nits. >>=20 >> Substantive issues: >>=20 >> General: >> I think this document is missing a clear, concise explanation of why = the >> protocol cannot be used for wiretapping. The pieces of this = explanation >> are almost all there in sections 5, 6, and 7, but given the existence = of >> RFC 2804 and general sensitivity towards this issue, I think the = document >> needs to be more explicit about the expected mechanics of the = recording >> indication and preference mechanisms in situations where all involved = UAs >> are recording-aware and where they are not. A simple statement is = missing >> about how it is not possible to use this protocol as standardized = without >> the SRC sending an indication that recording is occurring to every >> participant in the session. Furthermore, it seems like there are some >> situations where if a user does not want to be recorded, his only = option >> is to terminate the session. This arises when an SRC does not honor a >> UA's recording preference set to off, and also possibly when a UA is = not >> recording-aware, right? Those two situations need to be described >> explicitly. >>=20 >> I would suggest adding the explanation to 5.3 and summarizing it in a >> sentence in the abstract and in the introduction. >=20 > Append the follow to the Abstract: >=20 > This document only considers active recording, where the SRC > purposefully streams media to a SRS. =20 I would add =93and all participating user agents are notified of the = recording." > Passive recording, where a > recording device detects media directly from the network (e.g., = using > port-mirroring techniques), is outside the scope of this document. > In addition, lawful intercept is outside the scope of this document. I would suggest repeating the above at the end of the introduction and = adding =93in accordance with RFC 2804=94 to the last sentence. >=20 > Change section 5.3 as follows: > OLD > The recording attribute is a declaration by > the SRC in the CS to indicate whether recording is taking place. > The recording preference attribute is a declaration by the recording- > aware UA in the CS to indicate the recording preference. >=20 >=20 > NEW > The recording attribute is a declaration by > the SRC in the CS to indicate whether recording is taking place. > The recording preference attribute is a declaration by the recording- > aware UA in the CS to indicate the recording preference. > A UA that does not want to be recorded may still be notified recording > is occurring for a number of reasons (e.g. it was not capable of = indicating > its preference, its preference was ignored, etc.) If this occurs, the = UA=B9s > only mechanism to avoid being recorded is to terminate its = participation in > the session. >=20 WFM. I like Paul=92s suggestion too. >=20 >=20 >>=20 >> Sec 6.1.2: >> "For the communication session, the SRC MUST provide recording >> indication to all participants in the CS. A participant UA in a CS >> can indicate that it is recording-aware by providing the "record- >> aware" option tag, and the SRC MUST provide recording indications in >> the new SDP a=3Drecord attribute described in the SDP Handling = section. >> In the absence of the "record-aware" option tag, meaning that the >> participant UA is not recording-aware, an SRC MUST provide recording >> indications through other means such as playing a tone in-band, if >> the SRC is required to do so (e.g. based on policies)." >>=20 >> The requirements established in this paragraph are a little = confusing. >> First it says the SRC MUST provide recording indication to all >> participants. Then later it says the SRC MUST provide recording >> indications through other means ... if required to do so by policy. = That >> sounds like a conditional MUST, which doesn't make sense (since MUST >> means an absolute requirement), and it also contradicts the MUST in = the >> first sentence. Shouldn't the if clause in the last sentence be = dropped? >=20 > I suggest changing to: >=20 > In the absence of the "record-aware" option tag, meaning that the > participant UA is not recording-aware, an SRC MUST provide recording > indications through other means, such as playing a tone in-band, = having > a signed participant contract in place, etc. >=20 WFM >=20 >>=20 >> Section 6.3: >> "A recording-aware UA MUST be prepared to provide a recording >> indication to the end user through an appropriate user interface" >>=20 >> "MUST be prepared to" is a strange construction. I think "MUST = provide" >> is what is meant here. >=20 > Agreed. If this seems too constraining to capture the cases where the indication = is provided out-of-band, I think you could drop =93through an = appropriate user interface." >=20 >>=20 >> Section 7.2: >> "The SRS SHOULD NOT add recorded streams in the recording session = when >> SRS sends a new SDP offer. Similarly, when the SRS starts a >> recording session, the SRS SHOULD initiate the INVITE without an SDP >> offer to let the SRC generate the SDP offer with recorded streams." >>=20 >> I'm not clear on why these are SHOULD-level requirements, or what the >> exception cases are and what the SRC is expected to do in those = exception >> cases. Could you explain? >=20 > Me neither. We use tight language in section 9.2 already. Changing = both > from SHOULD to MUST works for me. >=20 >>=20 >> Section 8.1: >> Some of the text here seems like it boils down to saying "it's = important >> to use RTP correctly," without really saying anything specific to = siprec >> or explaining the rationale for a given recommendation as it relates = to >> recording. This is particularly true for 8.1.3, 8.1.5, and 8.1.7.2. I >> would suggest adding recording-specific rationales or removing this = text. >=20 > Sections 8.1.3 states, >=20 > The SSRC may also be used to separate different sources of media > within a single RTP session. For this reason as well as for = conflict > resolution, it is important that the SRC, SRS, and Recording aware > UAs handle changes in SSRC values and properly identify the reason = of > the change. The CNAME values carried in RTCP facilitate this > identification. >=20 >=20 > I think this is a compelling enough reason to call out SSRC handling = here. Ok, reading it again, I think this if fine. >=20 >=20 > Section 8.1.5 states, >=20 > End systems send one SDES > packet containing their own source identifier (the same as the SSRC > in the fixed RTP header). A mixer sends one SDES packet containing = a > chunk for each contributing source from which it is receiving SDES > information, or multiple complete SDES packets if there are more = than > 31 such sources. >=20 >=20 > How about I add, >=20 > The ability to identify individual contributing sources is important = in > the content of SIPREC. This may sometimes be achieved at the signaling > level using metadata, as described in [I-D.ietf-siprec-metadata]. SDES > provides a mechanism at the RTP level. >=20 WFM >=20 > Section 8.1.7.2 is one of the mechanism to recover from problems with = the > video stream. How about I extend as follows: >=20 > Appropriate use of PLI and FIR is important to ensure with minimum > overhead that the recorded video is usable (e.g. the necessary = reference > frames exist for a player to render the recorded video). >=20 WFM Thanks, Alissa >=20 >=20 >>=20 >>=20 >> Nits: >>=20 >> Sec 5.2: >>=20 >> OLD >> These metadata >> updates are normally incremental updates to the initial metadata >> snapshot to optimize on the size of updates, however, the SRC may >> also decide to send a new metadata snapshot anytime. >>=20 >> NEW >> These metadata >> updates are normally incremental updates to the initial metadata >> snapshot to optimize on the size of updates. However, the SRC may >> also decide to send a new metadata snapshot any time. >>=20 >> OLD >> such as the attributes of the recorded media stream >> are located in the SDP of the recording session. >>=20 >> NEW >> such as the attributes of the recorded media stream, >> are located in the SDP of the recording session. >>=20 >> Sec 7.1.2 and 7.3.2: >>=20 >> The /=3D in the ABNF should be =3D/ >>=20 >> Sec 8.1.2: >> s/However, as this is not a requirement/However, as these are not >> requirements/ >>=20 >> Sec 8.1.4: >> s/when acting a mixer/when acting as a mixer/ >>=20 >> Sec 8.2.1.1 and 8.2.1.2: >>=20 >> OLD >> A Recording aware UA SHOULD be prepared to >> process the RTCP Receiver Reports from the SRS, whereas a recording >> unaware UA may discard such RTCP packets as not of relevance. >>=20 >> NEW >> A UA SHOULD process the RTCP Receiver Reports from the SRS if it is >> recording-aware. >>=20 >> Sec 8.2.2: >> s/from different UA/from different UAs/ >>=20 >> Sec 8.3: >> The text in this section seems duplicative of the packet loss text in = the >> subsections of 8.2. It should only appear in one place or the other = but >> not both. >=20 > Good catch. It originally existed in section 8.3 only. We decided it = would > be better to handle this in the previous subsections but forgot to = remove > section 8.3. >=20 >>=20 >> Sec 8.4.2: >> s/In doing to/In doing so/ >>=20 >> Sec 8.5: >> s/an video/a video/ >>=20 >> Sec 10: >> s/When there is no communication sessions/When there is no = communication >> session/ >>=20 >> Sec 11.1.1: >>=20 >> OLD >> When present in a Require header in a request, it indicates that the = UAS >> MUST be either a SRC or SRS >>=20 >> NEW >> When present in a Require header in a request, it indicates that the = UAS >> is either an SRC or SRS >=20 > These all look fine to me. >=20 > Cheers, > Charles >=20 >=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec --Apple-Mail=_A6469306-1E1D-464F-B2BF-E81F7C602A97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thanks Charles. I=92ll respond to the ones that = Paul did not comment on and await further response from you to Paul on = the others.

On Apr 20, 2015, at 4:26 PM, Charles = Eckel (eckelcu) <eckelcu@cisco.com> = wrote:

Hi Alissa, 

Thank for your = thorough review and detailed comments. Please see how I
propose to = address each comment inline.

On 4/17/15, 3:39 PM, "Alissa Cooper" = <alissa@cooperw.in> = wrote:

I have reviewed this document in = preparation for IETF LC. Overall it is
in good shape. I have a few = substantive questions/comments I=B9d like to
discuss before issuing = the IETF LC and a bunch of nits.

Substantive = issues:

General:
I think this document is missing a clear, = concise explanation of why the
protocol cannot be used for = wiretapping. The pieces of this explanation
are almost all there in = sections 5, 6, and 7, but given the existence of
RFC 2804 and general = sensitivity towards this issue, I think the document
needs to be more = explicit about the expected mechanics of the recording
indication and = preference mechanisms in situations where all involved UAs
are = recording-aware and where they are not. A simple statement is = missing
about how it is not possible to use this protocol as = standardized without
the SRC sending an indication that recording is = occurring to every
participant in the session. Furthermore, it seems = like there are some
situations where if a user does not want to be = recorded, his only option
is to terminate the session. This arises = when an SRC does not honor a
UA's recording preference set to off, = and also possibly when a UA is not
recording-aware, right? Those two = situations need to be described
explicitly.

I would suggest = adding the explanation to 5.3 and summarizing it in a
sentence in the = abstract and in the introduction.

Append the follow = to the Abstract:

This document only considers active recording, = where the SRC
  purposefully streams media to a SRS. =  

I would add =93and all = participating user agents are notified of the = recording."

Passive recording, where a
  recording device detects = media directly from the network (e.g., = using
  port-mirroring techniques), is outside the scope of = this document.
  In addition, lawful intercept is outside = the scope of this document.

I = would suggest repeating the above at the end of the introduction and = adding =93in accordance with RFC 2804=94 to the last = sentence.


Change section 5.3 as follows:
OLD
The recording = attribute is a declaration by
  the SRC in the CS to = indicate whether recording is taking place.
The recording preference = attribute is a declaration by the recording-
  aware UA in = the CS to indicate the recording preference.


NEW
The = recording attribute is a declaration by
the SRC in the CS to indicate = whether recording is taking place.
The recording preference attribute = is a declaration by the recording-
  aware UA in the CS to = indicate the recording preference.
A UA that does not want to be = recorded may still be notified recording
is occurring for a number of = reasons (e.g. it was not capable of indicating
its preference, its = preference was ignored, etc.) If this occurs, the UA=B9s
only = mechanism to avoid being recorded is to terminate its participation = in
the session.


WFM. I = like Paul=92s suggestion too.




Sec= 6.1.2:
"For the communication session, the SRC MUST provide = recording
 indication to all participants in the CS.  A = participant UA in a CS
 can indicate that it is recording-aware = by providing the "record-
 aware" option tag, and the SRC MUST = provide recording indications in
 the new SDP a=3Drecord = attribute described in the SDP Handling section.
 In the absence = of the "record-aware" option tag, meaning that the
 participant = UA is not recording-aware, an SRC MUST provide = recording
 indications through other means such as playing a = tone in-band, if
 the SRC is required to do so (e.g. based on = policies)."

The requirements established in this paragraph are a = little confusing.
First it says the SRC MUST provide recording = indication to all
participants. Then later it says the SRC MUST = provide recording
indications through other means ... if required to = do so by policy. That
sounds like a conditional MUST, which doesn't = make sense (since MUST
means an absolute requirement), and it also = contradicts the MUST in the
first sentence. Shouldn't the if clause = in the last sentence be dropped?

I suggest changing = to:

In the absence of the "record-aware" option tag, meaning that = the
  participant UA is not recording-aware, an SRC MUST = provide recording
  indications through other means, such = as playing a tone in-band, having
a signed participant contract in = place, = etc.


WFM



Section 6.3:
"A recording-aware UA MUST be prepared = to provide a recording
 indication to the end user through an = appropriate user interface"

"MUST be prepared to" is a strange = construction. I think "MUST provide"
is what is meant = here.

Agreed.

If this seems too constraining to capture the cases where the = indication is provided out-of-band, I think you could drop =93through an = appropriate user interface."



Section= 7.2:
"The SRS SHOULD NOT add recorded streams in the recording = session when
 SRS sends a new SDP offer.  Similarly, when = the SRS starts a
 recording session, the SRS SHOULD initiate the = INVITE without an SDP
 offer to let the SRC generate the SDP = offer with recorded streams."

I'm not clear on why these are = SHOULD-level requirements, or what the
exception cases are and what = the SRC is expected to do in those exception
cases. Could you = explain?

Me neither. We use tight language in = section 9.2 already. Changing both
from SHOULD to MUST works for = me.


Section 8.1:
Some of the = text here seems like it boils down to saying "it's important
to use = RTP correctly," without really saying anything specific to siprec
or = explaining the rationale for a given recommendation as it relates = to
recording. This is particularly true for 8.1.3, 8.1.5, and = 8.1.7.2. I
would suggest adding recording-specific rationales or = removing this text.

Sections 8.1.3 = states,

  The SSRC may also be used to separate = different sources of media
  within a single RTP session. =  For this reason as well as for conflict
  resolution, = it is important that the SRC, SRS, and Recording = aware
  UAs handle changes in SSRC values and properly = identify the reason of
  the change.  The CNAME values = carried in RTCP facilitate = this
  identification.


I think this is a = compelling enough reason to call out SSRC handling = here.

Ok, reading it again, I = think this if fine.



Section 8.1.5 = states,

End systems send one SDES
  packet = containing their own source identifier (the same as the = SSRC
  in the fixed RTP header).  A mixer sends one = SDES packet containing a
  chunk for each contributing = source from which it is receiving SDES
  information, or = multiple complete SDES packets if there are more than
  31 = such sources.


How about I add,

The ability to identify = individual contributing sources is important in
the content of = SIPREC. This may sometimes be achieved at the signaling
level using = metadata, as described in [I-D.ietf-siprec-metadata]. SDES
provides a = mechanism at the RTP = level.


WFM


Section 8.1.7.2 is one of the = mechanism to recover from problems with the
video stream. How about I = extend as follows:

Appropriate use of PLI and FIR is important to = ensure with minimum
overhead that the recorded video is usable (e.g. = the necessary reference
frames exist for a player to render the = recorded = video).


WFM

Thanks,
Alissa





Nits:

Sec 5.2:

OLD
These = metadata
 updates are normally incremental updates to the = initial metadata
 snapshot to optimize on the size of updates, = however, the SRC may
 also decide to send a new metadata = snapshot anytime.

NEW
These metadata
 updates are = normally incremental updates to the initial metadata
 snapshot = to optimize on the size of updates. However, the SRC may
 also = decide to send a new metadata snapshot any time.

OLD
such as = the attributes of the recorded media stream
 are located in the = SDP of the recording session.

NEW
such as the attributes of = the recorded media stream,
 are located in the SDP of the = recording session.

Sec 7.1.2 and 7.3.2:

The /=3D in the = ABNF should be =3D/

Sec 8.1.2:
s/However, as this is not a = requirement/However, as these are not
requirements/

Sec = 8.1.4:
s/when acting a mixer/when acting as a mixer/

Sec = 8.2.1.1 and 8.2.1.2:

OLD
A Recording aware UA SHOULD be = prepared to
 process the RTCP Receiver Reports from the SRS, = whereas a recording
 unaware UA may discard such RTCP packets as = not of relevance.

NEW
A UA SHOULD process the RTCP Receiver = Reports from the SRS if it is
recording-aware.

Sec = 8.2.2:
s/from different UA/from different UAs/

Sec 8.3:
The = text in this section seems duplicative of the packet loss text in = the
subsections of 8.2. It should only appear in one place or the = other but
not both.

Good catch. It originally = existed in section 8.3 only. We decided it would
be better to handle = this in the previous subsections but forgot to remove
section = 8.3.


Sec 8.4.2:
s/In doing to/In = doing so/

Sec 8.5:
s/an video/a video/

Sec = 10:
s/When there is no communication sessions/When there is no = communication
session/

Sec 11.1.1:

OLD
When present = in a Require header in a request, it indicates that the UAS
MUST be = either a SRC or SRS

NEW
When present in a Require header in a = request, it indicates that the UAS
is either an SRC or = SRS

These all look fine to = me.

Cheers,
Charles


_______________________________________________
siprec = mailing list
siprec@ietf.org
https://www.ietf.org= /mailman/listinfo/siprec

= --Apple-Mail=_A6469306-1E1D-464F-B2BF-E81F7C602A97-- From nobody Fri Apr 24 11:07:19 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C94E1ACD85 for ; Fri, 24 Apr 2015 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8JCSCfl_ZEa for ; Fri, 24 Apr 2015 11:07:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071521ACCED for ; Fri, 24 Apr 2015 11:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38472; q=dns/txt; s=iport; t=1429898833; x=1431108433; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mTpBgmT5k6uipmuBAGzYjfVSuL9BKUGUCwbhEEnEocc=; b=EZPZCX+B6YVCrvvSQLkI37v/I+Gtv01Wwo0dqik5OoQ2eqOO2D7uQBW/ 6wcahUJavTAzCl9Q/248+sV/B5FRWLniskVpjTO+ePe3jhO48FWw/Q/6j nWy7A9dewDJ4vsQlywrnzRqClOFsbRxPR+8fE93GL6RIQG8SRIy89cE7I 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BrBQCchTpV/4oNJK1RCoJFR1JcBYMVxQkBCYU2TgIcgSJMAQEBAQEBgQuEIAEBAQQBAQFkBwsQAgEIEQMBAiEHBQICJQsUCQgCBA4FiCsNmjScegaUagEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizeEJ0wNBAeCYoFLBY8ygiGGAIQ4gSKDSI0dg04jggccgVFvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,641,1422921600"; d="scan'208,217";a="414923854" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 24 Apr 2015 18:07:11 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3OI7Bgj024812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 18:07:11 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.36]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 13:07:11 -0500 From: "Charles Eckel (eckelcu)" To: Alissa Cooper Thread-Topic: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 Thread-Index: AQHQeV90HF4W57aPCE6BhC5WhfOBBZ1WbqyAgANxe4CAAn6IgA== Date: Fri, 24 Apr 2015 18:07:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.81.226] Content-Type: multipart/alternative; boundary="_000_D15FCC3C478C4eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "siprec@ietf.org" Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:07:17 -0000 --_000_D15FCC3C478C4eckelcuciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGkgQWxpc3NhLA0KDQpZb3VyIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbnMgYWxsIGxvb2sgZmlu ZSB0byBtZS4gSSB3aWxsIGFkZCB5b3VyIHN1Z2dlc3Rpb24gZm9yIHNlY3Rpb24gNi4zIHRvIG15 IHJlc3BvbnNlIHRvIFBhdWwuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KRnJvbTogQWxpc3NhIENv b3BlciA8YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4NCkRhdGU6 IFdlZG5lc2RheSwgQXByaWwgMjIsIDIwMTUgYXQgMjowMSBQTQ0KVG86IENoYXJsZXMgRWNrZWwg PGVja2VsY3VAY2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+DQpDYzogInNpcHJl Y0BpZXRmLm9yZzxtYWlsdG86c2lwcmVjQGlldGYub3JnPiIgPHNpcHJlY0BpZXRmLm9yZzxtYWls dG86c2lwcmVjQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc2lwcmVjXSBBRCBldmFsdWF0aW9u OiBkcmFmdC1pZXRmLXNpcHJlYy1wcm90b2NvbC0xNQ0KDQpUaGFua3MgQ2hhcmxlcy4gSaGvbGwg cmVzcG9uZCB0byB0aGUgb25lcyB0aGF0IFBhdWwgZGlkIG5vdCBjb21tZW50IG9uIGFuZCBhd2Fp dCBmdXJ0aGVyIHJlc3BvbnNlIGZyb20geW91IHRvIFBhdWwgb24gdGhlIG90aGVycy4NCg0KT24g QXByIDIwLCAyMDE1LCBhdCA0OjI2IFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSA8ZWNrZWxj dUBjaXNjby5jb208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIEFsaXNz YSwNCg0KVGhhbmsgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3IGFuZCBkZXRhaWxlZCBjb21tZW50 cy4gUGxlYXNlIHNlZSBob3cgSQ0KcHJvcG9zZSB0byBhZGRyZXNzIGVhY2ggY29tbWVudCBpbmxp bmUuDQoNCk9uIDQvMTcvMTUsIDM6MzkgUE0sICJBbGlzc2EgQ29vcGVyIiA8YWxpc3NhQGNvb3Bl cncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4gd3JvdGU6DQoNCkkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGluIHByZXBhcmF0aW9uIGZvciBJRVRGIExDLiBPdmVyYWxsIGl0IGlz DQppbiBnb29kIHNoYXBlLiBJIGhhdmUgYSBmZXcgc3Vic3RhbnRpdmUgcXVlc3Rpb25zL2NvbW1l bnRzIEmp9mQgbGlrZSB0bw0KZGlzY3VzcyBiZWZvcmUgaXNzdWluZyB0aGUgSUVURiBMQyBhbmQg YSBidW5jaCBvZiBuaXRzLg0KDQpTdWJzdGFudGl2ZSBpc3N1ZXM6DQoNCkdlbmVyYWw6DQpJIHRo aW5rIHRoaXMgZG9jdW1lbnQgaXMgbWlzc2luZyBhIGNsZWFyLCBjb25jaXNlIGV4cGxhbmF0aW9u IG9mIHdoeSB0aGUNCnByb3RvY29sIGNhbm5vdCBiZSB1c2VkIGZvciB3aXJldGFwcGluZy4gVGhl IHBpZWNlcyBvZiB0aGlzIGV4cGxhbmF0aW9uDQphcmUgYWxtb3N0IGFsbCB0aGVyZSBpbiBzZWN0 aW9ucyA1LCA2LCBhbmQgNywgYnV0IGdpdmVuIHRoZSBleGlzdGVuY2Ugb2YNClJGQyAyODA0IGFu ZCBnZW5lcmFsIHNlbnNpdGl2aXR5IHRvd2FyZHMgdGhpcyBpc3N1ZSwgSSB0aGluayB0aGUgZG9j dW1lbnQNCm5lZWRzIHRvIGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgdGhlIGV4cGVjdGVkIG1lY2hh bmljcyBvZiB0aGUgcmVjb3JkaW5nDQppbmRpY2F0aW9uIGFuZCBwcmVmZXJlbmNlIG1lY2hhbmlz bXMgaW4gc2l0dWF0aW9ucyB3aGVyZSBhbGwgaW52b2x2ZWQgVUFzDQphcmUgcmVjb3JkaW5nLWF3 YXJlIGFuZCB3aGVyZSB0aGV5IGFyZSBub3QuIEEgc2ltcGxlIHN0YXRlbWVudCBpcyBtaXNzaW5n DQphYm91dCBob3cgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHVzZSB0aGlzIHByb3RvY29sIGFzIHN0 YW5kYXJkaXplZCB3aXRob3V0DQp0aGUgU1JDIHNlbmRpbmcgYW4gaW5kaWNhdGlvbiB0aGF0IHJl Y29yZGluZyBpcyBvY2N1cnJpbmcgdG8gZXZlcnkNCnBhcnRpY2lwYW50IGluIHRoZSBzZXNzaW9u LiBGdXJ0aGVybW9yZSwgaXQgc2VlbXMgbGlrZSB0aGVyZSBhcmUgc29tZQ0Kc2l0dWF0aW9ucyB3 aGVyZSBpZiBhIHVzZXIgZG9lcyBub3Qgd2FudCB0byBiZSByZWNvcmRlZCwgaGlzIG9ubHkgb3B0 aW9uDQppcyB0byB0ZXJtaW5hdGUgdGhlIHNlc3Npb24uIFRoaXMgYXJpc2VzIHdoZW4gYW4gU1JD IGRvZXMgbm90IGhvbm9yIGENClVBJ3MgcmVjb3JkaW5nIHByZWZlcmVuY2Ugc2V0IHRvIG9mZiwg YW5kIGFsc28gcG9zc2libHkgd2hlbiBhIFVBIGlzIG5vdA0KcmVjb3JkaW5nLWF3YXJlLCByaWdo dD8gVGhvc2UgdHdvIHNpdHVhdGlvbnMgbmVlZCB0byBiZSBkZXNjcmliZWQNCmV4cGxpY2l0bHku DQoNCkkgd291bGQgc3VnZ2VzdCBhZGRpbmcgdGhlIGV4cGxhbmF0aW9uIHRvIDUuMyBhbmQgc3Vt bWFyaXppbmcgaXQgaW4gYQ0Kc2VudGVuY2UgaW4gdGhlIGFic3RyYWN0IGFuZCBpbiB0aGUgaW50 cm9kdWN0aW9uLg0KDQpBcHBlbmQgdGhlIGZvbGxvdyB0byB0aGUgQWJzdHJhY3Q6DQoNClRoaXMg ZG9jdW1lbnQgb25seSBjb25zaWRlcnMgYWN0aXZlIHJlY29yZGluZywgd2hlcmUgdGhlIFNSQw0K ICBwdXJwb3NlZnVsbHkgc3RyZWFtcyBtZWRpYSB0byBhIFNSUy4NCg0KSSB3b3VsZCBhZGQgobBh bmQgYWxsIHBhcnRpY2lwYXRpbmcgdXNlciBhZ2VudHMgYXJlIG5vdGlmaWVkIG9mIHRoZSByZWNv cmRpbmcuIg0KDQpQYXNzaXZlIHJlY29yZGluZywgd2hlcmUgYQ0KICByZWNvcmRpbmcgZGV2aWNl IGRldGVjdHMgbWVkaWEgZGlyZWN0bHkgZnJvbSB0aGUgbmV0d29yayAoZS5nLiwgdXNpbmcNCiAg cG9ydC1taXJyb3JpbmcgdGVjaG5pcXVlcyksIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQogIEluIGFkZGl0aW9uLCBsYXdmdWwgaW50ZXJjZXB0IGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCkkgd291bGQgc3VnZ2VzdCByZXBlYXRpbmcgdGhl IGFib3ZlIGF0IHRoZSBlbmQgb2YgdGhlIGludHJvZHVjdGlvbiBhbmQgYWRkaW5nIKGwaW4gYWNj b3JkYW5jZSB3aXRoIFJGQyAyODA0obEgdG8gdGhlIGxhc3Qgc2VudGVuY2UuDQoNCg0KQ2hhbmdl IHNlY3Rpb24gNS4zIGFzIGZvbGxvd3M6DQpPTEQNClRoZSByZWNvcmRpbmcgYXR0cmlidXRlIGlz IGEgZGVjbGFyYXRpb24gYnkNCiAgdGhlIFNSQyBpbiB0aGUgQ1MgdG8gaW5kaWNhdGUgd2hldGhl ciByZWNvcmRpbmcgaXMgdGFraW5nIHBsYWNlLg0KVGhlIHJlY29yZGluZyBwcmVmZXJlbmNlIGF0 dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5IHRoZSByZWNvcmRpbmctDQogIGF3YXJlIFVBIGlu IHRoZSBDUyB0byBpbmRpY2F0ZSB0aGUgcmVjb3JkaW5nIHByZWZlcmVuY2UuDQoNCg0KTkVXDQpU aGUgcmVjb3JkaW5nIGF0dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5DQp0aGUgU1JDIGluIHRo ZSBDUyB0byBpbmRpY2F0ZSB3aGV0aGVyIHJlY29yZGluZyBpcyB0YWtpbmcgcGxhY2UuDQpUaGUg cmVjb3JkaW5nIHByZWZlcmVuY2UgYXR0cmlidXRlIGlzIGEgZGVjbGFyYXRpb24gYnkgdGhlIHJl Y29yZGluZy0NCiAgYXdhcmUgVUEgaW4gdGhlIENTIHRvIGluZGljYXRlIHRoZSByZWNvcmRpbmcg cHJlZmVyZW5jZS4NCkEgVUEgdGhhdCBkb2VzIG5vdCB3YW50IHRvIGJlIHJlY29yZGVkIG1heSBz dGlsbCBiZSBub3RpZmllZCByZWNvcmRpbmcNCmlzIG9jY3VycmluZyBmb3IgYSBudW1iZXIgb2Yg cmVhc29ucyAoZS5nLiBpdCB3YXMgbm90IGNhcGFibGUgb2YgaW5kaWNhdGluZw0KaXRzIHByZWZl cmVuY2UsIGl0cyBwcmVmZXJlbmNlIHdhcyBpZ25vcmVkLCBldGMuKSBJZiB0aGlzIG9jY3Vycywg dGhlIFVBqfZzDQpvbmx5IG1lY2hhbmlzbSB0byBhdm9pZCBiZWluZyByZWNvcmRlZCBpcyB0byB0 ZXJtaW5hdGUgaXRzIHBhcnRpY2lwYXRpb24gaW4NCnRoZSBzZXNzaW9uLg0KDQoNCldGTS4gSSBs aWtlIFBhdWyhr3Mgc3VnZ2VzdGlvbiB0b28uDQoNCg0KDQoNClNlYyA2LjEuMjoNCiJGb3IgdGhl IGNvbW11bmljYXRpb24gc2Vzc2lvbiwgdGhlIFNSQyBNVVNUIHByb3ZpZGUgcmVjb3JkaW5nDQog aW5kaWNhdGlvbiB0byBhbGwgcGFydGljaXBhbnRzIGluIHRoZSBDUy4gIEEgcGFydGljaXBhbnQg VUEgaW4gYSBDUw0KIGNhbiBpbmRpY2F0ZSB0aGF0IGl0IGlzIHJlY29yZGluZy1hd2FyZSBieSBw cm92aWRpbmcgdGhlICJyZWNvcmQtDQogYXdhcmUiIG9wdGlvbiB0YWcsIGFuZCB0aGUgU1JDIE1V U1QgcHJvdmlkZSByZWNvcmRpbmcgaW5kaWNhdGlvbnMgaW4NCiB0aGUgbmV3IFNEUCBhPXJlY29y ZCBhdHRyaWJ1dGUgZGVzY3JpYmVkIGluIHRoZSBTRFAgSGFuZGxpbmcgc2VjdGlvbi4NCiBJbiB0 aGUgYWJzZW5jZSBvZiB0aGUgInJlY29yZC1hd2FyZSIgb3B0aW9uIHRhZywgbWVhbmluZyB0aGF0 IHRoZQ0KIHBhcnRpY2lwYW50IFVBIGlzIG5vdCByZWNvcmRpbmctYXdhcmUsIGFuIFNSQyBNVVNU IHByb3ZpZGUgcmVjb3JkaW5nDQogaW5kaWNhdGlvbnMgdGhyb3VnaCBvdGhlciBtZWFucyBzdWNo IGFzIHBsYXlpbmcgYSB0b25lIGluLWJhbmQsIGlmDQogdGhlIFNSQyBpcyByZXF1aXJlZCB0byBk byBzbyAoZS5nLiBiYXNlZCBvbiBwb2xpY2llcykuIg0KDQpUaGUgcmVxdWlyZW1lbnRzIGVzdGFi bGlzaGVkIGluIHRoaXMgcGFyYWdyYXBoIGFyZSBhIGxpdHRsZSBjb25mdXNpbmcuDQpGaXJzdCBp dCBzYXlzIHRoZSBTUkMgTVVTVCBwcm92aWRlIHJlY29yZGluZyBpbmRpY2F0aW9uIHRvIGFsbA0K cGFydGljaXBhbnRzLiBUaGVuIGxhdGVyIGl0IHNheXMgdGhlIFNSQyBNVVNUIHByb3ZpZGUgcmVj b3JkaW5nDQppbmRpY2F0aW9ucyB0aHJvdWdoIG90aGVyIG1lYW5zIC4uLiBpZiByZXF1aXJlZCB0 byBkbyBzbyBieSBwb2xpY3kuIFRoYXQNCnNvdW5kcyBsaWtlIGEgY29uZGl0aW9uYWwgTVVTVCwg d2hpY2ggZG9lc24ndCBtYWtlIHNlbnNlIChzaW5jZSBNVVNUDQptZWFucyBhbiBhYnNvbHV0ZSBy ZXF1aXJlbWVudCksIGFuZCBpdCBhbHNvIGNvbnRyYWRpY3RzIHRoZSBNVVNUIGluIHRoZQ0KZmly c3Qgc2VudGVuY2UuIFNob3VsZG4ndCB0aGUgaWYgY2xhdXNlIGluIHRoZSBsYXN0IHNlbnRlbmNl IGJlIGRyb3BwZWQ/DQoNCkkgc3VnZ2VzdCBjaGFuZ2luZyB0bzoNCg0KSW4gdGhlIGFic2VuY2Ug b2YgdGhlICJyZWNvcmQtYXdhcmUiIG9wdGlvbiB0YWcsIG1lYW5pbmcgdGhhdCB0aGUNCiAgcGFy dGljaXBhbnQgVUEgaXMgbm90IHJlY29yZGluZy1hd2FyZSwgYW4gU1JDIE1VU1QgcHJvdmlkZSBy ZWNvcmRpbmcNCiAgaW5kaWNhdGlvbnMgdGhyb3VnaCBvdGhlciBtZWFucywgc3VjaCBhcyBwbGF5 aW5nIGEgdG9uZSBpbi1iYW5kLCBoYXZpbmcNCmEgc2lnbmVkIHBhcnRpY2lwYW50IGNvbnRyYWN0 IGluIHBsYWNlLCBldGMuDQoNCg0KV0ZNDQoNCg0KDQpTZWN0aW9uIDYuMzoNCiJBIHJlY29yZGlu Zy1hd2FyZSBVQSBNVVNUIGJlIHByZXBhcmVkIHRvIHByb3ZpZGUgYSByZWNvcmRpbmcNCiBpbmRp Y2F0aW9uIHRvIHRoZSBlbmQgdXNlciB0aHJvdWdoIGFuIGFwcHJvcHJpYXRlIHVzZXIgaW50ZXJm YWNlIg0KDQoiTVVTVCBiZSBwcmVwYXJlZCB0byIgaXMgYSBzdHJhbmdlIGNvbnN0cnVjdGlvbi4g SSB0aGluayAiTVVTVCBwcm92aWRlIg0KaXMgd2hhdCBpcyBtZWFudCBoZXJlLg0KDQpBZ3JlZWQu DQoNCklmIHRoaXMgc2VlbXMgdG9vIGNvbnN0cmFpbmluZyB0byBjYXB0dXJlIHRoZSBjYXNlcyB3 aGVyZSB0aGUgaW5kaWNhdGlvbiBpcyBwcm92aWRlZCBvdXQtb2YtYmFuZCwgSSB0aGluayB5b3Ug Y291bGQgZHJvcCChsHRocm91Z2ggYW4gYXBwcm9wcmlhdGUgdXNlciBpbnRlcmZhY2UuIg0KDQoN Cg0KU2VjdGlvbiA3LjI6DQoiVGhlIFNSUyBTSE9VTEQgTk9UIGFkZCByZWNvcmRlZCBzdHJlYW1z IGluIHRoZSByZWNvcmRpbmcgc2Vzc2lvbiB3aGVuDQogU1JTIHNlbmRzIGEgbmV3IFNEUCBvZmZl ci4gIFNpbWlsYXJseSwgd2hlbiB0aGUgU1JTIHN0YXJ0cyBhDQogcmVjb3JkaW5nIHNlc3Npb24s IHRoZSBTUlMgU0hPVUxEIGluaXRpYXRlIHRoZSBJTlZJVEUgd2l0aG91dCBhbiBTRFANCiBvZmZl ciB0byBsZXQgdGhlIFNSQyBnZW5lcmF0ZSB0aGUgU0RQIG9mZmVyIHdpdGggcmVjb3JkZWQgc3Ry ZWFtcy4iDQoNCkknbSBub3QgY2xlYXIgb24gd2h5IHRoZXNlIGFyZSBTSE9VTEQtbGV2ZWwgcmVx dWlyZW1lbnRzLCBvciB3aGF0IHRoZQ0KZXhjZXB0aW9uIGNhc2VzIGFyZSBhbmQgd2hhdCB0aGUg U1JDIGlzIGV4cGVjdGVkIHRvIGRvIGluIHRob3NlIGV4Y2VwdGlvbg0KY2FzZXMuIENvdWxkIHlv dSBleHBsYWluPw0KDQpNZSBuZWl0aGVyLiBXZSB1c2UgdGlnaHQgbGFuZ3VhZ2UgaW4gc2VjdGlv biA5LjIgYWxyZWFkeS4gQ2hhbmdpbmcgYm90aA0KZnJvbSBTSE9VTEQgdG8gTVVTVCB3b3JrcyBm b3IgbWUuDQoNCg0KU2VjdGlvbiA4LjE6DQpTb21lIG9mIHRoZSB0ZXh0IGhlcmUgc2VlbXMgbGlr ZSBpdCBib2lscyBkb3duIHRvIHNheWluZyAiaXQncyBpbXBvcnRhbnQNCnRvIHVzZSBSVFAgY29y cmVjdGx5LCIgd2l0aG91dCByZWFsbHkgc2F5aW5nIGFueXRoaW5nIHNwZWNpZmljIHRvIHNpcHJl Yw0Kb3IgZXhwbGFpbmluZyB0aGUgcmF0aW9uYWxlIGZvciBhIGdpdmVuIHJlY29tbWVuZGF0aW9u IGFzIGl0IHJlbGF0ZXMgdG8NCnJlY29yZGluZy4gVGhpcyBpcyBwYXJ0aWN1bGFybHkgdHJ1ZSBm b3IgOC4xLjMsIDguMS41LCBhbmQgOC4xLjcuMi4gSQ0Kd291bGQgc3VnZ2VzdCBhZGRpbmcgcmVj b3JkaW5nLXNwZWNpZmljIHJhdGlvbmFsZXMgb3IgcmVtb3ZpbmcgdGhpcyB0ZXh0Lg0KDQpTZWN0 aW9ucyA4LjEuMyBzdGF0ZXMsDQoNCiAgVGhlIFNTUkMgbWF5IGFsc28gYmUgdXNlZCB0byBzZXBh cmF0ZSBkaWZmZXJlbnQgc291cmNlcyBvZiBtZWRpYQ0KICB3aXRoaW4gYSBzaW5nbGUgUlRQIHNl c3Npb24uICBGb3IgdGhpcyByZWFzb24gYXMgd2VsbCBhcyBmb3IgY29uZmxpY3QNCiAgcmVzb2x1 dGlvbiwgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIFNSQywgU1JTLCBhbmQgUmVjb3JkaW5nIGF3 YXJlDQogIFVBcyBoYW5kbGUgY2hhbmdlcyBpbiBTU1JDIHZhbHVlcyBhbmQgcHJvcGVybHkgaWRl bnRpZnkgdGhlIHJlYXNvbiBvZg0KICB0aGUgY2hhbmdlLiAgVGhlIENOQU1FIHZhbHVlcyBjYXJy aWVkIGluIFJUQ1AgZmFjaWxpdGF0ZSB0aGlzDQogIGlkZW50aWZpY2F0aW9uLg0KDQoNCkkgdGhp bmsgdGhpcyBpcyBhIGNvbXBlbGxpbmcgZW5vdWdoIHJlYXNvbiB0byBjYWxsIG91dCBTU1JDIGhh bmRsaW5nIGhlcmUuDQoNCk9rLCByZWFkaW5nIGl0IGFnYWluLCBJIHRoaW5rIHRoaXMgaWYgZmlu ZS4NCg0KDQoNClNlY3Rpb24gOC4xLjUgc3RhdGVzLA0KDQpFbmQgc3lzdGVtcyBzZW5kIG9uZSBT REVTDQogIHBhY2tldCBjb250YWluaW5nIHRoZWlyIG93biBzb3VyY2UgaWRlbnRpZmllciAodGhl IHNhbWUgYXMgdGhlIFNTUkMNCiAgaW4gdGhlIGZpeGVkIFJUUCBoZWFkZXIpLiAgQSBtaXhlciBz ZW5kcyBvbmUgU0RFUyBwYWNrZXQgY29udGFpbmluZyBhDQogIGNodW5rIGZvciBlYWNoIGNvbnRy aWJ1dGluZyBzb3VyY2UgZnJvbSB3aGljaCBpdCBpcyByZWNlaXZpbmcgU0RFUw0KICBpbmZvcm1h dGlvbiwgb3IgbXVsdGlwbGUgY29tcGxldGUgU0RFUyBwYWNrZXRzIGlmIHRoZXJlIGFyZSBtb3Jl IHRoYW4NCiAgMzEgc3VjaCBzb3VyY2VzLg0KDQoNCkhvdyBhYm91dCBJIGFkZCwNCg0KVGhlIGFi aWxpdHkgdG8gaWRlbnRpZnkgaW5kaXZpZHVhbCBjb250cmlidXRpbmcgc291cmNlcyBpcyBpbXBv cnRhbnQgaW4NCnRoZSBjb250ZW50IG9mIFNJUFJFQy4gVGhpcyBtYXkgc29tZXRpbWVzIGJlIGFj aGlldmVkIGF0IHRoZSBzaWduYWxpbmcNCmxldmVsIHVzaW5nIG1ldGFkYXRhLCBhcyBkZXNjcmli ZWQgaW4gW0ktRC5pZXRmLXNpcHJlYy1tZXRhZGF0YV0uIFNERVMNCnByb3ZpZGVzIGEgbWVjaGFu aXNtIGF0IHRoZSBSVFAgbGV2ZWwuDQoNCg0KV0ZNDQoNCg0KU2VjdGlvbiA4LjEuNy4yIGlzIG9u ZSBvZiB0aGUgbWVjaGFuaXNtIHRvIHJlY292ZXIgZnJvbSBwcm9ibGVtcyB3aXRoIHRoZQ0Kdmlk ZW8gc3RyZWFtLiBIb3cgYWJvdXQgSSBleHRlbmQgYXMgZm9sbG93czoNCg0KQXBwcm9wcmlhdGUg dXNlIG9mIFBMSSBhbmQgRklSIGlzIGltcG9ydGFudCB0byBlbnN1cmUgd2l0aCBtaW5pbXVtDQpv dmVyaGVhZCB0aGF0IHRoZSByZWNvcmRlZCB2aWRlbyBpcyB1c2FibGUgKGUuZy4gdGhlIG5lY2Vz c2FyeSByZWZlcmVuY2UNCmZyYW1lcyBleGlzdCBmb3IgYSBwbGF5ZXIgdG8gcmVuZGVyIHRoZSBy ZWNvcmRlZCB2aWRlbykuDQoNCg0KV0ZNDQoNClRoYW5rcywNCkFsaXNzYQ0KDQoNCg0KDQoNCk5p dHM6DQoNClNlYyA1LjI6DQoNCk9MRA0KVGhlc2UgbWV0YWRhdGENCiB1cGRhdGVzIGFyZSBub3Jt YWxseSBpbmNyZW1lbnRhbCB1cGRhdGVzIHRvIHRoZSBpbml0aWFsIG1ldGFkYXRhDQogc25hcHNo b3QgdG8gb3B0aW1pemUgb24gdGhlIHNpemUgb2YgdXBkYXRlcywgaG93ZXZlciwgdGhlIFNSQyBt YXkNCiBhbHNvIGRlY2lkZSB0byBzZW5kIGEgbmV3IG1ldGFkYXRhIHNuYXBzaG90IGFueXRpbWUu DQoNCk5FVw0KVGhlc2UgbWV0YWRhdGENCiB1cGRhdGVzIGFyZSBub3JtYWxseSBpbmNyZW1lbnRh bCB1cGRhdGVzIHRvIHRoZSBpbml0aWFsIG1ldGFkYXRhDQogc25hcHNob3QgdG8gb3B0aW1pemUg b24gdGhlIHNpemUgb2YgdXBkYXRlcy4gSG93ZXZlciwgdGhlIFNSQyBtYXkNCiBhbHNvIGRlY2lk ZSB0byBzZW5kIGEgbmV3IG1ldGFkYXRhIHNuYXBzaG90IGFueSB0aW1lLg0KDQpPTEQNCnN1Y2gg YXMgdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIHJlY29yZGVkIG1lZGlhIHN0cmVhbQ0KIGFyZSBsb2Nh dGVkIGluIHRoZSBTRFAgb2YgdGhlIHJlY29yZGluZyBzZXNzaW9uLg0KDQpORVcNCnN1Y2ggYXMg dGhlIGF0dHJpYnV0ZXMgb2YgdGhlIHJlY29yZGVkIG1lZGlhIHN0cmVhbSwNCiBhcmUgbG9jYXRl ZCBpbiB0aGUgU0RQIG9mIHRoZSByZWNvcmRpbmcgc2Vzc2lvbi4NCg0KU2VjIDcuMS4yIGFuZCA3 LjMuMjoNCg0KVGhlIC89IGluIHRoZSBBQk5GIHNob3VsZCBiZSA9Lw0KDQpTZWMgOC4xLjI6DQpz L0hvd2V2ZXIsIGFzIHRoaXMgaXMgbm90IGEgcmVxdWlyZW1lbnQvSG93ZXZlciwgYXMgdGhlc2Ug YXJlIG5vdA0KcmVxdWlyZW1lbnRzLw0KDQpTZWMgOC4xLjQ6DQpzL3doZW4gYWN0aW5nIGEgbWl4 ZXIvd2hlbiBhY3RpbmcgYXMgYSBtaXhlci8NCg0KU2VjIDguMi4xLjEgYW5kIDguMi4xLjI6DQoN Ck9MRA0KQSBSZWNvcmRpbmcgYXdhcmUgVUEgU0hPVUxEIGJlIHByZXBhcmVkIHRvDQogcHJvY2Vz cyB0aGUgUlRDUCBSZWNlaXZlciBSZXBvcnRzIGZyb20gdGhlIFNSUywgd2hlcmVhcyBhIHJlY29y ZGluZw0KIHVuYXdhcmUgVUEgbWF5IGRpc2NhcmQgc3VjaCBSVENQIHBhY2tldHMgYXMgbm90IG9m IHJlbGV2YW5jZS4NCg0KTkVXDQpBIFVBIFNIT1VMRCBwcm9jZXNzIHRoZSBSVENQIFJlY2VpdmVy IFJlcG9ydHMgZnJvbSB0aGUgU1JTIGlmIGl0IGlzDQpyZWNvcmRpbmctYXdhcmUuDQoNClNlYyA4 LjIuMjoNCnMvZnJvbSBkaWZmZXJlbnQgVUEvZnJvbSBkaWZmZXJlbnQgVUFzLw0KDQpTZWMgOC4z Og0KVGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uIHNlZW1zIGR1cGxpY2F0aXZlIG9mIHRoZSBwYWNr ZXQgbG9zcyB0ZXh0IGluIHRoZQ0Kc3Vic2VjdGlvbnMgb2YgOC4yLiBJdCBzaG91bGQgb25seSBh cHBlYXIgaW4gb25lIHBsYWNlIG9yIHRoZSBvdGhlciBidXQNCm5vdCBib3RoLg0KDQpHb29kIGNh dGNoLiBJdCBvcmlnaW5hbGx5IGV4aXN0ZWQgaW4gc2VjdGlvbiA4LjMgb25seS4gV2UgZGVjaWRl ZCBpdCB3b3VsZA0KYmUgYmV0dGVyIHRvIGhhbmRsZSB0aGlzIGluIHRoZSBwcmV2aW91cyBzdWJz ZWN0aW9ucyBidXQgZm9yZ290IHRvIHJlbW92ZQ0Kc2VjdGlvbiA4LjMuDQoNCg0KU2VjIDguNC4y Og0Kcy9JbiBkb2luZyB0by9JbiBkb2luZyBzby8NCg0KU2VjIDguNToNCnMvYW4gdmlkZW8vYSB2 aWRlby8NCg0KU2VjIDEwOg0Kcy9XaGVuIHRoZXJlIGlzIG5vIGNvbW11bmljYXRpb24gc2Vzc2lv bnMvV2hlbiB0aGVyZSBpcyBubyBjb21tdW5pY2F0aW9uDQpzZXNzaW9uLw0KDQpTZWMgMTEuMS4x Og0KDQpPTEQNCldoZW4gcHJlc2VudCBpbiBhIFJlcXVpcmUgaGVhZGVyIGluIGEgcmVxdWVzdCwg aXQgaW5kaWNhdGVzIHRoYXQgdGhlIFVBUw0KTVVTVCBiZSBlaXRoZXIgYSBTUkMgb3IgU1JTDQoN Ck5FVw0KV2hlbiBwcmVzZW50IGluIGEgUmVxdWlyZSBoZWFkZXIgaW4gYSByZXF1ZXN0LCBpdCBp bmRpY2F0ZXMgdGhhdCB0aGUgVUFTDQppcyBlaXRoZXIgYW4gU1JDIG9yIFNSUw0KDQpUaGVzZSBh bGwgbG9vayBmaW5lIHRvIG1lLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcHJlYyBtYWlsaW5nIGxpc3QN CnNpcHJlY0BpZXRmLm9yZzxtYWlsdG86c2lwcmVjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCg0K --_000_D15FCC3C478C4eckelcuciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <47470EA9B7ACB448A47429B08B0F50D7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTZweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgQWxpc3Nh LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91ciBhZGRpdGlvbmFsIGNsYXJpZmlj YXRpb25zIGFsbCBsb29rIGZpbmUgdG8gbWUuIEkgd2lsbCBhZGQgeW91ciBzdWdnZXN0aW9uIGZv ciBzZWN0aW9uIDYuMyB0byBteSByZXNwb25zZSB0byBQYXVsLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj5DaGFybGVzPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPkFsaXNzYSBDb29wZXIgJmx0OzxhIGhyZWY9Im1haWx0bzphbGlzc2FA Y29vcGVydy5pbiI+YWxpc3NhQGNvb3BlcncuaW48L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBBcHJpbCAyMiwgMjAxNSBh dCAyOjAxIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ Q2hhcmxlcyBFY2tlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIj5lY2tl bGN1QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcHJlY0BpZXRmLm9yZyI+c2lwcmVj QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcHJlY0BpZXRmLm9yZyI+ c2lwcmVjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbc2lwcmVjXSBBRCBldmFsdWF0aW9uOiBkcmFmdC1pZXRm LXNpcHJlYy1wcm90b2NvbC0xNTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+ DQo8ZGl2PlRoYW5rcyBDaGFybGVzLiBJoa9sbCByZXNwb25kIHRvIHRoZSBvbmVzIHRoYXQgUGF1 bCBkaWQgbm90IGNvbW1lbnQgb24gYW5kIGF3YWl0IGZ1cnRoZXIgcmVzcG9uc2UgZnJvbSB5b3Ug dG8gUGF1bCBvbiB0aGUgb3RoZXJzLjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXY+T24gQXByIDIw LCAyMDE1LCBhdCA0OjI2IFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVja2VsY3VAY2lzY28uY29tIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KSGkgQWxpc3NhLDxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpUaGFuayBmb3Ig eW91ciB0aG9yb3VnaCByZXZpZXcgYW5kIGRldGFpbGVkIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGhv dyBJPGJyPg0KcHJvcG9zZSB0byBhZGRyZXNzIGVhY2ggY29tbWVudCBpbmxpbmUuPGJyPg0KPGJy Pg0KT24gNC8xNy8xNSwgMzozOSBQTSwgJnF1b3Q7QWxpc3NhIENvb3BlciZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIj5hbGlzc2FAY29vcGVydy5pbjwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGluIHByZXBhcmF0aW9uIGZvciBJRVRGIExDLiBPdmVyYWxsIGl0IGlz PGJyPg0KaW4gZ29vZCBzaGFwZS4gSSBoYXZlIGEgZmV3IHN1YnN0YW50aXZlIHF1ZXN0aW9ucy9j b21tZW50cyBJqfZkIGxpa2UgdG88YnI+DQpkaXNjdXNzIGJlZm9yZSBpc3N1aW5nIHRoZSBJRVRG IExDIGFuZCBhIGJ1bmNoIG9mIG5pdHMuPGJyPg0KPGJyPg0KU3Vic3RhbnRpdmUgaXNzdWVzOjxi cj4NCjxicj4NCkdlbmVyYWw6PGJyPg0KSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIG1pc3Npbmcg YSBjbGVhciwgY29uY2lzZSBleHBsYW5hdGlvbiBvZiB3aHkgdGhlPGJyPg0KcHJvdG9jb2wgY2Fu bm90IGJlIHVzZWQgZm9yIHdpcmV0YXBwaW5nLiBUaGUgcGllY2VzIG9mIHRoaXMgZXhwbGFuYXRp b248YnI+DQphcmUgYWxtb3N0IGFsbCB0aGVyZSBpbiBzZWN0aW9ucyA1LCA2LCBhbmQgNywgYnV0 IGdpdmVuIHRoZSBleGlzdGVuY2Ugb2Y8YnI+DQpSRkMgMjgwNCBhbmQgZ2VuZXJhbCBzZW5zaXRp dml0eSB0b3dhcmRzIHRoaXMgaXNzdWUsIEkgdGhpbmsgdGhlIGRvY3VtZW50PGJyPg0KbmVlZHMg dG8gYmUgbW9yZSBleHBsaWNpdCBhYm91dCB0aGUgZXhwZWN0ZWQgbWVjaGFuaWNzIG9mIHRoZSBy ZWNvcmRpbmc8YnI+DQppbmRpY2F0aW9uIGFuZCBwcmVmZXJlbmNlIG1lY2hhbmlzbXMgaW4gc2l0 dWF0aW9ucyB3aGVyZSBhbGwgaW52b2x2ZWQgVUFzPGJyPg0KYXJlIHJlY29yZGluZy1hd2FyZSBh bmQgd2hlcmUgdGhleSBhcmUgbm90LiBBIHNpbXBsZSBzdGF0ZW1lbnQgaXMgbWlzc2luZzxicj4N CmFib3V0IGhvdyBpdCBpcyBub3QgcG9zc2libGUgdG8gdXNlIHRoaXMgcHJvdG9jb2wgYXMgc3Rh bmRhcmRpemVkIHdpdGhvdXQ8YnI+DQp0aGUgU1JDIHNlbmRpbmcgYW4gaW5kaWNhdGlvbiB0aGF0 IHJlY29yZGluZyBpcyBvY2N1cnJpbmcgdG8gZXZlcnk8YnI+DQpwYXJ0aWNpcGFudCBpbiB0aGUg c2Vzc2lvbi4gRnVydGhlcm1vcmUsIGl0IHNlZW1zIGxpa2UgdGhlcmUgYXJlIHNvbWU8YnI+DQpz aXR1YXRpb25zIHdoZXJlIGlmIGEgdXNlciBkb2VzIG5vdCB3YW50IHRvIGJlIHJlY29yZGVkLCBo aXMgb25seSBvcHRpb248YnI+DQppcyB0byB0ZXJtaW5hdGUgdGhlIHNlc3Npb24uIFRoaXMgYXJp c2VzIHdoZW4gYW4gU1JDIGRvZXMgbm90IGhvbm9yIGE8YnI+DQpVQSdzIHJlY29yZGluZyBwcmVm ZXJlbmNlIHNldCB0byBvZmYsIGFuZCBhbHNvIHBvc3NpYmx5IHdoZW4gYSBVQSBpcyBub3Q8YnI+ DQpyZWNvcmRpbmctYXdhcmUsIHJpZ2h0PyBUaG9zZSB0d28gc2l0dWF0aW9ucyBuZWVkIHRvIGJl IGRlc2NyaWJlZDxicj4NCmV4cGxpY2l0bHkuPGJyPg0KPGJyPg0KSSB3b3VsZCBzdWdnZXN0IGFk ZGluZyB0aGUgZXhwbGFuYXRpb24gdG8gNS4zIGFuZCBzdW1tYXJpemluZyBpdCBpbiBhPGJyPg0K c2VudGVuY2UgaW4gdGhlIGFic3RyYWN0IGFuZCBpbiB0aGUgaW50cm9kdWN0aW9uLjxicj4NCjwv YmxvY2txdW90ZT4NCjxicj4NCkFwcGVuZCB0aGUgZm9sbG93IHRvIHRoZSBBYnN0cmFjdDo8YnI+ DQo8YnI+DQpUaGlzIGRvY3VtZW50IG9ubHkgY29uc2lkZXJzIGFjdGl2ZSByZWNvcmRpbmcsIHdo ZXJlIHRoZSBTUkM8YnI+DQombmJzcDsmbmJzcDtwdXJwb3NlZnVsbHkgc3RyZWFtcyBtZWRpYSB0 byBhIFNSUy4gJm5ic3A7PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JIHdvdWxkIGFkZCChsGFuZCBhbGwgcGFydGljaXBhdGluZyB1c2VyIGFnZW50cyBhcmUg bm90aWZpZWQgb2YgdGhlIHJlY29yZGluZy4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi IHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1B UkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7Ij4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0 eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyI+DQpQYXNzaXZlIHJlY29yZGluZywgd2hlcmUgYTxicj4NCiZuYnNwOyZuYnNwO3JlY29y ZGluZyBkZXZpY2UgZGV0ZWN0cyBtZWRpYSBkaXJlY3RseSBmcm9tIHRoZSBuZXR3b3JrIChlLmcu LCB1c2luZzxicj4NCiZuYnNwOyZuYnNwO3BvcnQtbWlycm9yaW5nIHRlY2huaXF1ZXMpLCBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Ljxicj4NCiZuYnNwOyZuYnNwO0luIGFk ZGl0aW9uLCBsYXdmdWwgaW50ZXJjZXB0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuPGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5JIHdvdWxkIHN1Z2dlc3QgcmVwZWF0aW5nIHRoZSBhYm92ZSBhdCB0aGUgZW5kIG9mIHRoZSBp bnRyb2R1Y3Rpb24gYW5kIGFkZGluZyChsGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMjgwNKGxIHRv IHRoZSBsYXN0IHNlbnRlbmNlLjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+DQo8YnI+DQpDaGFuZ2Ugc2VjdGlvbiA1LjMgYXMgZm9sbG93czo8YnI+ DQpPTEQ8YnI+DQpUaGUgcmVjb3JkaW5nIGF0dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5PGJy Pg0KJm5ic3A7Jm5ic3A7dGhlIFNSQyBpbiB0aGUgQ1MgdG8gaW5kaWNhdGUgd2hldGhlciByZWNv cmRpbmcgaXMgdGFraW5nIHBsYWNlLjxicj4NClRoZSByZWNvcmRpbmcgcHJlZmVyZW5jZSBhdHRy aWJ1dGUgaXMgYSBkZWNsYXJhdGlvbiBieSB0aGUgcmVjb3JkaW5nLTxicj4NCiZuYnNwOyZuYnNw O2F3YXJlIFVBIGluIHRoZSBDUyB0byBpbmRpY2F0ZSB0aGUgcmVjb3JkaW5nIHByZWZlcmVuY2Uu PGJyPg0KPGJyPg0KPGJyPg0KTkVXPGJyPg0KVGhlIHJlY29yZGluZyBhdHRyaWJ1dGUgaXMgYSBk ZWNsYXJhdGlvbiBieTxicj4NCnRoZSBTUkMgaW4gdGhlIENTIHRvIGluZGljYXRlIHdoZXRoZXIg cmVjb3JkaW5nIGlzIHRha2luZyBwbGFjZS48YnI+DQpUaGUgcmVjb3JkaW5nIHByZWZlcmVuY2Ug YXR0cmlidXRlIGlzIGEgZGVjbGFyYXRpb24gYnkgdGhlIHJlY29yZGluZy08YnI+DQombmJzcDsm bmJzcDthd2FyZSBVQSBpbiB0aGUgQ1MgdG8gaW5kaWNhdGUgdGhlIHJlY29yZGluZyBwcmVmZXJl bmNlLjxicj4NCkEgVUEgdGhhdCBkb2VzIG5vdCB3YW50IHRvIGJlIHJlY29yZGVkIG1heSBzdGls bCBiZSBub3RpZmllZCByZWNvcmRpbmc8YnI+DQppcyBvY2N1cnJpbmcgZm9yIGEgbnVtYmVyIG9m IHJlYXNvbnMgKGUuZy4gaXQgd2FzIG5vdCBjYXBhYmxlIG9mIGluZGljYXRpbmc8YnI+DQppdHMg cHJlZmVyZW5jZSwgaXRzIHByZWZlcmVuY2Ugd2FzIGlnbm9yZWQsIGV0Yy4pIElmIHRoaXMgb2Nj dXJzLCB0aGUgVUGp9nM8YnI+DQpvbmx5IG1lY2hhbmlzbSB0byBhdm9pZCBiZWluZyByZWNvcmRl ZCBpcyB0byB0ZXJtaW5hdGUgaXRzIHBhcnRpY2lwYXRpb24gaW48YnI+DQp0aGUgc2Vzc2lvbi48 YnI+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PldGTS4gSSBsaWtlIFBhdWyhr3Mgc3VnZ2VzdGlvbiB0b28uPC9kaXY+DQo8YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxicj4NCjxicj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxicj4NClNlYyA2LjEuMjo8YnI+DQomcXVvdDtGb3IgdGhlIGNvbW11bmlj YXRpb24gc2Vzc2lvbiwgdGhlIFNSQyBNVVNUIHByb3ZpZGUgcmVjb3JkaW5nPGJyPg0KJm5ic3A7 aW5kaWNhdGlvbiB0byBhbGwgcGFydGljaXBhbnRzIGluIHRoZSBDUy4gJm5ic3A7QSBwYXJ0aWNp cGFudCBVQSBpbiBhIENTPGJyPg0KJm5ic3A7Y2FuIGluZGljYXRlIHRoYXQgaXQgaXMgcmVjb3Jk aW5nLWF3YXJlIGJ5IHByb3ZpZGluZyB0aGUgJnF1b3Q7cmVjb3JkLTxicj4NCiZuYnNwO2F3YXJl JnF1b3Q7IG9wdGlvbiB0YWcsIGFuZCB0aGUgU1JDIE1VU1QgcHJvdmlkZSByZWNvcmRpbmcgaW5k aWNhdGlvbnMgaW48YnI+DQombmJzcDt0aGUgbmV3IFNEUCBhPXJlY29yZCBhdHRyaWJ1dGUgZGVz Y3JpYmVkIGluIHRoZSBTRFAgSGFuZGxpbmcgc2VjdGlvbi48YnI+DQombmJzcDtJbiB0aGUgYWJz ZW5jZSBvZiB0aGUgJnF1b3Q7cmVjb3JkLWF3YXJlJnF1b3Q7IG9wdGlvbiB0YWcsIG1lYW5pbmcg dGhhdCB0aGU8YnI+DQombmJzcDtwYXJ0aWNpcGFudCBVQSBpcyBub3QgcmVjb3JkaW5nLWF3YXJl LCBhbiBTUkMgTVVTVCBwcm92aWRlIHJlY29yZGluZzxicj4NCiZuYnNwO2luZGljYXRpb25zIHRo cm91Z2ggb3RoZXIgbWVhbnMgc3VjaCBhcyBwbGF5aW5nIGEgdG9uZSBpbi1iYW5kLCBpZjxicj4N CiZuYnNwO3RoZSBTUkMgaXMgcmVxdWlyZWQgdG8gZG8gc28gKGUuZy4gYmFzZWQgb24gcG9saWNp ZXMpLiZxdW90Ozxicj4NCjxicj4NClRoZSByZXF1aXJlbWVudHMgZXN0YWJsaXNoZWQgaW4gdGhp cyBwYXJhZ3JhcGggYXJlIGEgbGl0dGxlIGNvbmZ1c2luZy48YnI+DQpGaXJzdCBpdCBzYXlzIHRo ZSBTUkMgTVVTVCBwcm92aWRlIHJlY29yZGluZyBpbmRpY2F0aW9uIHRvIGFsbDxicj4NCnBhcnRp Y2lwYW50cy4gVGhlbiBsYXRlciBpdCBzYXlzIHRoZSBTUkMgTVVTVCBwcm92aWRlIHJlY29yZGlu Zzxicj4NCmluZGljYXRpb25zIHRocm91Z2ggb3RoZXIgbWVhbnMgLi4uIGlmIHJlcXVpcmVkIHRv IGRvIHNvIGJ5IHBvbGljeS4gVGhhdDxicj4NCnNvdW5kcyBsaWtlIGEgY29uZGl0aW9uYWwgTVVT VCwgd2hpY2ggZG9lc24ndCBtYWtlIHNlbnNlIChzaW5jZSBNVVNUPGJyPg0KbWVhbnMgYW4gYWJz b2x1dGUgcmVxdWlyZW1lbnQpLCBhbmQgaXQgYWxzbyBjb250cmFkaWN0cyB0aGUgTVVTVCBpbiB0 aGU8YnI+DQpmaXJzdCBzZW50ZW5jZS4gU2hvdWxkbid0IHRoZSBpZiBjbGF1c2UgaW4gdGhlIGxh c3Qgc2VudGVuY2UgYmUgZHJvcHBlZD88YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQpJIHN1Z2dl c3QgY2hhbmdpbmcgdG86PGJyPg0KPGJyPg0KSW4gdGhlIGFic2VuY2Ugb2YgdGhlICZxdW90O3Jl Y29yZC1hd2FyZSZxdW90OyBvcHRpb24gdGFnLCBtZWFuaW5nIHRoYXQgdGhlPGJyPg0KJm5ic3A7 Jm5ic3A7cGFydGljaXBhbnQgVUEgaXMgbm90IHJlY29yZGluZy1hd2FyZSwgYW4gU1JDIE1VU1Qg cHJvdmlkZSByZWNvcmRpbmc8YnI+DQombmJzcDsmbmJzcDtpbmRpY2F0aW9ucyB0aHJvdWdoIG90 aGVyIG1lYW5zLCBzdWNoIGFzIHBsYXlpbmcgYSB0b25lIGluLWJhbmQsIGhhdmluZzxicj4NCmEg c2lnbmVkIHBhcnRpY2lwYW50IGNvbnRyYWN0IGluIHBsYWNlLCBldGMuPGJyPg0KPGJyPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XRk08L2Rpdj4NCjxi cj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KU2VjdGlvbiA2LjM6PGJyPg0KJnF1b3Q7QSByZWNvcmRp bmctYXdhcmUgVUEgTVVTVCBiZSBwcmVwYXJlZCB0byBwcm92aWRlIGEgcmVjb3JkaW5nPGJyPg0K Jm5ic3A7aW5kaWNhdGlvbiB0byB0aGUgZW5kIHVzZXIgdGhyb3VnaCBhbiBhcHByb3ByaWF0ZSB1 c2VyIGludGVyZmFjZSZxdW90Ozxicj4NCjxicj4NCiZxdW90O01VU1QgYmUgcHJlcGFyZWQgdG8m cXVvdDsgaXMgYSBzdHJhbmdlIGNvbnN0cnVjdGlvbi4gSSB0aGluayAmcXVvdDtNVVNUIHByb3Zp ZGUmcXVvdDs8YnI+DQppcyB3aGF0IGlzIG1lYW50IGhlcmUuPGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJyPg0KQWdyZWVkLjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SWYgdGhpcyBzZWVtcyB0b28gY29uc3RyYWluaW5nIHRvIGNhcHR1cmUgdGhlIGNh c2VzIHdoZXJlIHRoZSBpbmRpY2F0aW9uIGlzIHByb3ZpZGVkIG91dC1vZi1iYW5kLCBJIHRoaW5r IHlvdSBjb3VsZCBkcm9wIKGwdGhyb3VnaCBhbiBhcHByb3ByaWF0ZSB1c2VyIGludGVyZmFjZS4m cXVvdDs8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0i Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KU2VjdGlvbiA3LjI6PGJyPg0K JnF1b3Q7VGhlIFNSUyBTSE9VTEQgTk9UIGFkZCByZWNvcmRlZCBzdHJlYW1zIGluIHRoZSByZWNv cmRpbmcgc2Vzc2lvbiB3aGVuPGJyPg0KJm5ic3A7U1JTIHNlbmRzIGEgbmV3IFNEUCBvZmZlci4g Jm5ic3A7U2ltaWxhcmx5LCB3aGVuIHRoZSBTUlMgc3RhcnRzIGE8YnI+DQombmJzcDtyZWNvcmRp bmcgc2Vzc2lvbiwgdGhlIFNSUyBTSE9VTEQgaW5pdGlhdGUgdGhlIElOVklURSB3aXRob3V0IGFu IFNEUDxicj4NCiZuYnNwO29mZmVyIHRvIGxldCB0aGUgU1JDIGdlbmVyYXRlIHRoZSBTRFAgb2Zm ZXIgd2l0aCByZWNvcmRlZCBzdHJlYW1zLiZxdW90Ozxicj4NCjxicj4NCkknbSBub3QgY2xlYXIg b24gd2h5IHRoZXNlIGFyZSBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1lbnRzLCBvciB3aGF0IHRoZTxi cj4NCmV4Y2VwdGlvbiBjYXNlcyBhcmUgYW5kIHdoYXQgdGhlIFNSQyBpcyBleHBlY3RlZCB0byBk byBpbiB0aG9zZSBleGNlcHRpb248YnI+DQpjYXNlcy4gQ291bGQgeW91IGV4cGxhaW4/PGJyPg0K PC9ibG9ja3F1b3RlPg0KPGJyPg0KTWUgbmVpdGhlci4gV2UgdXNlIHRpZ2h0IGxhbmd1YWdlIGlu IHNlY3Rpb24gOS4yIGFscmVhZHkuIENoYW5naW5nIGJvdGg8YnI+DQpmcm9tIFNIT1VMRCB0byBN VVNUIHdvcmtzIGZvciBtZS48YnI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+ DQpTZWN0aW9uIDguMTo8YnI+DQpTb21lIG9mIHRoZSB0ZXh0IGhlcmUgc2VlbXMgbGlrZSBpdCBi b2lscyBkb3duIHRvIHNheWluZyAmcXVvdDtpdCdzIGltcG9ydGFudDxicj4NCnRvIHVzZSBSVFAg Y29ycmVjdGx5LCZxdW90OyB3aXRob3V0IHJlYWxseSBzYXlpbmcgYW55dGhpbmcgc3BlY2lmaWMg dG8gc2lwcmVjPGJyPg0Kb3IgZXhwbGFpbmluZyB0aGUgcmF0aW9uYWxlIGZvciBhIGdpdmVuIHJl Y29tbWVuZGF0aW9uIGFzIGl0IHJlbGF0ZXMgdG88YnI+DQpyZWNvcmRpbmcuIFRoaXMgaXMgcGFy dGljdWxhcmx5IHRydWUgZm9yIDguMS4zLCA4LjEuNSwgYW5kIDguMS43LjIuIEk8YnI+DQp3b3Vs ZCBzdWdnZXN0IGFkZGluZyByZWNvcmRpbmctc3BlY2lmaWMgcmF0aW9uYWxlcyBvciByZW1vdmlu ZyB0aGlzIHRleHQuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KU2VjdGlvbnMgOC4xLjMgc3Rh dGVzLDxicj4NCjxicj4NCiZuYnNwOyZuYnNwO1RoZSBTU1JDIG1heSBhbHNvIGJlIHVzZWQgdG8g c2VwYXJhdGUgZGlmZmVyZW50IHNvdXJjZXMgb2YgbWVkaWE8YnI+DQombmJzcDsmbmJzcDt3aXRo aW4gYSBzaW5nbGUgUlRQIHNlc3Npb24uICZuYnNwO0ZvciB0aGlzIHJlYXNvbiBhcyB3ZWxsIGFz IGZvciBjb25mbGljdDxicj4NCiZuYnNwOyZuYnNwO3Jlc29sdXRpb24sIGl0IGlzIGltcG9ydGFu dCB0aGF0IHRoZSBTUkMsIFNSUywgYW5kIFJlY29yZGluZyBhd2FyZTxicj4NCiZuYnNwOyZuYnNw O1VBcyBoYW5kbGUgY2hhbmdlcyBpbiBTU1JDIHZhbHVlcyBhbmQgcHJvcGVybHkgaWRlbnRpZnkg dGhlIHJlYXNvbiBvZjxicj4NCiZuYnNwOyZuYnNwO3RoZSBjaGFuZ2UuICZuYnNwO1RoZSBDTkFN RSB2YWx1ZXMgY2FycmllZCBpbiBSVENQIGZhY2lsaXRhdGUgdGhpczxicj4NCiZuYnNwOyZuYnNw O2lkZW50aWZpY2F0aW9uLjxicj4NCjxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBpcyBhIGNvbXBl bGxpbmcgZW5vdWdoIHJlYXNvbiB0byBjYWxsIG91dCBTU1JDIGhhbmRsaW5nIGhlcmUuPGJyPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PaywgcmVhZGlu ZyBpdCBhZ2FpbiwgSSB0aGluayB0aGlzIGlmIGZpbmUuPC9kaXY+DQo8YnI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxicj4NCjxicj4NClNlY3Rpb24gOC4xLjUg c3RhdGVzLDxicj4NCjxicj4NCkVuZCBzeXN0ZW1zIHNlbmQgb25lIFNERVM8YnI+DQombmJzcDsm bmJzcDtwYWNrZXQgY29udGFpbmluZyB0aGVpciBvd24gc291cmNlIGlkZW50aWZpZXIgKHRoZSBz YW1lIGFzIHRoZSBTU1JDPGJyPg0KJm5ic3A7Jm5ic3A7aW4gdGhlIGZpeGVkIFJUUCBoZWFkZXIp LiAmbmJzcDtBIG1peGVyIHNlbmRzIG9uZSBTREVTIHBhY2tldCBjb250YWluaW5nIGE8YnI+DQom bmJzcDsmbmJzcDtjaHVuayBmb3IgZWFjaCBjb250cmlidXRpbmcgc291cmNlIGZyb20gd2hpY2gg aXQgaXMgcmVjZWl2aW5nIFNERVM8YnI+DQombmJzcDsmbmJzcDtpbmZvcm1hdGlvbiwgb3IgbXVs dGlwbGUgY29tcGxldGUgU0RFUyBwYWNrZXRzIGlmIHRoZXJlIGFyZSBtb3JlIHRoYW48YnI+DQom bmJzcDsmbmJzcDszMSBzdWNoIHNvdXJjZXMuPGJyPg0KPGJyPg0KPGJyPg0KSG93IGFib3V0IEkg YWRkLDxicj4NCjxicj4NClRoZSBhYmlsaXR5IHRvIGlkZW50aWZ5IGluZGl2aWR1YWwgY29udHJp YnV0aW5nIHNvdXJjZXMgaXMgaW1wb3J0YW50IGluPGJyPg0KdGhlIGNvbnRlbnQgb2YgU0lQUkVD LiBUaGlzIG1heSBzb21ldGltZXMgYmUgYWNoaWV2ZWQgYXQgdGhlIHNpZ25hbGluZzxicj4NCmxl dmVsIHVzaW5nIG1ldGFkYXRhLCBhcyBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLXNpcHJlYy1tZXRh ZGF0YV0uIFNERVM8YnI+DQpwcm92aWRlcyBhIG1lY2hhbmlzbSBhdCB0aGUgUlRQIGxldmVsLjxi cj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ V0ZNPC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4N Cjxicj4NClNlY3Rpb24gOC4xLjcuMiBpcyBvbmUgb2YgdGhlIG1lY2hhbmlzbSB0byByZWNvdmVy IGZyb20gcHJvYmxlbXMgd2l0aCB0aGU8YnI+DQp2aWRlbyBzdHJlYW0uIEhvdyBhYm91dCBJIGV4 dGVuZCBhcyBmb2xsb3dzOjxicj4NCjxicj4NCkFwcHJvcHJpYXRlIHVzZSBvZiBQTEkgYW5kIEZJ UiBpcyBpbXBvcnRhbnQgdG8gZW5zdXJlIHdpdGggbWluaW11bTxicj4NCm92ZXJoZWFkIHRoYXQg dGhlIHJlY29yZGVkIHZpZGVvIGlzIHVzYWJsZSAoZS5nLiB0aGUgbmVjZXNzYXJ5IHJlZmVyZW5j ZTxicj4NCmZyYW1lcyBleGlzdCBmb3IgYSBwbGF5ZXIgdG8gcmVuZGVyIHRoZSByZWNvcmRlZCB2 aWRlbykuPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5XRk08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4N CjxkaXY+QWxpc3NhPC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYg c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxicj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjxicj4N Ck5pdHM6PGJyPg0KPGJyPg0KU2VjIDUuMjo8YnI+DQo8YnI+DQpPTEQ8YnI+DQpUaGVzZSBtZXRh ZGF0YTxicj4NCiZuYnNwO3VwZGF0ZXMgYXJlIG5vcm1hbGx5IGluY3JlbWVudGFsIHVwZGF0ZXMg dG8gdGhlIGluaXRpYWwgbWV0YWRhdGE8YnI+DQombmJzcDtzbmFwc2hvdCB0byBvcHRpbWl6ZSBv biB0aGUgc2l6ZSBvZiB1cGRhdGVzLCBob3dldmVyLCB0aGUgU1JDIG1heTxicj4NCiZuYnNwO2Fs c28gZGVjaWRlIHRvIHNlbmQgYSBuZXcgbWV0YWRhdGEgc25hcHNob3QgYW55dGltZS48YnI+DQo8 YnI+DQpORVc8YnI+DQpUaGVzZSBtZXRhZGF0YTxicj4NCiZuYnNwO3VwZGF0ZXMgYXJlIG5vcm1h bGx5IGluY3JlbWVudGFsIHVwZGF0ZXMgdG8gdGhlIGluaXRpYWwgbWV0YWRhdGE8YnI+DQombmJz cDtzbmFwc2hvdCB0byBvcHRpbWl6ZSBvbiB0aGUgc2l6ZSBvZiB1cGRhdGVzLiBIb3dldmVyLCB0 aGUgU1JDIG1heTxicj4NCiZuYnNwO2Fsc28gZGVjaWRlIHRvIHNlbmQgYSBuZXcgbWV0YWRhdGEg c25hcHNob3QgYW55IHRpbWUuPGJyPg0KPGJyPg0KT0xEPGJyPg0Kc3VjaCBhcyB0aGUgYXR0cmli dXRlcyBvZiB0aGUgcmVjb3JkZWQgbWVkaWEgc3RyZWFtPGJyPg0KJm5ic3A7YXJlIGxvY2F0ZWQg aW4gdGhlIFNEUCBvZiB0aGUgcmVjb3JkaW5nIHNlc3Npb24uPGJyPg0KPGJyPg0KTkVXPGJyPg0K c3VjaCBhcyB0aGUgYXR0cmlidXRlcyBvZiB0aGUgcmVjb3JkZWQgbWVkaWEgc3RyZWFtLDxicj4N CiZuYnNwO2FyZSBsb2NhdGVkIGluIHRoZSBTRFAgb2YgdGhlIHJlY29yZGluZyBzZXNzaW9uLjxi cj4NCjxicj4NClNlYyA3LjEuMiBhbmQgNy4zLjI6PGJyPg0KPGJyPg0KVGhlIC89IGluIHRoZSBB Qk5GIHNob3VsZCBiZSA9Lzxicj4NCjxicj4NClNlYyA4LjEuMjo8YnI+DQpzL0hvd2V2ZXIsIGFz IHRoaXMgaXMgbm90IGEgcmVxdWlyZW1lbnQvSG93ZXZlciwgYXMgdGhlc2UgYXJlIG5vdDxicj4N CnJlcXVpcmVtZW50cy88YnI+DQo8YnI+DQpTZWMgOC4xLjQ6PGJyPg0Kcy93aGVuIGFjdGluZyBh IG1peGVyL3doZW4gYWN0aW5nIGFzIGEgbWl4ZXIvPGJyPg0KPGJyPg0KU2VjIDguMi4xLjEgYW5k IDguMi4xLjI6PGJyPg0KPGJyPg0KT0xEPGJyPg0KQSBSZWNvcmRpbmcgYXdhcmUgVUEgU0hPVUxE IGJlIHByZXBhcmVkIHRvPGJyPg0KJm5ic3A7cHJvY2VzcyB0aGUgUlRDUCBSZWNlaXZlciBSZXBv cnRzIGZyb20gdGhlIFNSUywgd2hlcmVhcyBhIHJlY29yZGluZzxicj4NCiZuYnNwO3VuYXdhcmUg VUEgbWF5IGRpc2NhcmQgc3VjaCBSVENQIHBhY2tldHMgYXMgbm90IG9mIHJlbGV2YW5jZS48YnI+ DQo8YnI+DQpORVc8YnI+DQpBIFVBIFNIT1VMRCBwcm9jZXNzIHRoZSBSVENQIFJlY2VpdmVyIFJl cG9ydHMgZnJvbSB0aGUgU1JTIGlmIGl0IGlzPGJyPg0KcmVjb3JkaW5nLWF3YXJlLjxicj4NCjxi cj4NClNlYyA4LjIuMjo8YnI+DQpzL2Zyb20gZGlmZmVyZW50IFVBL2Zyb20gZGlmZmVyZW50IFVB cy88YnI+DQo8YnI+DQpTZWMgOC4zOjxicj4NClRoZSB0ZXh0IGluIHRoaXMgc2VjdGlvbiBzZWVt cyBkdXBsaWNhdGl2ZSBvZiB0aGUgcGFja2V0IGxvc3MgdGV4dCBpbiB0aGU8YnI+DQpzdWJzZWN0 aW9ucyBvZiA4LjIuIEl0IHNob3VsZCBvbmx5IGFwcGVhciBpbiBvbmUgcGxhY2Ugb3IgdGhlIG90 aGVyIGJ1dDxicj4NCm5vdCBib3RoLjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCkdvb2QgY2F0 Y2guIEl0IG9yaWdpbmFsbHkgZXhpc3RlZCBpbiBzZWN0aW9uIDguMyBvbmx5LiBXZSBkZWNpZGVk IGl0IHdvdWxkPGJyPg0KYmUgYmV0dGVyIHRvIGhhbmRsZSB0aGlzIGluIHRoZSBwcmV2aW91cyBz dWJzZWN0aW9ucyBidXQgZm9yZ290IHRvIHJlbW92ZTxicj4NCnNlY3Rpb24gOC4zLjxicj4NCjxi cj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NClNlYyA4LjQuMjo8YnI+DQpzL0luIGRv aW5nIHRvL0luIGRvaW5nIHNvLzxicj4NCjxicj4NClNlYyA4LjU6PGJyPg0Kcy9hbiB2aWRlby9h IHZpZGVvLzxicj4NCjxicj4NClNlYyAxMDo8YnI+DQpzL1doZW4gdGhlcmUgaXMgbm8gY29tbXVu aWNhdGlvbiBzZXNzaW9ucy9XaGVuIHRoZXJlIGlzIG5vIGNvbW11bmljYXRpb248YnI+DQpzZXNz aW9uLzxicj4NCjxicj4NClNlYyAxMS4xLjE6PGJyPg0KPGJyPg0KT0xEPGJyPg0KV2hlbiBwcmVz ZW50IGluIGEgUmVxdWlyZSBoZWFkZXIgaW4gYSByZXF1ZXN0LCBpdCBpbmRpY2F0ZXMgdGhhdCB0 aGUgVUFTPGJyPg0KTVVTVCBiZSBlaXRoZXIgYSBTUkMgb3IgU1JTPGJyPg0KPGJyPg0KTkVXPGJy Pg0KV2hlbiBwcmVzZW50IGluIGEgUmVxdWlyZSBoZWFkZXIgaW4gYSByZXF1ZXN0LCBpdCBpbmRp Y2F0ZXMgdGhhdCB0aGUgVUFTPGJyPg0KaXMgZWl0aGVyIGFuIFNSQyBvciBTUlM8YnI+DQo8L2Js b2NrcXVvdGU+DQo8YnI+DQpUaGVzZSBhbGwgbG9vayBmaW5lIHRvIG1lLjxicj4NCjxicj4NCkNo ZWVycyw8YnI+DQpDaGFybGVzPGJyPg0KPGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpz aXByZWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcHJlY0BpZXRmLm9yZyI+ c2lwcmVjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwcmVjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcHJlYzwvYT48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D15FCC3C478C4eckelcuciscocom_-- From nobody Fri Apr 24 11:07:21 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7403D1ACE2D for ; Fri, 24 Apr 2015 11:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqx4Zjml-4U0 for ; Fri, 24 Apr 2015 11:07:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1FD1ACD6E for ; Fri, 24 Apr 2015 11:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6270; q=dns/txt; s=iport; t=1429898839; x=1431108439; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JvB17hJt56kZUqBZl7Wz4gALEzlx28Oy//B2By13vag=; b=aeUgvpk+llfzFaYu8DSVIawVlbL+QHvbsY+d5R14K4HLi/FIrqeiao5U bwbkuz+vwKcOgLQs5HrjgYfLiQ39kH1HJgLdvjzqtc3c+JIOiftqq6t8T 3hrftMm06nRcdE+DHw+93ouDtiAW0NRRj51y5rlHrIEZ8tfFRGVSG0rAV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BoBQA3hTpV/49dJa1bDoJ+UlwFgxXFCQqFNk4CHIEiTAEBAQEBAYELhCABAQEDAQEBATE6GwIBCA4KBCgCAiULJQIEARKIIwgNmkCcegaUagEBAQEBAQEBAQEBAQEBAQEBARYEgRuKHIRROoJigUsFjzKCIYo4gSKDSIlHhyQjgWWBUj1vgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,641,1422921600"; d="scan'208";a="411457321" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP; 24 Apr 2015 18:07:18 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3OI7HJV018606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 18:07:17 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.36]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 13:07:17 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 Thread-Index: AQHQeV90HF4W57aPCE6BhC5WhfOBBZ1WbqyAgAGDKYCABGzgAA== Date: Fri, 24 Apr 2015 18:07:17 +0000 Message-ID: References: <55366D8F.1070109@alum.mit.edu> In-Reply-To: <55366D8F.1070109@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.81.226] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:07:20 -0000 SGkgUGF1bCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIDQvMjEvMTUsIDg6MzIgQU0sICJQ YXVsIEt5eml2YXQiIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KDQo+Q29tbWVudHMg b24gYSBmZXcgb2YgdGhlc2U6DQo+DQo+T24gNC8yMC8xNSA3OjI2IFBNLCBDaGFybGVzIEVja2Vs IChlY2tlbGN1KSB3cm90ZToNCj4NCj4+IENoYW5nZSBzZWN0aW9uIDUuMyBhcyBmb2xsb3dzOg0K Pj4gT0xEDQo+PiBUaGUgcmVjb3JkaW5nIGF0dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5DQo+ PiAgICAgdGhlIFNSQyBpbiB0aGUgQ1MgdG8gaW5kaWNhdGUgd2hldGhlciByZWNvcmRpbmcgaXMg dGFraW5nIHBsYWNlLg0KPj4gVGhlIHJlY29yZGluZyBwcmVmZXJlbmNlIGF0dHJpYnV0ZSBpcyBh IGRlY2xhcmF0aW9uIGJ5IHRoZSByZWNvcmRpbmctDQo+PiAgICAgYXdhcmUgVUEgaW4gdGhlIENT IHRvIGluZGljYXRlIHRoZSByZWNvcmRpbmcgcHJlZmVyZW5jZS4NCj4+DQo+Pg0KPj4gTkVXDQo+ PiBUaGUgcmVjb3JkaW5nIGF0dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5DQo+PiB0aGUgU1JD IGluIHRoZSBDUyB0byBpbmRpY2F0ZSB3aGV0aGVyIHJlY29yZGluZyBpcyB0YWtpbmcgcGxhY2Uu DQo+PiBUaGUgcmVjb3JkaW5nIHByZWZlcmVuY2UgYXR0cmlidXRlIGlzIGEgZGVjbGFyYXRpb24g YnkgdGhlIHJlY29yZGluZy0NCj4+ICAgICBhd2FyZSBVQSBpbiB0aGUgQ1MgdG8gaW5kaWNhdGUg dGhlIHJlY29yZGluZyBwcmVmZXJlbmNlLg0KPg0KPnBlcmhhcHMgImluZGljYXRlICppdCdzKiBy ZWNvcmRpbmcgcHJlZmVyZW5jZSI/DQoNCkdvb2QgaWRlYS4NCg0KPg0KPj4gQSBVQSB0aGF0IGRv ZXMgbm90IHdhbnQgdG8gYmUgcmVjb3JkZWQgbWF5IHN0aWxsIGJlIG5vdGlmaWVkIHJlY29yZGlu Zw0KPj4gaXMgb2NjdXJyaW5nIGZvciBhIG51bWJlciBvZiByZWFzb25zIChlLmcuIGl0IHdhcyBu b3QgY2FwYWJsZSBvZg0KPj5pbmRpY2F0aW5nDQo+PiBpdHMgcHJlZmVyZW5jZSwgaXRzIHByZWZl cmVuY2Ugd2FzIGlnbm9yZWQsIGV0Yy4pIElmIHRoaXMgb2NjdXJzLCB0aGUNCj4+VUGp9nMNCj4+ IG9ubHkgbWVjaGFuaXNtIHRvIGF2b2lkIGJlaW5nIHJlY29yZGVkIGlzIHRvIHRlcm1pbmF0ZSBp dHMNCj4+cGFydGljaXBhdGlvbiBpbg0KPj4gdGhlIHNlc3Npb24uDQo+DQo+Pj4gU2VjdGlvbiA2 LjM6DQo+Pj4gIkEgcmVjb3JkaW5nLWF3YXJlIFVBIE1VU1QgYmUgcHJlcGFyZWQgdG8gcHJvdmlk ZSBhIHJlY29yZGluZw0KPj4+ICAgIGluZGljYXRpb24gdG8gdGhlIGVuZCB1c2VyIHRocm91Z2gg YW4gYXBwcm9wcmlhdGUgdXNlciBpbnRlcmZhY2UiDQo+Pj4NCj4+PiAiTVVTVCBiZSBwcmVwYXJl ZCB0byIgaXMgYSBzdHJhbmdlIGNvbnN0cnVjdGlvbi4gSSB0aGluayAiTVVTVCBwcm92aWRlIg0K Pj4+IGlzIHdoYXQgaXMgbWVhbnQgaGVyZS4NCj4+DQo+PiBBZ3JlZWQuDQo+DQo+SSB0aGluayB0 aGUgY29uY2VybiBoZXJlIGlzIHRoYXQgdGhpcyBtaWdodCBiZSBjb25zdHJ1ZWQgdG8gcmVxdWly ZSBhDQo+cmVhbC10aW1lIG5vdGlmaWNhdGlvbi4gQSByZWNvcmRpbmctYXdhcmUgVUEgY291bGQg YmUgY29uZmlndXJlZCBieSBpdHMNCj51c2VyIHRvIG1hbmFnZSByZWNvcmRpbmcgcG9saWN5IG9u IGJlaGFsZiBvZiB0aGUgdXNlci4gRm9yIGluc3RhbmNlLCB0aGUNCj51c2VyIG1heSBzZXQgcG9s aWN5IHRoYXQgcmVjb3JkaW5nIGlzIG9rIGF0IGFsbCB0aW1lcywgb3IgdGhhdCByZWNvcmRpbmcN Cj5pcyBvayB3aGVuIGNvbm5lY3RlZCB0byBjZXJ0YWluIHBhcnRpZXMuIEluIHN1Y2ggY2FzZXMg aXQgbWlnaHQgbm90DQo+aW5kaWNhdGUgdGhpcyBhY3RpdmVseS4NCj4NCj5BbiBleHRyZW1lIGV4 YW1wbGUgaXMgYSBzcGVjaWFsIHB1cnBvc2UgVUEgZm9yIGZpbmFuY2lhbCBzZXJ2aWNlDQo+d29y a2Vycy4gQ2FsbHMgYXJlIHR5cGljYWxseSAqcmVxdWlyZWQqIHRvIGJlIHJlY29yZGVkLiBUaGUg VUEgbWF5DQo+aXRzZWxmICpiZSogYW4gU1JDIHRoYXQgcmVjb3JkcyBhbGwgY2FsbHMsIG9yIGEg VUEgaW50ZW5kZWQgdG8gYmUgdXNlZA0KPndoZXJlIGFuIFNSQyBpcyBpbiBhbGwgY2FsbHMuIFNv IHRoZSB1c2VyIGRvZXNuJ3QgZXhwZWN0IG9yIG5lZWQgYW4NCj5leHBsaWNpdCBpbmRpY2F0aW9u Lg0KPg0KPkRvIHdlIHdhbnQgdG8gcHJlY2x1ZGUgc3VjaCBkZXZpY2VzPw0KDQpJIGRvbqGvdCB0 aGluayBzby4gSSBzZWUgQWxpc3NhIHByb3Bvc2VkIGRyb3BwaW5nIHRoZSChsHRocm91Z2ggYW4N CmFwcHJvcHJpYXRlIHVzZXIgaW50ZXJmYWNlobEsIHJlc3VsdGluZyBpbiB0aGUgZm9sbG93aW5n Og0KDQoiQSByZWNvcmRpbmctYXdhcmUgVUEgTVVTVCBwcm92aWRlIGEgcmVjb3JkaW5nIGluZGlj YXRpb24gdG8gdGhlIGVuZCB1c2VyIg0KDQpUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUg dG8gZXhwYW5kIG9uIHdoYXQgaXMgYXBwcm9wcmlhdGU6DQoNCiJBcHByb3ByaWF0ZSB1c2VyIGlu dGVyZmFjZXMgbWF5IGluY2x1ZGUgcmVhbC10aW1lIG5vdGlmaWNhdGlvbiBvcg0KcHJldmlvdXNs eSBlc3RhYmxpc2hlZCBhZ3JlZW1lbnQgdGhhdCB1c2Ugb2YgdGhlIGRldmljZSBpcyBzdWJqZWN0 DQpyZWNvcmRpbmcuobENCg0KPg0KPj4+IFNlY3Rpb24gNy4yOg0KPj4+ICJUaGUgU1JTIFNIT1VM RCBOT1QgYWRkIHJlY29yZGVkIHN0cmVhbXMgaW4gdGhlIHJlY29yZGluZyBzZXNzaW9uIHdoZW4N Cj4+PiAgICBTUlMgc2VuZHMgYSBuZXcgU0RQIG9mZmVyLiAgU2ltaWxhcmx5LCB3aGVuIHRoZSBT UlMgc3RhcnRzIGENCj4+PiAgICByZWNvcmRpbmcgc2Vzc2lvbiwgdGhlIFNSUyBTSE9VTEQgaW5p dGlhdGUgdGhlIElOVklURSB3aXRob3V0IGFuIFNEUA0KPj4+ICAgIG9mZmVyIHRvIGxldCB0aGUg U1JDIGdlbmVyYXRlIHRoZSBTRFAgb2ZmZXIgd2l0aCByZWNvcmRlZCBzdHJlYW1zLiINCj4+Pg0K Pj4+IEknbSBub3QgY2xlYXIgb24gd2h5IHRoZXNlIGFyZSBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1l bnRzLCBvciB3aGF0IHRoZQ0KPj4+IGV4Y2VwdGlvbiBjYXNlcyBhcmUgYW5kIHdoYXQgdGhlIFNS QyBpcyBleHBlY3RlZCB0byBkbyBpbiB0aG9zZQ0KPj4+ZXhjZXB0aW9uDQo+Pj4gY2FzZXMuIENv dWxkIHlvdSBleHBsYWluPw0KPj4NCj4+IE1lIG5laXRoZXIuIFdlIHVzZSB0aWdodCBsYW5ndWFn ZSBpbiBzZWN0aW9uIDkuMiBhbHJlYWR5LiBDaGFuZ2luZyBib3RoDQo+PiBmcm9tIFNIT1VMRCB0 byBNVVNUIHdvcmtzIGZvciBtZS4NCj4NCj5UaGVyZSB3YXMgY29uc2lkZXJhYmxlIGRpc2N1c3Np b24gb2YgY2FzZXMgd2hlcmUgdGhlIFNSUyB3YW50cyB0byB0YWtlDQo+dGhlIGluaXRpYXRpdmUg b2YgY29ubmVjdGluZyB0byBhbiBTUkMgZm9yIHB1cnBvc2VzIG9mIHJlY29yZGluZy4gV2UNCj51 bHRpbWF0ZWx5IHJ1bGVkIGl0IG91dCBvZiBzY29wZSwgYmVjYXVzZSB3ZSBjb3VsZG4ndCBmaWd1 cmUgb3V0IGhvdyB0aGUNCj5TUkMgY291bGQgc2lnbmFsIHdoYXQgY2FsbHMgc2hvdWxkIGJlIHJl Y29yZGVkLiBCdXQgaXQgd2FzIG15IGltcHJlc3Npb24NCj50aGF0IHRoaXMgaXMgYSB2YWxpZCB1 c2UgY2FzZSBpbiBzb21lIGVudmlyb25tZW50cywgYW5kIHNvIG1heSBiZSB0aGUNCj5zdWJqZWN0 IG9mIGZ1dHVyZSB3b3JrLCBvciBvZiBwcm9wcmlldGFyeSBleHRlbnNpb25zLg0KPg0KPkkgKmd1 ZXNzKiB0aGF0IHRoZSBTSE9VTEQtbGV2ZWwgaGVyZSB3YXMgdG8gcHJvdmlkZSBhIGxpdHRsZSB3 aWdnbGUgcm9vbQ0KPmZvciBleHRlbnNpb25zIGhlcmUuDQo+DQo+Tm90ZSB0aGF0IGlmIHRoaXMg dGhlIFNIT1VMRCB3ZXJlIHZpb2xhdGVkIHRoZSBTUkMgc3RpbGwgaGFzIHRoZSBvcHRpb24NCj5v ZiByZWplY3RpbmcgdGhlIGFkZGVkIHN0cmVhbXMuIFNpbmNlIGluIGdlbmVyYWwgaXQgd291bGRu J3Qga25vdyB3aGF0DQo+dG8gZG8gd2l0aCB0aGVtIHRoYXQgaXMgcHJvYmFibHkgd2hhdCBpdCB3 b3VsZCBkby4gU28gSU1PIFNIT1VMRCBpcyBvaw0KPmhlcmUuDQoNClRoZSBleGlzdGluZyBkcmFm dCBhbGxvd3MgdGhlIFNSUyB0byBpbml0aWF0ZSB0aGUgcmVjb3JkaW5nLCBidXQgcmVzdHJpY3Rz DQppdCB0byBkb2luZyBzbyB2aWEgYW4gb2ZmZXJsZXNzIGludml0ZS4gSXQgc2VlbXMgdG8gbWUg dGhhdCB0aWdodGVuaW5nDQp0aGlzIGZyb20gYSBTSE9VTEQgdG8gYSBNVVNUIGlzIGFwcHJvcHJp YXRlLiBGdXR1cmUgZXh0ZW5zaW9ucyB0byBnaXZlIHRoZQ0KU1JTIG1vcmUgY29udHJvbCBvdmVy IHRoZSByZWNvcmRpbmcgY291bGQgYWxzbyB1cGRhdGUgdGhlIFJGQyB0byBkZWZpbmUNCnRoZSBu ZXcgZXhjZXB0aW9ucyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgcHJvcHJpZXRhcnkgZXh0ZW5zaW9u cy4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KIA0KPg0KPglUaGFua3MsDQo+CVBhdWwNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNpcHJlYyBtYWls aW5nIGxpc3QNCj5zaXByZWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcHJlYw0KDQo= From nobody Fri Apr 24 11:49:42 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01A31B3158 for ; Fri, 24 Apr 2015 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8ZEErz1u60y for ; Fri, 24 Apr 2015 11:49:38 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6AB1B312E for ; Fri, 24 Apr 2015 11:49:37 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-11v.sys.comcast.net with comcast id Kupc1q0062Bo0NV01upd7E; Fri, 24 Apr 2015 18:49:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id Kupc1q01S3Ge9ey01upcZQ; Fri, 24 Apr 2015 18:49:37 +0000 Message-ID: <553A9040.3010402@alum.mit.edu> Date: Fri, 24 Apr 2015 14:49:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" References: <55366D8F.1070109@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429901377; bh=cnELXLQM35HvOQ6hdxs2ORExrtPlKEeaxqterj5y9I4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kgmJIYZDGB9EgSkcyCHdrVRviiDA22n+1X7FJgno60wBG0/LkBYmq4Y5sMN4iIPWu 54oY4ivupatZlFXBvLKuhKyki+W+IxfAo50gvX67bth68/u9TjXSgUh4TieIJQHwgF 4dVTnwnyfO6JcqJBXsQfqLn/QcYkwdMQVk5hiBTDGvkOOUNLijE5F61mMevF1SYbBI fpQrh7z/86s/EBG2QnkMqDcQvs+Zu3KIjbkTkUCKZ1G77RvDu3qfxt7CUbZZdV1X/x BD9vhd2ZV+VvsEEhOfmXVZUl/88XfE0cYjzRlT9Wm/DHIpZrHSa28adJ8IY4C+54ba ieagZx23huHTA== Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:49:41 -0000 WFM On 4/24/15 2:07 PM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > Please see inline. > > On 4/21/15, 8:32 AM, "Paul Kyzivat" wrote: > >> Comments on a few of these: >> >> On 4/20/15 7:26 PM, Charles Eckel (eckelcu) wrote: >> >>> Change section 5.3 as follows: >>> OLD >>> The recording attribute is a declaration by >>> the SRC in the CS to indicate whether recording is taking place. >>> The recording preference attribute is a declaration by the recording- >>> aware UA in the CS to indicate the recording preference. >>> >>> >>> NEW >>> The recording attribute is a declaration by >>> the SRC in the CS to indicate whether recording is taking place. >>> The recording preference attribute is a declaration by the recording- >>> aware UA in the CS to indicate the recording preference. >> >> perhaps "indicate *it's* recording preference"? > > Good idea. > >> >>> A UA that does not want to be recorded may still be notified recording >>> is occurring for a number of reasons (e.g. it was not capable of >>> indicating >>> its preference, its preference was ignored, etc.) If this occurs, the >>> UA©ös >>> only mechanism to avoid being recorded is to terminate its >>> participation in >>> the session. >> >>>> Section 6.3: >>>> "A recording-aware UA MUST be prepared to provide a recording >>>> indication to the end user through an appropriate user interface" >>>> >>>> "MUST be prepared to" is a strange construction. I think "MUST provide" >>>> is what is meant here. >>> >>> Agreed. >> >> I think the concern here is that this might be construed to require a >> real-time notification. A recording-aware UA could be configured by its >> user to manage recording policy on behalf of the user. For instance, the >> user may set policy that recording is ok at all times, or that recording >> is ok when connected to certain parties. In such cases it might not >> indicate this actively. >> >> An extreme example is a special purpose UA for financial service >> workers. Calls are typically *required* to be recorded. The UA may >> itself *be* an SRC that records all calls, or a UA intended to be used >> where an SRC is in all calls. So the user doesn't expect or need an >> explicit indication. >> >> Do we want to preclude such devices? > > I don¡¯t think so. I see Alissa proposed dropping the ¡°through an > appropriate user interface¡±, resulting in the following: > > "A recording-aware UA MUST provide a recording indication to the end user" > > The other alternative would be to expand on what is appropriate: > > "Appropriate user interfaces may include real-time notification or > previously established agreement that use of the device is subject > recording.¡± > >> >>>> Section 7.2: >>>> "The SRS SHOULD NOT add recorded streams in the recording session when >>>> SRS sends a new SDP offer. Similarly, when the SRS starts a >>>> recording session, the SRS SHOULD initiate the INVITE without an SDP >>>> offer to let the SRC generate the SDP offer with recorded streams." >>>> >>>> I'm not clear on why these are SHOULD-level requirements, or what the >>>> exception cases are and what the SRC is expected to do in those >>>> exception >>>> cases. Could you explain? >>> >>> Me neither. We use tight language in section 9.2 already. Changing both >>> from SHOULD to MUST works for me. >> >> There was considerable discussion of cases where the SRS wants to take >> the initiative of connecting to an SRC for purposes of recording. We >> ultimately ruled it out of scope, because we couldn't figure out how the >> SRC could signal what calls should be recorded. But it was my impression >> that this is a valid use case in some environments, and so may be the >> subject of future work, or of proprietary extensions. >> >> I *guess* that the SHOULD-level here was to provide a little wiggle room >> for extensions here. >> >> Note that if this the SHOULD were violated the SRC still has the option >> of rejecting the added streams. Since in general it wouldn't know what >> to do with them that is probably what it would do. So IMO SHOULD is ok >> here. > > The existing draft allows the SRS to initiate the recording, but restricts > it to doing so via an offerless invite. It seems to me that tightening > this from a SHOULD to a MUST is appropriate. Future extensions to give the > SRS more control over the recording could also update the RFC to define > the new exceptions and the corresponding proprietary extensions. > > Cheers, > Charles > >> >> Thanks, >> Paul >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From nobody Wed Apr 29 06:12:39 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0741B2CB3 for ; Wed, 29 Apr 2015 06:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDqfdc3wwsuy for ; Wed, 29 Apr 2015 06:12:32 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 717151B2CAE for ; Wed, 29 Apr 2015 06:12:32 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 686A923F0467; Wed, 29 Apr 2015 15:12:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.54]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Wed, 29 Apr 2015 15:12:30 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "Charles Eckel (eckelcu)" , "siprec@ietf.org" , Alissa Cooper Thread-Topic: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 Thread-Index: AQHQeV90HF4W57aPCE6BhC5WhfOBBZ1WbqyAgAGDKYCABGzgAIAAC9cAgAedgMA= Date: Wed, 29 Apr 2015 13:12:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E75304E@MCHP04MSX.global-ad.net> References: <55366D8F.1070109@alum.mit.edu> <553A9040.3010402@alum.mit.edu> In-Reply-To: <553A9040.3010402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 13:12:35 -0000 Hi All, I have been through Alissa's comments and the proposed changes and my take = on it is that all the proposed changes are just clarifications of what was = intended by the working group and none of the suggested updates the protoco= l. Charles, Are you willing to do an update with the changes proposed? Regards Andy=20 > -----Original Message----- > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 April 2015 19:50 > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 >=20 > WFM >=20 > On 4/24/15 2:07 PM, Charles Eckel (eckelcu) wrote: > > Hi Paul, > > > > Please see inline. > > > > On 4/21/15, 8:32 AM, "Paul Kyzivat" wrote: > > > >> Comments on a few of these: > >> > >> On 4/20/15 7:26 PM, Charles Eckel (eckelcu) wrote: > >> > >>> Change section 5.3 as follows: > >>> OLD > >>> The recording attribute is a declaration by > >>> the SRC in the CS to indicate whether recording is taking > place. > >>> The recording preference attribute is a declaration by the > recording- > >>> aware UA in the CS to indicate the recording preference. > >>> > >>> > >>> NEW > >>> The recording attribute is a declaration by > >>> the SRC in the CS to indicate whether recording is taking place. > >>> The recording preference attribute is a declaration by the > recording- > >>> aware UA in the CS to indicate the recording preference. > >> > >> perhaps "indicate *it's* recording preference"? > > > > Good idea. > > > >> > >>> A UA that does not want to be recorded may still be notified > recording > >>> is occurring for a number of reasons (e.g. it was not capable of > >>> indicating > >>> its preference, its preference was ignored, etc.) If this occurs, > the > >>> UA=B9s > >>> only mechanism to avoid being recorded is to terminate its > >>> participation in > >>> the session. > >> > >>>> Section 6.3: > >>>> "A recording-aware UA MUST be prepared to provide a recording > >>>> indication to the end user through an appropriate user > interface" > >>>> > >>>> "MUST be prepared to" is a strange construction. I think "MUST > provide" > >>>> is what is meant here. > >>> > >>> Agreed. > >> > >> I think the concern here is that this might be construed to require > a > >> real-time notification. A recording-aware UA could be configured by > its > >> user to manage recording policy on behalf of the user. For instance, > the > >> user may set policy that recording is ok at all times, or that > recording > >> is ok when connected to certain parties. In such cases it might not > >> indicate this actively. > >> > >> An extreme example is a special purpose UA for financial service > >> workers. Calls are typically *required* to be recorded. The UA may > >> itself *be* an SRC that records all calls, or a UA intended to be > used > >> where an SRC is in all calls. So the user doesn't expect or need an > >> explicit indication. > >> > >> Do we want to preclude such devices? > > > > I don't think so. I see Alissa proposed dropping the "through an > > appropriate user interface", resulting in the following: > > > > "A recording-aware UA MUST provide a recording indication to the end > user" > > > > The other alternative would be to expand on what is appropriate: > > > > "Appropriate user interfaces may include real-time notification or > > previously established agreement that use of the device is subject > > recording." > > > >> > >>>> Section 7.2: > >>>> "The SRS SHOULD NOT add recorded streams in the recording session > when > >>>> SRS sends a new SDP offer. Similarly, when the SRS starts a > >>>> recording session, the SRS SHOULD initiate the INVITE without > an SDP > >>>> offer to let the SRC generate the SDP offer with recorded > streams." > >>>> > >>>> I'm not clear on why these are SHOULD-level requirements, or what > the > >>>> exception cases are and what the SRC is expected to do in those > >>>> exception > >>>> cases. Could you explain? > >>> > >>> Me neither. We use tight language in section 9.2 already. Changing > both > >>> from SHOULD to MUST works for me. > >> > >> There was considerable discussion of cases where the SRS wants to > take > >> the initiative of connecting to an SRC for purposes of recording. We > >> ultimately ruled it out of scope, because we couldn't figure out how > the > >> SRC could signal what calls should be recorded. But it was my > impression > >> that this is a valid use case in some environments, and so may be > the > >> subject of future work, or of proprietary extensions. > >> > >> I *guess* that the SHOULD-level here was to provide a little wiggle > room > >> for extensions here. > >> > >> Note that if this the SHOULD were violated the SRC still has the > option > >> of rejecting the added streams. Since in general it wouldn't know > what > >> to do with them that is probably what it would do. So IMO SHOULD is > ok > >> here. > > > > The existing draft allows the SRS to initiate the recording, but > restricts > > it to doing so via an offerless invite. It seems to me that > tightening > > this from a SHOULD to a MUST is appropriate. Future extensions to > give the > > SRS more control over the recording could also update the RFC to > define > > the new exceptions and the corresponding proprietary extensions. > > > > Cheers, > > Charles > > > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From nobody Wed Apr 29 08:21:05 2015 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115E41A1BEA for ; Wed, 29 Apr 2015 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uf0-q1lT3_i for ; Wed, 29 Apr 2015 08:21:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA37C1A1BD1 for ; Wed, 29 Apr 2015 08:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8692; q=dns/txt; s=iport; t=1430320860; x=1431530460; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=j+n7c+YIEkZYROs1Q/ApGYAxfHWpkQZXWuZGPjBjGVM=; b=UC8mNEp6/PrRpdNOTHl7uHPfI5zOWSh3S1kzi+W042kLf8A22Lo8+eia O9m6mBRMQ0cpP9HoytZxn1jSnhdbt1iKXHP7hzpSKFY8voWH5SqTZ5WDm H4OiHFQqCUf++OoZn+OPxsuPQVWvNPNo3OqAh+KzeVue6RbWtEghMVOL0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXBAB19kBV/5tdJa1cDoJ+U1wFgxXCZgmBSQqFNk4CHIEkOBQBAQEBAQEBgQqEIAEBAQQBAQExOhcEAgEIEQQBAQEEIwUCAiULFAkIAgQBEogrDZYrnHwGlAABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEbih2EUjoGglyBSwWRaopIgSODSYlghywjgWWBUj1vgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,671,1422921600"; d="scan'208";a="145630325" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 29 Apr 2015 15:20:59 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3TFKwZ0010794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 15:20:58 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.36]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 10:20:58 -0500 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , Paul Kyzivat , "siprec@ietf.org" , Alissa Cooper Thread-Topic: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 Thread-Index: AQHQeV90HF4W57aPCE6BhC5WhfOBBZ1WbqyAgAGDKYCABGzgAIAAgS8AgAd9eQD//66LgA== Date: Wed, 29 Apr 2015 15:20:58 +0000 Message-ID: References: <55366D8F.1070109@alum.mit.edu> <553A9040.3010402@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E75304E@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E75304E@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.81.226] Content-Type: text/plain; charset="euc-kr" Content-ID: <09678A03B74CB646B8EC71F806CC1A1C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-protocol-15 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 15:21:04 -0000 WWVzLCBJIGNhbiBtYWtlIHRoZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMuIEkgd2FzIHdhaXRpbmcg YSBiaXQgdG8gc2VlIGlmDQp0aGVyZSB3ZXJlIGFueSBhZGRpdGlvbmFsIGNvbW1lbnRzLiBJIHdp bGwgdGFyZ2V0IGdldHRpbmcgYW4gdXBkYXRlIG91dA0KYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHdl ZWsuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KT24gNC8yOS8xNSwgNjoxMiBBTSwgIkh1dHRvbiwg QW5kcmV3IiA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20+IHdyb3RlOg0KDQo+SGkgQWxsLA0KPg0K PkkgaGF2ZSBiZWVuIHRocm91Z2ggQWxpc3NhJ3MgY29tbWVudHMgYW5kIHRoZSBwcm9wb3NlZCBj aGFuZ2VzIGFuZCBteQ0KPnRha2Ugb24gaXQgaXMgdGhhdCBhbGwgdGhlIHByb3Bvc2VkIGNoYW5n ZXMgYXJlIGp1c3QgY2xhcmlmaWNhdGlvbnMgb2YNCj53aGF0IHdhcyBpbnRlbmRlZCBieSB0aGUg d29ya2luZyBncm91cCBhbmQgbm9uZSBvZiB0aGUgc3VnZ2VzdGVkIHVwZGF0ZXMNCj50aGUgcHJv dG9jb2wuDQo+DQo+Q2hhcmxlcywgQXJlIHlvdSB3aWxsaW5nIHRvIGRvIGFuIHVwZGF0ZSB3aXRo IHRoZSBjaGFuZ2VzIHByb3Bvc2VkPw0KPg0KPlJlZ2FyZHMNCj5BbmR5IA0KPg0KPg0KPg0KPg0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHNpcHJlYyBbbWFpbHRvOnNp cHJlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBLeXppdmF0DQo+PiBTZW50 OiAyNCBBcHJpbCAyMDE1IDE5OjUwDQo+PiBUbzogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSk7IHNp cHJlY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzaXByZWNdIEFEIGV2YWx1YXRpb246IGRy YWZ0LWlldGYtc2lwcmVjLXByb3RvY29sLTE1DQo+PiANCj4+IFdGTQ0KPj4gDQo+PiBPbiA0LzI0 LzE1IDI6MDcgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIHdyb3RlOg0KPj4gPiBIaSBQYXVs LA0KPj4gPg0KPj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4+ID4NCj4+ID4gT24gNC8yMS8xNSwg ODozMiBBTSwgIlBhdWwgS3l6aXZhdCIgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+ PiA+DQo+PiA+PiBDb21tZW50cyBvbiBhIGZldyBvZiB0aGVzZToNCj4+ID4+DQo+PiA+PiBPbiA0 LzIwLzE1IDc6MjYgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIHdyb3RlOg0KPj4gPj4NCj4+ ID4+PiBDaGFuZ2Ugc2VjdGlvbiA1LjMgYXMgZm9sbG93czoNCj4+ID4+PiBPTEQNCj4+ID4+PiBU aGUgcmVjb3JkaW5nIGF0dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5DQo+PiA+Pj4gICAgICB0 aGUgU1JDIGluIHRoZSBDUyB0byBpbmRpY2F0ZSB3aGV0aGVyIHJlY29yZGluZyBpcyB0YWtpbmcN Cj4+IHBsYWNlLg0KPj4gPj4+IFRoZSByZWNvcmRpbmcgcHJlZmVyZW5jZSBhdHRyaWJ1dGUgaXMg YSBkZWNsYXJhdGlvbiBieSB0aGUNCj4+IHJlY29yZGluZy0NCj4+ID4+PiAgICAgIGF3YXJlIFVB IGluIHRoZSBDUyB0byBpbmRpY2F0ZSB0aGUgcmVjb3JkaW5nIHByZWZlcmVuY2UuDQo+PiA+Pj4N Cj4+ID4+Pg0KPj4gPj4+IE5FVw0KPj4gPj4+IFRoZSByZWNvcmRpbmcgYXR0cmlidXRlIGlzIGEg ZGVjbGFyYXRpb24gYnkNCj4+ID4+PiB0aGUgU1JDIGluIHRoZSBDUyB0byBpbmRpY2F0ZSB3aGV0 aGVyIHJlY29yZGluZyBpcyB0YWtpbmcgcGxhY2UuDQo+PiA+Pj4gVGhlIHJlY29yZGluZyBwcmVm ZXJlbmNlIGF0dHJpYnV0ZSBpcyBhIGRlY2xhcmF0aW9uIGJ5IHRoZQ0KPj4gcmVjb3JkaW5nLQ0K Pj4gPj4+ICAgICAgYXdhcmUgVUEgaW4gdGhlIENTIHRvIGluZGljYXRlIHRoZSByZWNvcmRpbmcg cHJlZmVyZW5jZS4NCj4+ID4+DQo+PiA+PiBwZXJoYXBzICJpbmRpY2F0ZSAqaXQncyogcmVjb3Jk aW5nIHByZWZlcmVuY2UiPw0KPj4gPg0KPj4gPiBHb29kIGlkZWEuDQo+PiA+DQo+PiA+Pg0KPj4g Pj4+IEEgVUEgdGhhdCBkb2VzIG5vdCB3YW50IHRvIGJlIHJlY29yZGVkIG1heSBzdGlsbCBiZSBu b3RpZmllZA0KPj4gcmVjb3JkaW5nDQo+PiA+Pj4gaXMgb2NjdXJyaW5nIGZvciBhIG51bWJlciBv ZiByZWFzb25zIChlLmcuIGl0IHdhcyBub3QgY2FwYWJsZSBvZg0KPj4gPj4+IGluZGljYXRpbmcN Cj4+ID4+PiBpdHMgcHJlZmVyZW5jZSwgaXRzIHByZWZlcmVuY2Ugd2FzIGlnbm9yZWQsIGV0Yy4p IElmIHRoaXMgb2NjdXJzLA0KPj4gdGhlDQo+PiA+Pj4gVUGp9nMNCj4+ID4+PiBvbmx5IG1lY2hh bmlzbSB0byBhdm9pZCBiZWluZyByZWNvcmRlZCBpcyB0byB0ZXJtaW5hdGUgaXRzDQo+PiA+Pj4g cGFydGljaXBhdGlvbiBpbg0KPj4gPj4+IHRoZSBzZXNzaW9uLg0KPj4gPj4NCj4+ID4+Pj4gU2Vj dGlvbiA2LjM6DQo+PiA+Pj4+ICJBIHJlY29yZGluZy1hd2FyZSBVQSBNVVNUIGJlIHByZXBhcmVk IHRvIHByb3ZpZGUgYSByZWNvcmRpbmcNCj4+ID4+Pj4gICAgIGluZGljYXRpb24gdG8gdGhlIGVu ZCB1c2VyIHRocm91Z2ggYW4gYXBwcm9wcmlhdGUgdXNlcg0KPj4gaW50ZXJmYWNlIg0KPj4gPj4+ Pg0KPj4gPj4+PiAiTVVTVCBiZSBwcmVwYXJlZCB0byIgaXMgYSBzdHJhbmdlIGNvbnN0cnVjdGlv bi4gSSB0aGluayAiTVVTVA0KPj4gcHJvdmlkZSINCj4+ID4+Pj4gaXMgd2hhdCBpcyBtZWFudCBo ZXJlLg0KPj4gPj4+DQo+PiA+Pj4gQWdyZWVkLg0KPj4gPj4NCj4+ID4+IEkgdGhpbmsgdGhlIGNv bmNlcm4gaGVyZSBpcyB0aGF0IHRoaXMgbWlnaHQgYmUgY29uc3RydWVkIHRvIHJlcXVpcmUNCj4+ IGENCj4+ID4+IHJlYWwtdGltZSBub3RpZmljYXRpb24uIEEgcmVjb3JkaW5nLWF3YXJlIFVBIGNv dWxkIGJlIGNvbmZpZ3VyZWQgYnkNCj4+IGl0cw0KPj4gPj4gdXNlciB0byBtYW5hZ2UgcmVjb3Jk aW5nIHBvbGljeSBvbiBiZWhhbGYgb2YgdGhlIHVzZXIuIEZvciBpbnN0YW5jZSwNCj4+IHRoZQ0K Pj4gPj4gdXNlciBtYXkgc2V0IHBvbGljeSB0aGF0IHJlY29yZGluZyBpcyBvayBhdCBhbGwgdGlt ZXMsIG9yIHRoYXQNCj4+IHJlY29yZGluZw0KPj4gPj4gaXMgb2sgd2hlbiBjb25uZWN0ZWQgdG8g Y2VydGFpbiBwYXJ0aWVzLiBJbiBzdWNoIGNhc2VzIGl0IG1pZ2h0IG5vdA0KPj4gPj4gaW5kaWNh dGUgdGhpcyBhY3RpdmVseS4NCj4+ID4+DQo+PiA+PiBBbiBleHRyZW1lIGV4YW1wbGUgaXMgYSBz cGVjaWFsIHB1cnBvc2UgVUEgZm9yIGZpbmFuY2lhbCBzZXJ2aWNlDQo+PiA+PiB3b3JrZXJzLiBD YWxscyBhcmUgdHlwaWNhbGx5ICpyZXF1aXJlZCogdG8gYmUgcmVjb3JkZWQuIFRoZSBVQSBtYXkN Cj4+ID4+IGl0c2VsZiAqYmUqIGFuIFNSQyB0aGF0IHJlY29yZHMgYWxsIGNhbGxzLCBvciBhIFVB IGludGVuZGVkIHRvIGJlDQo+PiB1c2VkDQo+PiA+PiB3aGVyZSBhbiBTUkMgaXMgaW4gYWxsIGNh bGxzLiBTbyB0aGUgdXNlciBkb2Vzbid0IGV4cGVjdCBvciBuZWVkIGFuDQo+PiA+PiBleHBsaWNp dCBpbmRpY2F0aW9uLg0KPj4gPj4NCj4+ID4+IERvIHdlIHdhbnQgdG8gcHJlY2x1ZGUgc3VjaCBk ZXZpY2VzPw0KPj4gPg0KPj4gPiBJIGRvbid0IHRoaW5rIHNvLiBJIHNlZSBBbGlzc2EgcHJvcG9z ZWQgZHJvcHBpbmcgdGhlICJ0aHJvdWdoIGFuDQo+PiA+IGFwcHJvcHJpYXRlIHVzZXIgaW50ZXJm YWNlIiwgcmVzdWx0aW5nIGluIHRoZSBmb2xsb3dpbmc6DQo+PiA+DQo+PiA+ICJBIHJlY29yZGlu Zy1hd2FyZSBVQSBNVVNUIHByb3ZpZGUgYSByZWNvcmRpbmcgaW5kaWNhdGlvbiB0byB0aGUgZW5k DQo+PiB1c2VyIg0KPj4gPg0KPj4gPiBUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8g ZXhwYW5kIG9uIHdoYXQgaXMgYXBwcm9wcmlhdGU6DQo+PiA+DQo+PiA+ICJBcHByb3ByaWF0ZSB1 c2VyIGludGVyZmFjZXMgbWF5IGluY2x1ZGUgcmVhbC10aW1lIG5vdGlmaWNhdGlvbiBvcg0KPj4g PiBwcmV2aW91c2x5IGVzdGFibGlzaGVkIGFncmVlbWVudCB0aGF0IHVzZSBvZiB0aGUgZGV2aWNl IGlzIHN1YmplY3QNCj4+ID4gcmVjb3JkaW5nLiINCj4+ID4NCj4+ID4+DQo+PiA+Pj4+IFNlY3Rp b24gNy4yOg0KPj4gPj4+PiAiVGhlIFNSUyBTSE9VTEQgTk9UIGFkZCByZWNvcmRlZCBzdHJlYW1z IGluIHRoZSByZWNvcmRpbmcgc2Vzc2lvbg0KPj4gd2hlbg0KPj4gPj4+PiAgICAgU1JTIHNlbmRz IGEgbmV3IFNEUCBvZmZlci4gIFNpbWlsYXJseSwgd2hlbiB0aGUgU1JTIHN0YXJ0cyBhDQo+PiA+ Pj4+ICAgICByZWNvcmRpbmcgc2Vzc2lvbiwgdGhlIFNSUyBTSE9VTEQgaW5pdGlhdGUgdGhlIElO VklURSB3aXRob3V0DQo+PiBhbiBTRFANCj4+ID4+Pj4gICAgIG9mZmVyIHRvIGxldCB0aGUgU1JD IGdlbmVyYXRlIHRoZSBTRFAgb2ZmZXIgd2l0aCByZWNvcmRlZA0KPj4gc3RyZWFtcy4iDQo+PiA+ Pj4+DQo+PiA+Pj4+IEknbSBub3QgY2xlYXIgb24gd2h5IHRoZXNlIGFyZSBTSE9VTEQtbGV2ZWwg cmVxdWlyZW1lbnRzLCBvciB3aGF0DQo+PiB0aGUNCj4+ID4+Pj4gZXhjZXB0aW9uIGNhc2VzIGFy ZSBhbmQgd2hhdCB0aGUgU1JDIGlzIGV4cGVjdGVkIHRvIGRvIGluIHRob3NlDQo+PiA+Pj4+IGV4 Y2VwdGlvbg0KPj4gPj4+PiBjYXNlcy4gQ291bGQgeW91IGV4cGxhaW4/DQo+PiA+Pj4NCj4+ID4+ PiBNZSBuZWl0aGVyLiBXZSB1c2UgdGlnaHQgbGFuZ3VhZ2UgaW4gc2VjdGlvbiA5LjIgYWxyZWFk eS4gQ2hhbmdpbmcNCj4+IGJvdGgNCj4+ID4+PiBmcm9tIFNIT1VMRCB0byBNVVNUIHdvcmtzIGZv ciBtZS4NCj4+ID4+DQo+PiA+PiBUaGVyZSB3YXMgY29uc2lkZXJhYmxlIGRpc2N1c3Npb24gb2Yg Y2FzZXMgd2hlcmUgdGhlIFNSUyB3YW50cyB0bw0KPj4gdGFrZQ0KPj4gPj4gdGhlIGluaXRpYXRp dmUgb2YgY29ubmVjdGluZyB0byBhbiBTUkMgZm9yIHB1cnBvc2VzIG9mIHJlY29yZGluZy4gV2UN Cj4+ID4+IHVsdGltYXRlbHkgcnVsZWQgaXQgb3V0IG9mIHNjb3BlLCBiZWNhdXNlIHdlIGNvdWxk bid0IGZpZ3VyZSBvdXQgaG93DQo+PiB0aGUNCj4+ID4+IFNSQyBjb3VsZCBzaWduYWwgd2hhdCBj YWxscyBzaG91bGQgYmUgcmVjb3JkZWQuIEJ1dCBpdCB3YXMgbXkNCj4+IGltcHJlc3Npb24NCj4+ ID4+IHRoYXQgdGhpcyBpcyBhIHZhbGlkIHVzZSBjYXNlIGluIHNvbWUgZW52aXJvbm1lbnRzLCBh bmQgc28gbWF5IGJlDQo+PiB0aGUNCj4+ID4+IHN1YmplY3Qgb2YgZnV0dXJlIHdvcmssIG9yIG9m IHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMuDQo+PiA+Pg0KPj4gPj4gSSAqZ3Vlc3MqIHRoYXQgdGhl IFNIT1VMRC1sZXZlbCBoZXJlIHdhcyB0byBwcm92aWRlIGEgbGl0dGxlIHdpZ2dsZQ0KPj4gcm9v bQ0KPj4gPj4gZm9yIGV4dGVuc2lvbnMgaGVyZS4NCj4+ID4+DQo+PiA+PiBOb3RlIHRoYXQgaWYg dGhpcyB0aGUgU0hPVUxEIHdlcmUgdmlvbGF0ZWQgdGhlIFNSQyBzdGlsbCBoYXMgdGhlDQo+PiBv cHRpb24NCj4+ID4+IG9mIHJlamVjdGluZyB0aGUgYWRkZWQgc3RyZWFtcy4gU2luY2UgaW4gZ2Vu ZXJhbCBpdCB3b3VsZG4ndCBrbm93DQo+PiB3aGF0DQo+PiA+PiB0byBkbyB3aXRoIHRoZW0gdGhh dCBpcyBwcm9iYWJseSB3aGF0IGl0IHdvdWxkIGRvLiBTbyBJTU8gU0hPVUxEIGlzDQo+PiBvaw0K Pj4gPj4gaGVyZS4NCj4+ID4NCj4+ID4gVGhlIGV4aXN0aW5nIGRyYWZ0IGFsbG93cyB0aGUgU1JT IHRvIGluaXRpYXRlIHRoZSByZWNvcmRpbmcsIGJ1dA0KPj4gcmVzdHJpY3RzDQo+PiA+IGl0IHRv IGRvaW5nIHNvIHZpYSBhbiBvZmZlcmxlc3MgaW52aXRlLiBJdCBzZWVtcyB0byBtZSB0aGF0DQo+ PiB0aWdodGVuaW5nDQo+PiA+IHRoaXMgZnJvbSBhIFNIT1VMRCB0byBhIE1VU1QgaXMgYXBwcm9w cmlhdGUuIEZ1dHVyZSBleHRlbnNpb25zIHRvDQo+PiBnaXZlIHRoZQ0KPj4gPiBTUlMgbW9yZSBj b250cm9sIG92ZXIgdGhlIHJlY29yZGluZyBjb3VsZCBhbHNvIHVwZGF0ZSB0aGUgUkZDIHRvDQo+ PiBkZWZpbmUNCj4+ID4gdGhlIG5ldyBleGNlcHRpb25zIGFuZCB0aGUgY29ycmVzcG9uZGluZyBw cm9wcmlldGFyeSBleHRlbnNpb25zLg0KPj4gPg0KPj4gPiBDaGVlcnMsDQo+PiA+IENoYXJsZXMN Cj4+ID4NCj4+ID4+DQo+PiA+PiAJVGhhbmtzLA0KPj4gPj4gCVBhdWwNCj4+ID4+DQo+PiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2lw cmVjIG1haWxpbmcgbGlzdA0KPj4gPj4gc2lwcmVjQGlldGYub3JnDQo+PiA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0KPj4gPg0KPj4gDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2lwcmVjIG1haWxp bmcgbGlzdA0KPj4gc2lwcmVjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcHJlYw0KDQo=