From isms-bounces@ietf.org Tue Aug 5 02:33:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEB13A6CC7; Tue, 5 Aug 2008 02:33:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C79928C1D3 for ; Tue, 5 Aug 2008 02:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Daj3y7Sta7Qc for ; Tue, 5 Aug 2008 02:33:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 3FC6A3A6CC0 for ; Tue, 5 Aug 2008 02:33:41 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m759XrpZ016415; Tue, 5 Aug 2008 12:33:56 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 12:33:52 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 12:33:38 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 12:33:48 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201474C12@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Proposed SSH Transport Address Changes (and a quick nit) Thread-Index: Acjlt71YPeoOCArQQ+qdbyeIKtQrfQRJAchA References: <20080714101933.GA8289@elstar.local><065301c8e5a8$47f98360$0600a8c0@china.huawei.com> From: To: X-OriginalArrivalTime: 05 Aug 2008 09:33:38.0443 (UTC) FILETIME=[57181DB0:01C8F6DE] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker wrote: > > DH> I am of the impression this would require yet another > DH> mapping table to support a feature that is not needed by > DH> everybody. > > Actually, I think it drops the need for one. This reply comes a bit late... but I think I agree with Wes here: allowing "user@host" as SSH transport address could drop the need for one mapping table on notification originators (it's not that important for command generators). An administrator configuring TARGET-MIB will of course include the securityName used for VACM, but that's *our* name for the *recipient* (e.g. "joe", an administrator). To actually open the SSH connection, SSH will need to send *their* name for *us* (e.g. "router134"). Configuring an extra table mapping "joe,192.0.2.1" to "router134" will of course work, but allowing "router134@192.0.2.1" as transport address could be simpler to deploy. (SSH will still need a mapping from "192.0.2.1" to the host public key, and from "router134@192.0.2.1" to the password/private key, but IMHO those really belong in SSH module, not on SNMP side.) Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Aug 6 07:17:23 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDA03A6CB9; Wed, 6 Aug 2008 07:17:23 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA1B3A6CB9 for ; Wed, 6 Aug 2008 07:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB9mV8LKCBDz for ; Wed, 6 Aug 2008 07:17:22 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 5BA093A680B for ; Wed, 6 Aug 2008 07:17:22 -0700 (PDT) Received: from [172.16.209.80] (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m76EHofr001907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 10:17:51 -0400 (EDT) Date: Wed, 06 Aug 2008 10:17:50 -0400 From: Jeffrey Hutzelman To: Pasi.Eronen@nokia.com, wjhns1@hardakers.net Message-ID: In-Reply-To: <200808050935.m759YG7j011012@raisinbran.srv.cs.cmu.edu> References: <20080714101933.GA8289@elstar.local> <065301c8e5a8$47f98360$0600a8c0@china.huawei.com> <200808050935.m759YG7j011012@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, August 05, 2008 12:33:48 PM +0300 Pasi.Eronen@nokia.com wrote: > Wes Hardaker wrote: >> >> DH> I am of the impression this would require yet another >> DH> mapping table to support a feature that is not needed by >> DH> everybody. >> >> Actually, I think it drops the need for one. > > This reply comes a bit late... but I think I agree with Wes here: > allowing "user@host" as SSH transport address could drop the need > for one mapping table on notification originators (it's not that > important for command generators). +1 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Aug 9 12:03:50 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2B328C0F0; Sat, 9 Aug 2008 12:03:50 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA89C28C142 for ; Sat, 9 Aug 2008 12:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23-usbcyrAyv for ; Sat, 9 Aug 2008 12:03:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1108C28C0F0 for ; Sat, 9 Aug 2008 12:03:49 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D95DC0054 for ; Sat, 9 Aug 2008 21:03:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3mg6d2e289sX; Sat, 9 Aug 2008 21:03:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE755C0056; Sat, 9 Aug 2008 21:03:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 83BF3683368; Sat, 9 Aug 2008 21:03:41 +0200 (CEST) Date: Sat, 9 Aug 2008 21:03:41 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080809190341.GA7071@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] consider to volunteer for nomcom X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, please consider volunteering for the nomcom. /js ----- Forwarded message from NomCom Chair ----- Delivered-To: wgchairs@core3.amsl.com From: NomCom Chair To: Working Group Chairs Subject: Please ask your WG... Date: Sun, 3 Aug 2008 07:43:22 -0700 (PDT) To volunteer for the nomcom. The nomcom process is (in my opinion) better served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. As such, please ask on your individual mailing lists for folks to volunteer. Obviously, the exact method for doing so is up to you. The most recent call for volunteers can be reference here: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 Whether you copy that message, or reference is probably up to you and the habits of your working group mailing list. If you want to reference or copy the status message I sent out, that can be found at: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 Thank you, Joel M. Halpern Nomcom Chair jmh@joelahlpern.com nomcom-chair@ietf.org ----- End forwarded message ----- _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Aug 12 09:29:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD34D28C0F5; Tue, 12 Aug 2008 09:29:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9747C3A6962 for ; Mon, 11 Aug 2008 15:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HloqPGrKM3Lt for ; Mon, 11 Aug 2008 15:25:27 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 64AE13A635F for ; Mon, 11 Aug 2008 15:25:27 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2080321wfd.31 for ; Mon, 11 Aug 2008 15:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=oA4jgAEw9eY1Wm/E1WGFVrYFInn7E9bxySuneUk5bDs=; b=sPe1n/wnnC7Fjkw41DJoTVKn7TEkVkTglafcIkwX8HTb870BZFEzZ8WJsPIkPe2pAV YWTxS/qulf5TuBud4QIu4ksvCQwb71JZ64HYxbh78AQtVepJ5IivXIvBGqIXd3ST/a+X lF/6RU4Dc3Q1h/fy4mi/mwvJUNMsCFoa5jQS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=oXDdEylOHASFmYyHXWXbfgcca5YwxcY2CovXWyGantjVqSxDAbInUAG2LY089iYXl4 MZ8m23XD1ajKP2/MDM1DX7M9ho/vxfyTX/X1HaqpqWXbcP1GLEJ4TN3mqANuWMMXIenU O7mje3GAGh67waS3OQAEeLq9H/p0chyWweAX0= Received: by 10.143.42.6 with SMTP id u6mr2341276wfj.140.1218493522108; Mon, 11 Aug 2008 15:25:22 -0700 (PDT) Received: by 10.143.163.2 with HTTP; Mon, 11 Aug 2008 15:25:19 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2008 23:25:19 +0100 From: "Dave Shield" To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9_16883203.1218493522073" X-Google-Sender-Auth: e3e85b7b852f36c3 X-Mailman-Approved-At: Tue, 12 Aug 2008 09:29:25 -0700 Subject: [Isms] Comments on ISMS drafts X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ------=_Part_9_16883203.1218493522073 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As part of preparing for the ISMS session at IETF 72, I read through most of the relevant drafts shortly before the meeting. As someone coming to this from an SNMP perspective, with no particular security expertise, I found the proposed mechanisms to be reasonably clear and understandable. However, in a number of places throughout the various drafts, I sometime had to read a section two or three times to be sure that I had grasped what was being proposed. In particular, there are several concepts common to the Transport Subsystem and Transport Security Model, and hence covered in both (or all three) documents. However the individual descriptions are sometimes incomplete or inconsistent. It proved necessary to read all three documents in detail, to fully understand what is required. Similarly, the terminology used is not entirely consistent between the three documents. I therefore offer the attached comments as a (somewhat verbose!) attempt to clarify text that I found to be less than straightforward to follow. In most cases, I don't believe that these suggestions should affect the content of the proposals themselves - they are mostly simply wordsmithing of the descriptive text. There are also a number of places where I found the current drafts ambiguous or inconsistent. I have attempted to identify these issues and sometime propose possible solutions. These may involve some minor amendments to the proposed behaviour - particularly as relating to the mapping of security names. Naturally, you are free to adopt or reject any/all of these suggestions as you see fit. Dave ------=_Part_9_16883203.1218493522073 Content-Type: application/octet-stream; name=General-comments Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjrmz5710 Content-Disposition: attachment; filename=General-comments SVNNUyBHZW5lcmFsIENvbW1lbnRzCj09PT09PT09PT09PT09PT09PT09PQoKdG1TdGF0ZVJlZmVy ZW5jZSBjYWNoZQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUaGUgbWFpbiBjb25jZXB0IG9mIHRo ZSBJU01TIHByb3Bvc2FsIHNlZW1zIHRvIGJlIGZvciB0aGUgdHJhbnNwb3J0CnN1YnN5c3RlbSB0 byBjb29wZXJhdGUgd2l0aCB0aGUgU2VjdXJpdHkgc3Vic3lzdGVtLCBpbiBvcmRlciB0byB1c2UK dHJhbnNwb3J0LWxldmVsIHNlY3VyaXR5IHBhcmFtZXRlcnMgZm9yIGF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uLgpUaGUgbWVjaGFuaXNtIHVzZWQgZm9yIHRoaXMgcHVycG9zZSBpcyBh ICd0bVN0YXRlUmVmZXJlbmNlIGNhY2hlJy4KQXMgc3VjaCwgdGhlcmUgbmVlZHMgdG8gYmUgYSBj b21tb24gdW5kZXJzdGFuZGluZyBvZiB0aGUgY29udGVudHMgb2YKdGhpcyBjYWNoZSAtIGJvdGgg aW4gdGVybXMgb2Ygd2hhdCBpbmZvcm1hdGlvbiBpdCB3aWxsIGNvbnRhaW4sIGFuZApob3cgdGhh dCBpbmZvcm1hdGlvbiBzaG91bGQgYmUgdXNlZC4gICBIb3dldmVyIHRoZSB0aHJlZSBtYWluIElT TVMKZG9jdW1lbnRzIGNvbnRhaW4gc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQgZGVzY3JpcHRpb25z IG9mIHRoaXMgY2FjaGUsCndpdGggdGhlIFRyYW5zcG9ydCBTdWJzeXN0ZW0gZG9jdW1lbnQgKGlu IHBhcnRpY3VsYXIpIGJlaW5nIHZlcnkgdmFndWUKYWJvdXQgd2hhdCBpbmZvcm1hdGlvbiBzaG91 bGQgYmUgaW5jbHVkZWQuCgogIEl0IHdvdWxkIHNlZW0gc2Vuc2libGUgdG8gaGF2ZSBhIGNvbnNp c3RlbnQgZGVzY3JpcHRpb24gc2hhcmVkIGJ5CmFsbCB0aHJlZSBkb2N1bWVudHMgLSBwcm9iYWJs eSBieSByZXBlYXRpbmcgZXNzZW50aWFsbHkgdGhlIHNhbWUgdGV4dAplYWNoIHRpbWUuICAoUG9z c2libHkgYXVnbWVudGVkIGJ5IGFueSBsb2NhbCBjb25zaWRlcmF0aW9ucykuCgogIDxwcm9wb3Nh bD4KICAgICBYLiAgQ2FjaGVkIEluZm9ybWF0aW9uIGFuZCBSZWZlcmVuY2VzCgogICAgIFdoZW4g cGVyZm9ybWluZyBTTk1QIHByb2Nlc3NpbmcsIHRoZXJlIGFyZSB0d28gbGV2ZWxzIG9mIHN0YXRl CiAgIGluZm9ybWF0aW9uIHRoYXQgbWF5IG5lZWQgdG8gYmUgcmV0YWluZWQ6ICB0aGUgaW1tZWRp YXRlIHN0YXRlCiAgIGxpbmtpbmcgYSByZXF1ZXN0LXJlc3BvbnNlIHBhaXIsIGFuZCBwb3RlbnRp YWxseSBsb25nZXItdGVybSBzdGF0ZQogICByZWxhdGluZyB0byB0aGUgcHJvY2Vzc2luZyBvZiBh IHN0cmVhbSBvZiByZWxhdGVkIHJlcXVlc3RzLgoKICAgVGhlIFJGQzM0MTEgYXJjaGl0ZWN0dXJl IHVzZXMgY2FjaGVzIHRvIG1haW50YWluIHRoZSBzaG9ydC10ZXJtCiAgIG1lc3NhZ2Ugc3RhdGUs IGFuZCB1c2VzIHJlZmVyZW5jZXMgaW4gdGhlIEFTSXMgdG8gcGFzcyB0aGlzCiAgIGluZm9ybWF0 aW9uIGJldHdlZW4gc3Vic3lzdGVtcy4KCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcmVx dWlyZW1lbnRzIGZvciBhIGNhY2hlIHRvIGhhbmRsZSB0aGUKICAgbG9uZ2VyLXRlcm0gdHJhbnNw b3J0IHN0YXRlIGluZm9ybWF0aW9uLCB1c2luZyBhIHRtU3RhdGVSZWZlcmVuY2UKICAgcGFyYW1l dGVyIHRvIHBhc3MgdGhpcyBpbmZvcm1hdGlvbiBiZXR3ZWVuIHN1YnN5c3RlbXMuCgogICBUbyBz aW1wbGlmeSB0aGUgZWxlbWVudHMgb2YgcHJvY2VkdXJlLCB0aGUgcmVsZWFzZSBvZiBzdGF0ZQog ICBpbmZvcm1hdGlvbiBpcyBub3QgYWx3YXlzIGV4cGxpY2l0bHkgc3BlY2lmaWVkLiAgQXMgYSBn ZW5lcmFsIHJ1bGUsCiAgIGlmIHN0YXRlIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSB3aGVuIGEg bWVzc2FnZSBiZWluZyBwcm9jZXNzZWQKICAgZ2V0cyBkaXNjYXJkZWQsIHRoZSBzdGF0ZSByZWxh dGVkIHRvIHRoYXQgbWVzc2FnZSBzaG91bGQgYWxzbyBiZQogICBkaXNjYXJkZWQuICBJZiBzdGF0 ZSBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgd2hlbiBhIHJlbGF0aW9uc2hpcAogICBiZXR3ZWVu IGVuZ2luZXMgaXMgc2V2ZXJlZCwgc3VjaCBhcyB0aGUgY2xvc2luZyBvZiBhIHRyYW5zcG9ydAog ICBzZXNzaW9uLCB0aGUgc3RhdGUgaW5mb3JtYXRpb24gZm9yIHRoYXQgcmVsYXRpb25zaGlwIG1p Z2h0IGFsc28KICAgYmUgZGlzY2FyZGVkLgoKICAgICBYLjEuICBzZWN1cml0eVN0YXRlUmVmZXJl bmNlIGNhY2hlCgogICBUaGUgc2VjdXJpdHlTdGF0ZVJlZmVyZW5jZSBwYXJhbWV0ZXIgaXMgZGVm aW5lZCBpbiBSRkMzNDExLiAgSXRzCiAgIHByaW1hcnkgcHVycG9zZSBpcyB0byBwcm92aWRlIGEg bWFwcGluZyBiZXR3ZWVuIGEgcmVxdWVzdCBhbmQgdGhlCiAgIGNvcnJlc3BvbmRpbmcgcmVzcG9u c2UuICAgVGhpcyBjYWNoZSBpcyBub3QgYWNjZXNzaWJsZSB0byBUcmFuc3BvcnQKICAgTW9kZWxz LCBhbmQgYW4gZW50cnkgaXMgdHlwaWNhbGx5IG9ubHkgcmV0YWluZWQgZm9yIHRoZSBsaWZldGlt ZSBvZgogICBhIHJlcXVlc3QtcmVzcG9uc2UgcGFpciBvZiBtZXNzYWdlcy4KCiAgICAgWC4yLiAg dG1TdGF0ZVJlZmVyZW5jZSBjYWNoZQoKICAgRm9yIGVhY2ggdHJhbnNwb3J0IHNlc3Npb24sIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSB0cmFuc3BvcnQgc2VjdXJpdHkKICAgaXMgc3RvcmVkIGluIGEg Y2FjaGUuICBUaGUgdG1TdGF0ZVJlZmVyZW5jZSBwYXJhbWV0ZXIgaXMgdXNlZCB0bwogICBwYXNz IG1vZGVsLSBhbmQgbWVjaGFuaXNtLXNwZWNpZmljIHBhcmFtZXRlcnMgYmV0d2VlbiB0aGUgVHJh bnNwb3J0CiAgIHN1YnN5c3RlbSBhbmQgdHJhbnNwb3J0LWF3YXJlIFNlY3VyaXR5IE1vZGVscy4K CiAgIFRoZSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlIHdpbGwgdHlwaWNhbGx5IHJlbWFpbiB2YWxp ZCBmb3IgdGhlIGR1cmF0aW9uCiAgIG9mIHRoZSB0cmFuc3BvcnQgc2Vzc2lvbiwgYW5kIGhlbmNl IG1heSBiZSB1c2VkIGZvciBzZXZlcmFsIG1lc3NhZ2VzLgoKICAgU2luY2UgdGhpcyBjYWNoZSBp cyBvbmx5IHVzZWQgd2l0aGluIGFuIGltcGxlbWVudGF0aW9uLCBhbmQgbm90CiAgIG9uLXRoZS13 aXJlLCB0aGUgcHJlY2lzZSBjb250ZW50cyBhbmQgZm9ybWF0IGFyZSBpbXBsZW1lbnRhdGlvbi0K ICAgZGVwZW5kZW50LiAgSG93ZXZlciwgZm9yIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBUcmFu c3BvcnQgTW9kZWxzCiAgIGFuZCB0cmFuc3BvcnQtYXdhcmUgU2VjdXJpdHkgTW9kZWxzLCBlbnRy aWVzIGluIHRoaXMgY2FjaGUgbXVzdAogICBpbmNsdWRlIGF0IGxlYXN0IHRoZSBmb2xsb3dpbmcg ZmllbGRzOgoKICAgICAtIHRyYW5zcG9ydERvbWFpbgogICAgIC0gdHJhbnNwb3J0QWRkcmVzcwog ICAgIC0gdG1TZWN1cml0eU5hbWUKICAgICAtIHRtU2VjdXJpdHlMZXZlbCAgIChidXQgc2VlIGJl bG93KQogICAgIC0gdG1TYW1lU2VjdXJpdHkKICAgICAtIHRtU2Vzc2lvbklECgogICAgIFguMi4x LiAgVHJhbnNwb3J0IGluZm9ybWF0aW9uCgogICAgIEluZm9ybWF0aW9uIGFib3V0IHRoZSBzb3Vy Y2Ugb2YgYW4gaW5jb21pbmcgU05NUCBtZXNzYWdlIGlzIHBhc3NlZCB1cAogICBmcm9tIHRoZSBU cmFuc3BvcnQgc3Vic3lzdGVtIGFzIGZhciBhcyB0aGUgTWVzc2FnZSBQcm9jZXNzaW5nIHN1YnN5 c3RlbS4KICAgSG93ZXZlciB0aGVzZSBwYXJhbWV0ZXJzIGFyZSBub3QgaW5jbHVkZWQgaW4gdGhl IHByb2Nlc3NJbmNvbWluZ01zZyBBU0kKICAgZGVmaW5lZCBpbiBSRkMzNDExLCBhbmQgaGVuY2Ug dGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgZGlyZWN0bHkgYXZhaWxhYmxlCiAgIHRvIHRoZSBTZWN1 cml0eSBNb2RlbC4KCiAgIEEgdHJhbnNwb3J0LWF3YXJlIFNlY3VyaXR5IE1vZGVsIG1pZ2h0IHdp c2ggdG8gdGFrZSBhY2NvdW50IG9mIHRoZQogICB0cmFuc3BvcnQgcHJvdG9jb2wgYW5kIG9yaWdp bmF0aW5nIGFkZHJlc3Mgd2hlbiBhdXRoZW50aWNhdGluZyB0aGUKICAgcmVxdWVzdCwgYW5kIHNl dHRpbmcgdXAgdGhlIGF1dGhvcml6YXRpb24gcGFyYW1ldGVycy4gIEl0IGlzIHRoZXJlZm9yZQog ICBuZWNlc3NhcnkgZm9yIHRoZSBUcmFuc3BvcnQgTW9kZWwgdG8gaW5jbHVkZSB0aGlzIGluZm9y bWF0aW9uIGluIHRoZQogICB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlLCBzbyB0aGF0IGl0IGlzIGFj Y2Vzc2libGUgdG8gdGhlIFNlY3VyaXR5IE1vZGVsLgogICAKICAgICAtIHRyYW5zcG9ydERvbWFp bgogICAgICAgICB0aGUgdHJhbnNwb3J0IHByb3RvY29sIChhbmQgaGVuY2UgdGhlIFRyYW5zcG9y dCBNb2RlbCkgdXNlZCB0byAKICAgICAgICAgcmVjZWl2ZSB0aGUgaW5jb21pbmcgbWVzc2FnZQoK ICAgICAtIHRyYW5zcG9ydEFkZHJlc3MKICAgICAgICAgdGhlIHNvdXJjZSBvZiB0aGUgaW5jb21p bmcgbWVzc2FnZS4KCiAgIE5vdGUgdGhhdCB0aGUgQVNJcyB1c2VkIGZvciBwcm9jZXNzaW5nIGFu IG91dGdvaW5nIG1lc3NhZ2UgYWxsCiAgIGluY2x1ZGUgZXhwbGljaXQgdHJhbnNwb3J0RG9tYWlu IGFuZCB0cmFuc3BvcnRBZGRyZXNzIHBhcmFtZXRlcnMuCiAgIFRoZXNlIGZpZWxkcyB3aXRoaW4g dGhlIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUgd2lsbCB0eXBpY2FsbHkKICAgbm90IGJlIHVzZWQg Zm9yIG91dGdvaW5nIG1lc3NhZ2VzLgoKICAgICBYLjIuMi4gIHNlY3VyaXR5TmFtZQoKICAgICBU aGVyZSBhcmUgYWN0dWFsbHkgdGhyZWUgZGlzdGluY3QgImlkZW50aXRpZXMiIHRoYXQgY2FuIGJl CiAgIGlkZW50aWZpZWQgZHVyaW5nIHRoZSBwcm9jZXNzaW5nIG9mIGFuIFNOTVAgcmVxdWVzdCBv dmVyIGEgc2VjdXJlCiAgIHRyYW5zcG9ydDoKCiAgICAgLSB0cmFuc3BvcnQgcHJpbmNpcGFsOgog ICAgICAgICB0aGUgdHJhbnNwb3J0LWF1dGhlbnRpY2F0ZWQgaWRlbnRpdHksIG9uIHdob3NlIGJl aGFsZiB0aGUKICAgICAgICAgc2VjdXJlIHRyYW5zcG9ydCBjb25uZWN0aW9uIHdhcyAob3Igc2hv dWxkIGJlKSBlc3RhYmxpc2hlZC4KICAgICAgICAgVGhpcyB2YWx1ZSBpcyB0cmFuc3BvcnQtLCBt ZWNoYW5pc20tIGFuZCBpbXBsZW1lbnRhdGlvbi0KICAgICAgICAgc3BlY2lmaWMsIGFuZCBpcyBv bmx5IHVzZWQgd2l0aGluIGEgZ2l2ZW4gVHJhbnNwb3J0IE1vZGVsLgoKICAgICAtIHRtU2VjdXJp dHlOYW1lOgogICAgICAgICBhIGh1bWFuLXJlYWRhYmxlIG5hbWUgKGluIHNubXBBZG1pblN0cmlu ZyBmb3JtYXQpCiAgICAgICAgIHJlcHJlc2VudGluZyB0aGlzIHRyYW5zcG9ydCBpZGVudGl0eS4g IFRoaXMgdmFsdWUgaXMKICAgICAgICAgdHJhbnNwb3J0LSBhbmQgaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMsIGFuZCBpcyBvbmx5CiAgICAgICAgIHVzZWQgKGRpcmVjdGx5KSBieSB0aGUgVHJhbnNw b3J0IGFuZCBTZWN1cml0eSBNb2RlbHMuCgogICAgIC0gc2VjdXJpdHlOYW1lOgogICAgICAgICBh IGh1bWFuLXJlYWRhYmxlIG5hbWUgKGluIHNubXBBZG1pblN0cmluZyBmb3JtYXQpIHJlcHJlc2Vu dGluZwogICAgICAgICB0aGUgU05NUCBwcmluY2lwYWwgaW4gYSBtb2RlbC1pbmRlcGVuZGVudCBt YW5uZXIuCgogICBOb3RlIHRoYXQgdGhlIHRyYW5zcG9ydCBwcmluY2lwYWwgbWF5IG9yIG1heSBu b3QgYmUgdGhlIHNhbWUgYXMKICAgdGhlIHRtU2VjdXJpdHlOYW1lLiAgU2ltaWxhcmx5LCB0aGUg dG1TZWN1cml0eU5hbWUgbWF5IG9yIG1heSBub3QKICAgYmUgdGhlIHNhbWUgYXMgdGhlIHNlY3Vy aXR5TmFtZSBhcyBzZWVuIGJ5IHRoZSBBcHBsaWNhdGlvbiBhbmQKICAgQWNjZXNzIENvbnRyb2wg c3Vic3lzdGVtcy4gICBJbiBwYXJ0aWN1bGFyLCBhIG5vbi10cmFuc3BvcnQtYXdhcmUKICAgU2Vj dXJpdHkgTW9kZWwgd2lsbCBpZ25vcmUgdG1TZWN1cml0eU5hbWUgY29tcGxldGVseSB3aGVuIGRl dGVybWluaW5nCiAgIHRoZSBTTk1QIHNlY3VyaXR5TmFtZS4KCiAgIEhvd2V2ZXIgaXQgaXMgaW1w b3J0YW50IHRoYXQgdGhlIG1hcHBpbmcgYmV0d2VlbiB0aGUgdHJhbnNwb3J0CiAgIHByaW5jaXBh bCBhbmQgdGhlIFNOTVAgc2VjdXJpdHlOYW1lIChmb3IgdHJhbnNwb3J0LWF3YXJlIFNlY3VyaXR5 CiAgIE1vZGVscykgaXMgY29uc2lzdGVudCBhbmQgcHJlZGljdGFibGUsIHRvIGFsbG93IGNvbmZp Z3VyYXRpb24gb2YKICAgc3VpdGFibGUgYWNjZXNzIGNvbnRyb2wgYW5kIHRoZSBlc3RhYmxpc2ht ZW50IG9mIHRyYW5zcG9ydCBjb25uZWN0aW9ucy4KCiAgICAgWC4yLjMuICBzZWN1cml0eUxldmVs CgogICAgIFRoZXJlIGFyZSB0d28gZGlzdGluY3QgaXNzdWVzIHJlbGF0aW5nIHRvIHNlY3VyaXR5 IGxldmVsIGFzCiAgIGFwcGxpZWQgdG8gc2VjdXJlIHRyYW5zcG9ydHMuICBGb3IgY2xhcml0eSwg dGhlc2UgYXJlIGhhbmRsZWQKICAgYnkgc2VwYXJhdGUgZmllbGRzIGluIHRoZSB0bVN0YXRlUmVm ZXJlbmNlIGNhY2hlOgoKICAgICAtIHRtVHJhbnNwb3J0U2VjdXJpdHlMZXZlbDoKICAgICAgICAg YW4gaW5kaWNhdGlvbiBmcm9tIHRoZSBUcmFuc3BvcnQgTW9kZWwgb2YgdGhlIGxldmVsIG9mCiAg ICAgICAgIHNlY3VyaXR5IG9mZmVyZWQgYnkgdGhpcyBzZXNzaW9uLiAgVGhlIFNlY3VyaXR5IE1v ZGVsCiAgICAgICAgIGNhbiB1c2UgdGhpcyB0byBlbnN1cmUgdGhhdCBpbmNvbWluZyBtZXNzYWdl cyB3ZXJlCiAgICAgICAgIHN1aXRhYmx5IHByb3RlY3RlZCBiZWZvcmUgYWN0aW5nIG9uIHRoZW0u CgogICAgIC0gdG1SZXF1ZXN0ZWRTZWN1cml0eUxldmVsOgogICAgICAgICBhbiBpbmRpY2F0aW9u IGZyb20gdGhlIFNlY3VyaXR5IE1vZGVsIG9mIHRoZSBsZXZlbAogICAgICAgICBvZiBzZWN1cml0 eSByZXF1aXJlZCB0byBiZSBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0CiAgICAgICAgIHByb3Rv Y29sLiAgIFRoZSBUcmFuc3BvcnQgTW9kZWwgY2FuIHVzZSB0aGlzIHRvCiAgICAgICAgIGVuc3Vy ZSB0aGF0IG91dGdvaW5nIG1lc3NhZ2VzIHdpbGwgbm90IGJlIHNlbnQgb3ZlcgogICAgICAgICBh biBpbnN1ZmZpY2llbnRseSBzZWN1cmUgc2Vzc2lvbi4KCiAgICAgWC4yLjQuICBTZXNzaW9uIGlu Zm9ybWF0aW9uCgogICAgIEZvciBzZWN1cml0eSByZWFzb25zLCBpZiBhIHNlY3VyZSB0cmFuc3Bv cnQgc2Vzc2lvbiBpcyBjbG9zZWQKICAgYmV0d2VlbiB0aGUgdGltZSBhIHJlcXVlc3QgbWVzc2Fn ZSBpcyByZWNlaXZlZCBhbmQgdGhlIGNvcnJlc3BvbmRpbmcKICAgcmVzcG9uc2UgbWVzc2FnZSBp cyBzZW50LCB0aGVuIHRoZSByZXNwb25zZSBtZXNzYWdlIFNIT1VMRCBiZQogICBkaXNjYXJkZWQs IGV2ZW4gaWYgYSBuZXcgc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZC4gIFRoZSBTTk1QdjMK ICAgV0cgZGVjaWRlZCB0aGF0IHRoaXMgc2hvdWxkIGJlIGEgU0hPVUxEIGFyY2hpdGVjdHVyYWxs eSwgYW5kIGl0IGlzCiAgIGEgc2VjdXJpdHktbW9kZWwtc3BlY2lmaWMgZGVjaXNpb24gd2hldGhl ciB0byBSRVFVSVJFIHRoaXMuCgogICAgLSB0bVNhbWVTZWN1cml0eToKICAgICAgICB0aGlzIGZs YWcgaXMgdXNlZCBieSBhIHRyYW5zcG9ydC1hd2FyZSBTZWN1cml0eSBNb2RlbAogICAgICAgIHRv IGluZGljYXRlIHdoZXRoZXIgdGhlIFRyYW5zcG9ydCBNb2RlbCBzaG91bGQgZW5mb3JjZQogICAg ICAgIHRoaXMgcmVzdHJpY3Rpb24uCgogICAgLSB0bVNlc3Npb25JRDoKICAgICAgICBpbiBvcmRl ciB0byB2ZXJpZnkgd2hldGhlciB0aGUgc2Vzc2lvbiBoYXMgY2hhbmdlZCwgdGhlCiAgICAgICAg VHJhbnNwb3J0IE1vZGVsIG11c3QgYmUgYWJsZSB0byBjb21wYXJlIHRoZSBzZXNzaW9uIHVzZWQK ICAgICAgICB0byByZWNlaXZlIHRoZSBvcmlnaW5hbCByZXF1ZXN0IHdpdGggdGhlIG9uZSB0byBi ZSB1c2VkCiAgICAgICAgdG8gc2VuZCB0aGUgcmVzcG9uc2UuICBUaGlzIHR5cGljYWxseSByZXF1 aXJlcyBzb21lIGZvcm0KICAgICAgICBvZiBzZXNzaW9uIGlkZW50aWZpZXIuICBUaGlzIHZhbHVl IGlzIG9ubHkgZXZlciB1c2VkIGJ5CiAgICAgICAgdGhlIFRyYW5zcG9ydCBNb2RlbCwgc28gdGhl IGZvcm1hdCBhbmQgaW50ZXJwcmV0YXRpb24gb2YKICAgICAgICB0aGlzIGZpZWxkIGFyZSBtb2Rl bC0gYW5kIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4KICA8L3Byb3Bvc2FsPgoKClFuOgogIFRo ZSBhYm92ZSB0ZXh0IGRlc2NyaWJlcyB0aGUgdG1TdGF0ZVJlZmVyZW5jZSBjYWNoZSBhcyBhIHBl ci1zZXNzaW9uCnN0cnVjdHVyZSAoZm9sbG93aW5nIHRoZSBsZWFkIG9mIHRoZSBUcmFuc3BvcnQg c3Vic3lzdGVtIGRvY3VtZW50KS4KSG93ZXZlciB0aGUgdG1TYW1lU2VjdXJpdHkgYW5kIHRtUmVx dWVzdGVkU2VjdXJpdHlMZXZlbCBmaWVsZHMgd29yayBvbgphIHBlci1tZXNzYWdlLiAgSXMgdGhp cyBhIHByb2JsZW0/ICAgSWYgc28sIGhvdyBzaG91bGQgaXQgYmUgaGFuZGxlZD8KCgo= ------=_Part_9_16883203.1218493522073 Content-Type: application/octet-stream; name=TMSM-comments Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjrmzbhg1 Content-Disposition: attachment; filename=TMSM-comments U2VjdGlvbnMgMS4yICYgMS4zCiAgVGhlIG90aGVyIHR3byBkb2N1bWVudHMgc3RhcnQgd2l0aCBJ bnRlcm5ldC1TdGFuZGFyZCBNYW5hZ2VtZW50CkZyYW1ld29yayBhbmQgQ29udmVudGlvbnMgZm9s bG93ZWQgYnkgYSBzZWN0aW9uIG9uIE1vZHVsYXJpdHkuClRoZSBUcmFuc3BvcnQgc3Vic3lzdGVt IGRvY3VtZW50IGhhcyB0aGUgbW9kdWxhcml0eSBkaWFncmFtCmNvbWluZyAqYmVmb3JlKiB0aGUg c2VjdGlvbiBvbiBDb252ZW50aW9ucy4KCiAgPHByb3Bvc2FsPgogICAgIFN3aXRjaCB0aGVzZSB0 d28gc2VjdGlvbnMgYXJvdW5kLgoKICAgICAxLjIuICBDb252ZW50aW9ucwogICAgIDEuMy4gIE1v ZHVsYXJpdHkgICAgW05vdGU6IG5ldyB0aXRsZV0KICA8L3Byb3Bvc2FsPgoKKFRoaXMgd291bGQg YWxzbyBwcm9iYWJseSBhdm9pZCB0aGUgbGFyZ2UgYmxhbmsgc3BhY2Ugb24gcDMhKQoKCihuZXcp IFNlY3Rpb24gMS40CiAgVGhlIG90aGVyIHR3byBkb2N1bWVudHMgYWxzbyBpbmNsdWRlIGEgc2Vj dGlvbiBvbiBDb25zdHJhaW50cywgd2hpY2gKaXMgbWlzc2luZyBmcm9tIHRoZSBzdWJzeXN0ZW0g ZG9jdW1lbnQuICBJdCB3b3VsZCBiZSBzZW5zaWJsZSB0byBpbmNsdWRlCnRoZSBzYW1lIHNlY3Rp b24gaGVyZSwgYXMgYSBndWlkZSB0byBkZXZlbG9wZXJzIG9mIG5ldyBUcmFuc3BvcnQgTW9kZWxz LAp3aG8gbWlnaHQgdXNlIHRoaXMgZG9jdW1lbnQgYXMgYSB0ZW1wbGF0ZS4KCgpTZWN0aW9uIDIs IHBhcmFncmFwaCAyCiAgVGhlIGRlc2NyaXB0aW9uIG9mIHRoZSAidGhpcmQgYXBwcm9hY2giIGlz IHZlcnkgbG9uZyBhbmQgZGV0YWlsZWQuClRoaXMgdGVuZHMgdG8gb2JzY3VyZSB0aGUgYmFzaWMg cG9pbnQuCgogIDxwcm9wb3NhbD4KICAgICAuLi4gSW4gdGhlIHRoaXJkIGFwcHJvYWNoLCBoZSBj b3VsZCBoaXJlIGEgc2VjdXJpdHkgY29tcGFueSwKICAgdGVsbCB0aGVtIHdoYXQgaGUgd2FudHMg cHJvdGVjdGVkLCBhbmQgbGVhdmUgdGhlIGRldGFpbHMgdG8gdGhlbS4KICAgQ29uc2lkZXJhdGlv bnMgb2YgaGlyaW5nIGFuZCB0cmFpbmluZyBlbXBsb3llZXMsIHBvc2l0aW9uaW5nCiAgIGFuZCBz Y2hlZHVsaW5nIGd1YXJkcywgYXJyYW5naW5nIGZvciBjb3ZlciwgZXRjLiBhcmUgdGhlbiB0aGUK ICAgcmVzcG9uc2liaWxpdHkgb2YgdGhlIHNlY3VyaXR5IGNvbXBhbnkuICBUaGUgaW5kaXZpZHVh bCB0aGVyZWZvcmUKICAgYWNoaWV2ZXMgdGhlIGRlc2lyZWQgc2VjdXJpdHksIHd0aCBubyBzaWdu aWZpY2FudCBlZmZvcnQuLi4KICA8L3Byb3Bvc2FsPgoKClNlY3Rpb24gMiwgcGFyYWdyYXBoIDQK ICBUaGlzIHRleHQgaGFsZi1yZWFkcyBhcyBhIGp1c3RpZmljYXRpb24gb2Ygd2hldGhlciBpdCBp cyBwb3NzaWJsZSB0bwp1c2UgVVNNIGF0IGFsbC4gICBUaGUgaW50ZW5kZWQga2V5IHBvaW50IGlz IHByZXN1bWFibHkgdGhhdCBvcGVyYXRvcnMKd291bGQgcHJlZmVyIGFuIGludGVncmF0ZWQgYXBw cm9hY2guCgogIDxwcm9wb3NhbD4KICAgLi4uIFVTTSB0aGVyZWZvcmUgcmVxdWlyZXMgYSBzZXBh cmF0ZSBwcmluY2lwYWwgYW5kIGtleSBtYW5hZ2VtZW50CiAgIGluZnJhc3RydWN0dXJlLCBlaXRo ZXIgY29uZmlndXJlZCB1c2luZyBTTk1QIGl0c2VsZiwgb3IgdmlhIHNvbWUKICAgZXh0ZXJuYWwg bWVjaGFuaXNtLiAgSG93ZXZlciBvcGVyYXRvcnMgaGF2ZSByZXBvcnRlZCB0aGF0IHJlcXVpcmlu ZwogICBzdWNoIGEgc2VwYXJhdGUgaW5mcmFzdHJ1Y3R1cmUgaXMgYSBkZXRlcnJlbnQgdG8gZGVw bG95aW5nIFNOTVB2My4KICAgSXQgd291bGQgYmUgcHJlZmVyYWJsZSB0byBsZXZlcmFnZSBhIHNp bmdsZSB1c2VyIGJhc2UgdGhhdCB3YXNuJ3QKICAgc3BlY2lmaWMgdG8gU05NUC4KICA8L3Byb3Bv c2FsPgoKClNlY3Rpb24gMiwgcGFyYWdyYXBocyA1JjYKICBCb3RoIG9mIHRoZXNlIHBhcmFncmFw aHMgbGVhZCB3aXRoIHRoZSBkb21lc3RpYyBzZWN1cml0eSBhbmFsb2d5LAphbmQgdGhpcyB0ZW5k cyB0byBvYnNjdXJlIHRoZSBTTk1QIGFzcGVjdHMgc29tZXdoYXQuICBUaGUgZW1waGFzaXMKc2hv dWxkIHByb2JhYmx5IGJlIG9uIHRoZSBvcHRpb25zIGZvciBTTk1QIGF1dGhlbnRpY2F0aW9uLCBl dGMuCgogIDxwcm9wb3NhbD4KICAgICBBIFVTTS1jb21wbGlhbnQgYXJjaGl0ZWN0dXJlIG1pZ2h0 IGNvbWJpbmUgdGhlIGF1dGhlbnRpY2F0aW9uCiAgIG1lY2hhbmlzbSB3aXRoIGFuIGV4dGVybmFs IG1lY2hhbmlzbSwgc3VjaCBhcyBSQURJVVMgW1JGQzI4NjVdLAogICB0byBwcm92aWRlIHRoZSBh dXRoZW50aWNhdGlvbiBzZXJ2aWNlLiAgU2ltaWxhcmx5IGl0IG1pZ2h0IGJlCiAgIHBvc3NpYmxl IHRvIHV0aWxpemUgYW4gZXh0ZXJuYWwgcHJvdG9jb2wgdG8gZW5jcnlwdCBhIG1lc3NhZ2UsCiAg IHRvIGNoZWNrIHRpbWVsaW5lc3MsIHRvIGNoZWNrIGRhdGEgaW50ZWdyaXR5LCBldGMuICBIb3dl dmVyIHRoaXMKICAgY29ycmVzcG9uZHMgdG8gdGhlIHNlY29uZCBhcHByb2FjaCAtIHJlcXVpcmlu ZyB0aGUgY29vcmRpbmF0aW9uCiAgIG9mIGEgbnVtYmVyIG9mIGRpZmZlcmVudHkgc3ViY29udHJh Y3RlZCBzZXJ2aWNlcy4gIEJ1aWxkaW5nIHNvbGlkCiAgIHNlY3VyaXR5IGJldHdlZW4gdGhlIHZh cmlvdXMgc2VydmljZXMgaXMgZGlmZmljdWx0LCBhbmQgdGhlcmUgaXMKICAgYSBzaWduaWZpY2Fu dCBwb3RlbnRpYWwgZm9yIGdhcHMgaW4gc2VjdXJpdHkuCgogICBBbiBhbHRlcm5hdGl2ZSBhcHBy b2FjaCBtaWdodCBiZSB0byB1dGlsaXplIG9uZSBvciBtb3JlIGxvd2VyLWxheWVyCiAgIHNlY3Vy aXR5IG1lY2hhbmlzbXMgdG8gcHJvdmlkZSB0aGUgbWVzc2FnZS1vcmllbnRlZCBzZWN1cml0eQog ICBzZXJ2aWNlcyByZXF1aXJlZC4gIFRoZXNlIHdvdWxkIGluY2x1ZGUgYXV0aGVudGljYXRpb24g b2YgdGhlCiAgIHNlbmRlciwgZW5jcnlwdGlvbiwgdGltZWxpbmVzcyBjaGVja2luZywgYW5kIGRh dGEgaW50ZWdyaXR5IGNoZWNraW5nLgogICBUaGlzIGNvcnJlc3BvbmRzIHRvIHRoZSB0aGlyZCBh cHByb2FjaCBkZXNjcmliZWQgYWJvdmUuCiAgIFRoZXJlIGFyZSBhIG51bWJlciBvZiBJRVRGIHN0 YW5kYXJkcyAuLi4uCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMuMQogIElzIGl0IG5lY2Vzc2Fy eSB0byByZWZlcmVuY2UgUkZDIDM0MTEgYm90aCBiZWZvcmUgKmFuZCogYWZ0ZXIgdGhlCmxpc3Qg b2YgdGhyZWF0cz8KCiAgPHByb3Bvc2FsPgogICBEZWxldGUgIiBbUkZDMzQxMV0iIGZyb20gYmVm b3JlIHRoZSBsaXN0IG9mIHRocmVhdHMKICA8L3Byb3Bvc2FsPgoKClNlY3Rpb24gMy4xLjEsIHBh cmFncmFwaCAxCgogIDxwcm9wb3NhbD4KICAgICBzL1NIT1VMRC9zaG91bGQvCiAgPC9wcm9wb3Nh bD4KCgpTZWN0aW9uIDMuMS4xLCBwYXJhZ3JhcGggMgogIEknbSBzdGlsbCBub3QgZW50aXJlbHkg c3VyZSB3aGF0IHRoZSBsYXN0IHNlbnRlbmNlIGlzIHRyeWluZyB0byBzYXkuClRoZSBmb2xsb3dp bmcgZW5jYXBzdWxhdGVzIHdoYXQgSSAqdGhpbmsqIGl0J3MgcmVmZXJyaW5nIHRvOgoKICA8cHJv cG9zYWwgY29uZmlkZW5jZT0wPgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGFueSBwcm9wb3Nl ZCBUcmFuc3BvcnQgTW9kZWwgaW5jbHVkZQogICBhIGRlc2NyaXB0aW9uIG9mIHRoZSBhcHBsaWNh YmlsaXR5IG9mIHRoZSByZWxldmFudCBzZWN1cml0eQogICBwcm90b2NvbChzKSBmb3IgdXNlIGlu IHRoYXQgVHJhbnNwb3J0IE1vZGVsLgogIDwvcHJvcG9zYWw+CgpJZiBJIGhhdmUgbWlzdW5kZXJz dG9vZCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlbnRlbmNlLCB0aGVuIHNvbWUgZnVsbGVyCmV4cGxh bmF0aW9uIHdvdWxkIHByb2JhYmx5IGJlIHVzZWZ1bC4KCgpTZWN0aW9uIDMuMS4xLCBwYXJhZ3Jh cGggMywgc2VudGVuY2UgMgoKICA8cHJvcG9zYWw+CiAgICBzL3dvdWxkL2NvdWxkLyAgICBpLmUu CiAgICAuLi4gaW4gd2F5cyB0aGF0IGNvdWxkIGltcGFjdCBvdGhlciBleGlzdGluZyB1c2FnZXMu IC4uLgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiAzLjIuMQogIFRoZSBkZXNjcmlwdGlvbiBvZiB0 aGUgZXhpc3RpbmcgYXJjaGl0ZWN0dXJlIChpbiBwYXJhZ3JhcGggMikgbGlzdHMKdGhlIGNvbXBv bmVudHMgaW4gYSBzZWVtaW5nbHkgcmFuZG9tIG9yZGVyLiAgSXQgd291bGQgYmUgbW9yZSBuYXR1 cmFsCnRvIGxpc3QgdGhlc2UgaW4gdGhlIG9yZGVyIHRoYXQgdGhleSBhcmUgdXNlZCAoYXMgaW4g dGhlIGRpYWdyYW0gb24gcDQpLgoKVGhlIHRoaXJkIHNlbnRlbmNlIG9mIHRoZSBzYW1lIHBhcmFn cmFwaCBpcyBwZXJoYXBzIGEgbGl0dGxlIHRvbyBzdHJvbmcuCgpUaGUgcmVzdCBvZiB0aGlzIHNl Y3Rpb24gZG9lc24ndCByZWFsbHkgc2VlbSB0byBoYW5nIHRvZ2V0aGVyIHZlcnkgd2VsbC4KQSBy ZS1vcmRlcmluZyBvZiB0aGUgc2FtZSBiYXNpYyBtYXRlcmlhbCB3b3VsZCBwcm9iYWJseSBwcm92 aWRlIGEgbW9yZQpjb2hlcmVudCBleHBsYW5hdGlvbiBvZiBob3cgdGhlIFRyYW5zcG9ydCBzdWJz eXN0ZW0gZml0cyBpbnRvIHRoZSBiYXNpYwpSRkMzNDExIGFyY2hpdGVjdHVyYWwgcmVxdWlyZW1l bnRzLgoKSW4gcGFydGljdWxhciwgcGFyYWdyYXBocyAzJjYgZmVlbCB0byBiZSBkaXJlY3RseSBy ZWxhdGVkLCBhbmQgY291bGQKdXNlZnVsbHkgYmUgbWVyZ2VkLiAgSXQgd291bGQgYWxzbyBiZSB3 b3J0aCBlbXBoYXNpc2luZyB0aGUgZnVuY3Rpb25hbApiZW5lZml0cyBvZiBhIFRyYW5zcG9ydCBz dWJzeXN0ZW0sIHJhdGhlciB0aGFuIHRoZSBpbXBsaWNhdGlvbnMgZm9yCklFVEYgcHJvZ3Jlc3Np b24uCgpUaGUgbW90aXZhdGlvbiBiZWhpbmQgdGhlIFRyYW5zcG9ydCBTdWJzeXN0ZW0gKGluIHBh cmFncmFwaCA1KSwgYW5kCmxpc3RpbmcgcGFydGljdWxhciBleGFtcGxlcywgaXNuJ3QgcmVhbGx5 IGRpcmVjdGx5IHJlbGV2YW50IHRvIHRoZSBpZGVhCm9mIG1hbmRhdG9yeSBlbGVtZW50cy4gIE1l bnRpb25pbmcgdGhlbSBoZXJlIHNlcnZlcyB0byBvYnNjdXJlIHRoZQptYWluIHBvaW50IG9mIHRo ZSBwYXJhZ3JhcGguCgogIDxwcm9wb3NhbD4KICAgICAzLjIuMS4gIEFyY2hpdGVjdHVyYWwgTW9k dWxhcml0eSBSZXF1aXJlbWVudHMKCiAgIFNOTVAgdmVyc2lvbiAzIChTTk1QdjMpIGlzIGJhc2Vk IG9uIGEgbW9kdWxhciBhcmNoaXRlY3R1cmUgKGRlZmluZWQKICAgaW4gW1JGQzM0MTFdIHNlY3Rp b24gMykgdG8gYWxsb3cgdGhlIGV2b2x1dGlvbiBvZiB0aGUgU05NUCBwcm90b2NvbAogICBzdGFu ZGFyZHMgb3ZlciB0aW1lLCBhbmQgdG8gbWluaW1pemUgc2lkZSBlZmZlY3RzIGJldHdlZW4gc3Vi c3lzdGVtcwogICB3aGVuIGNoYW5nZXMgYXJlIG1hZGUuCgogICBUaGUgUkZDMzQxMSBhcmNoaXRl Y3R1cmUgaW5jbHVkZXMgYSBNZXNzYWdlIFByb2Nlc3NpbmcgU3Vic3lzdGVtCiAgIHBlcm1pdHRp bmcgZGlmZmVyZW50IG1lc3NhZ2UgdmVyc2lvbnMgdG8gYmUgaGFuZGxlZCBieSBhIHNpbmdsZQog ICBlbmdpbmUsIGEgU2VjdXJpdHkgU3Vic3lzdGVtIGZvciBlbmFibGluZyBkaWZmZXJlbnQgbWV0 aG9kcyBvZgogICBwcm92aWRpbmcgc2VjdXJpdHkgc2VydmljZXMsIGFuIEFjY2VzcyBDb250cm9s IFN1YnN5c3RlbSBmb3IKICAgYWxsb3dpbmcgbXVsdGlwbGUgYXBwcm9hY2hlcyB0byBhY2Nlc3Mg Y29udHJvbCwgYW5kIEFwcGxpY2F0aW9uKHMpCiAgIHRvIHN1cHBvcnQgZGlmZmVyZW50IHR5cGUg b2YgYXBwbGljYXRpb24gcHJvY2Vzc29ycy4gIFRoZSBSRkMzNDExCiAgIGFyY2hpdGVjdHVyZSBk b2VzIG5vdCBpbmNsdWRlIGEgc3Vic3lzdGVtIGZvciBUcmFuc3BvcnQgTW9kZWxzLAogICBkZXNw aXRlIHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlIHRyYW5zcG9ydCBtYXBwaW5ncyBh bHJlYWR5CiAgIGRlZmluZWQgZm9yIFNOTVAuICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGEgVHJh bnNwb3J0IFN1YnN5c3RlbSB0aGF0CiAgIGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgUkZDMzQxMSBh cmNoaXRlY3R1cmUuICBBcyB3b3JrIGlzIGJlaW5nIGRvbmUKICAgdG8gdXNlIHNlY3VyZSB0cmFu c3BvcnRzIHN1Y2ggYXMgU1NIIGFuZCBUTFMsIHVzaW5nIGEgc2JzeXN0ZW0gd2lsbAogICBlbmFi bGUgY29uc2lzdGVudCBkZXNpZ24gYW5kIG1vZHVsYXJpdHkgb2Ygc3VjaCBUcmFuc3BvcnQgTW9k ZWxzLgoKICAgVGhlIGRlc2lnbiBvZiB0aGlzIFRyYW5zcG9ydCBTdWJzeXN0ZW0gYWNjZXB0cyB0 aGUgZ29hbHMgb2YgdGhlCiAgIFJGQzM0MTEgYXJjaGl0ZWN0dXJlIGRlZmluZWQgaW4gc2VjdGlv biAxLjUgb2YgW1JGQzM0MTFdLiAgVGhpcwogICBUcmFuc3BvcnQgU3Vic3lzdGVtIHVzZXMgYSBt b2R1bGFyIGRlc2lnbiB0aGF0IHBlcm1pdHMgbXVsdGlwbGUKICAgdHJhbnNwb3J0IHByb3RvY29s cyB0byBiZSAicGx1Z2dlZCBpbnRvIiB0aGUgUkZDMzQxMSBhcmNoaXRlY3R1cmUsCiAgIHN1cHBv cnRlZCBieSBjb3JyZXNwb25kaW5nIFRyYW5zcG9ydCBNb2RlbHMgKHdoaWNoIG1heSBvciBtYXkg bm90CiAgIGJlIHNlY3VyaXR5LWF3YXJlKS4gIFN1Y2ggVHJhbnNwb3J0IE1vZGVscyB3b3VsZCBi ZSBpbmRlcGVuZGVudCBvZgogICBvdGhlciBtb2R1bGFyIFNOTVAgY29tcG9uZW50cyBhcyBtdWNo IGFzIHBvc3NpYmxlLiAgVGhpcyBkZXNpZ24KICAgYWxzbyBwZXJtaXRzIFRyYW5zcG9ydCBNb2Rl bHMgdG8gYmUgYWR2YW5jZWQgdGhyb3VnaCB0aGUgc3RhbmRhcmRzCiAgIHByb2Nlc3MgaW5kZXBl bmRlbnRseSBvZiBvdGhlciBUcmFuc3BvcnQgTW9kZWxzLgoKICAgVG8gZW5jb3VyYWdlIGEgYmFz aWMgbGV2ZWwgb2YgaW50ZXJvcGVyYWJpbGl0eSwgSUVURiBzdGFuZGFyZHMKICAgdHlwaWNhbGx5 IHJlcXVpcmUgb25lIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc29sdXRpb24sIHdpdGggdGhlCiAg IGNhcGFiaWxpdHkgb2YgYWRkaW5nIG5ldyBtZWNoYW5pc21zIGluIHRoZSBmdXR1cmUuICBBbnkg VHJhbnNwb3J0CiAgIE1vZGVsIFNIT1VMRCBkZWZpbmUgb25lIG1pbmltdW0tY29tcGxpYW5jZSBz ZWN1cml0eSBtZWNoYW5pc20sIGJ1dAogICBzaG91bGQgYWxzbyBiZSBhYmxlIHRvIHN1cHBvcnQg YWRkaXRpb25hbCBleGlzdGluZyBhbmQgbmV3IG1lY2hhbmlzbXMuCgogICBUaGUgZm9sbG93aW5n IGRpYWdyYW0gZGVwaWN0cyB0aGUgU05NUHYzIGFyY2hpdGVjdHVyZSBpbmNsdWRpbmcgdGhlCiAg IG5ldyBUcmFuc3BvcnQgU3Vic3lzdGVtIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kIGEg bmV3IFRyYW5zcG9ydAogICBTZWN1cml0eSBNb2RlbCBkZWZpbmVkIGluIFtJLUQuaWV0Zi1pc21z LXRyYW5zcG9ydC1zZWN1cml0eS1tb2RlbF0uCiAgPC9wcm9wb3NhbD4KClFuOiBJcyBpdCBpbnRl bmRlZCB0byBzcGVjaWZ5IFNTSC1UTSBhcyB0aGUgYmFzaWMgaW50ZXJvcGVyYWJpbGl0eQogICAg c2VjdXJlIFRyYW5zcG9ydCBNb2RlbD8gIElmIHNvLCBpdCB3b3VsZCBwcm9iYWJseSBiZSBzZW5z aWJsZQogICAgdG8gc3RhdGUgdGhpcyBleHBsaWNpdGx5IHNvbWV3aGVyZS4gIFRoZSBlbmQgb2Yg dGhlIHBlbnVsdGltYXRlCiAgICBwYXJhZ3JhcGggYWJvdmUgd291bGQgc2VlbSBhbiBvYnZpb3Vz IHBsYWNlIHRvIGRvIHRoaXMuCgoKU2VjdGlvbiAzLjIuMSwgcGFyYWdyYXBocyA0LDcmOAogIFRo ZXNlIHRocmVlIHBhcmFncmFwaHMgZGlzY3VzcyAqY2hhbmdlcyogdG8gdGhlIGJhc2ljIFJGQzM0 MTEgbW9kZWwKKG92ZXIgYW5kIGFib3ZlIHRoZSBzaW1wbGUgaW50cm9kdWN0aW9uIG9mIHRoZSBU cmFuc3BvcnQgU3Vic3lzdGVtKS4KSXQgd291bGQgcHJvYmFibHkgYmUgd29ydGggcHVsbGluZyB0 aGVzZSBvdXQgaW50byBhIHNlcGFyYXRlIHN1YnNlY3Rpb24sCnRvIGVtcGhhc2lzZSB0aGlzIGZh Y3QuICAgVGhlIGZvbGxvd2luZyB0ZXh0IGFsc28gb21pdHMgc29tZSB1bm5lY2Vzc2FyeQpkZXRh aWwsIHdoaWNoIHRlbmRlZCB0byBvYnNjdXJlIHRoZSBiYXNpYyBpZGVhcyBiZWluZyBkZXNjcmli ZWQuCgogIDxwcm9wb3NhbCBsb2NhdGlvbj1hZnRlcl9kaWFncmFtX29uX3AxMD4KICAgICAzLjIu MS4xLiAgQ2hhbmdlcyB0byBSRkMzNDExIGFyY2hpdGVjdHVyZQoKICAgICBUaGUgUkZDMzQxMSBh cmNoaXRlY3R1cmUgYW5kIHRoZSBTZWN1cml0eSBTdWJzeXN0ZW0gYXNzdW1lIHRoYXQKICAgYSBT ZWN1cml0eSBNb2RlbCBpcyBjYWxsZWQgYnkgYSBNZXNzYWdlIFByb2Nlc3NpbmcgTW9kZWwgYW5k IHdpbGwKICAgcGVyZm9ybSBtdWx0aXBsZSBzZWN1cml0eSBmdW5jdGlvbnMgd2l0aGluIHRoZSBT ZWN1cml0eSBTdWJzeXN0ZW0uCiAgIEEgVHJhbnNwb3J0IE1vZGVsIHRoYXQgc3VwcG9ydHMgYSBz ZWN1cmUgdHJhbnNwb3J0IHByb3RvY29sIG1pZ2h0CiAgIHBlcmZvcm0gc2ltaWxhciBzZWN1cml0 eSBmdW5jdGlvbnMgd2l0aGluIHRoZSBUcmFuc3BvcnQgU3Vic3lzdGVtLAogICBpbmNsdWRpbmcg dGhlIHRyYW5zbGF0aW9uIG9mIHRyYW5zcG9ydCBzZWN1cml0eSBwYXJhbWV0ZXJzIHRvL2Zyb20K ICAgc2VjdXJpdHktbW9kZWwtaW5kZXBlbmRlbnQgcGFyYW1ldGVycy4KCiAgIFRvIGFjY29tbW9k YXRlIHRoaXMsIGFuIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGNhY2hlIG9mIHRyYW5zcG9ydC0K ICAgc3BlY2lmaWMgaW5mb3JtYXRpb24gd2lsbCBiZSBkZXNjcmliZWQgKG5vdCBzaG93biksIGFu ZCB0aGUgZGF0YQogICBmbG93cyBiZXR3ZWVuIG1vZHVsZXMgb24gdGhpcyBwYXRoIHdpbGwgYmUg ZXh0ZW5kZWQgdG8gcGFzcwogICBzZWN1cml0eS1tb2RlbC1pbmRlcGVuZGVudCB0cmFuc3BvcnQg aW5mb3JtYXRpb24uICAgTm90ZSB0aGF0IHRoaXMKICAgZG9jdW1lbnQgYW1lbmRzIHNvbWUgb2Yg dGhlIEFTSXMgZGVmaW5lZCBpbiBSRkMgMzQxMSwgYW5kIHRoZXNlCiAgIGNoYW5nZXMgYXJlIGNv dmVyZWQgaW4gc2VjdGlvbnMgNi4yIGFuZCA2LjQuCgogICBOZXcgU2VjdXJpdHkgTW9kZWxzIG1h eSBiZSBkZWZpbmVkIHRoYXQgdW5kZXJzdGFuZCBob3cgdG8gd29yawogICB3aXRoIHRoZXNlIG1v ZGlmaWVkIEFTSXMgYW5kIHRoZSB0cmFuc3BvcnQtaW5mb3JtYXRpb24gY2FjaGUuCiAgIE9uZSBz dWNoIFNlY3VyaXR5IE1vZGVsLCB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsLCBpcyBkZWZp bmVkCiAgIGluIFtJLUQuaWV0Zi1pc21zLXRyYW5zcG9ydC1zZWN1cml0eS1tb2RlbF0KICA8cHJv cG9zYWw+CgoKKGN1cnJlbnQpIFNlY3Rpb24gMy4yLjEuMQogIFRoaXMgaXNuJ3QgcmVhbGx5IHNw ZWNpZmljIHRvIFVTTSAtIGl0IGFjdHVhbGx5IHNlZW1zIHRvIGJlIGRpc2N1c3NpbmcKdGhlIHBy b2Nlc3NpbmcgZGlmZmVyZW5jZXMgYXMgY29tcGFyZWQgdG8gdGhlIGN1cnJlbnQgUkZDMzQxMSBh cmNoaXRlY3R1cmUKd2hlbiB1c2VkIHdpdGggKmFueSogKG5vbi10cml2aWFsKSBTZWN1cml0eSBN b2RlbC4KQWdhaW4sIHRoZXJlIGlzIGFuIGV4Y2VzcyBvZiBkZXRhaWwgd2hpY2ggc2VydmVzIHRv IG9ic2N1cmUgdGhlIG1haW4KcG9pbnQgb2YgdGhlIHBhcmFncmFwaC4KClRoaXMgc3Vic2VjdGlv biB3b3VsZCBhbHNvIG5lZWQgdG8gYmUgcmVudW1iZXJlZCwgaWYgdGhlIG5ldyBzdWJzZWN0aW9u CnByb3Bvc2VkIGFib3ZlIGlzIGluY2x1ZGVkLgoKICA8cHJvcG9zYWw+CiAgICAgMy4yLjEuMi4g IENoYW5nZXMgdG8gUkZDMzQxMSBwcm9jZXNzaW5nCgogICAgIFRoZSBpbnRyb2R1Y3Rpb24gb2Yg c2VjdXJlIHRyYW5zcG9ydHMgYWxzbyBhZmZlY3RzIHRoZSAoc2VjdXJpdHk/KQogICByZXNwb25z aWJpbGl0aWVzIGFuZCBvcmRlciBvZiBwcm9jZXNzaW5nIHdpdGhpbiB0aGUgUkZDMzQxMQogICBh cmNoaXRlY3R1cmUuICBXaGlsZSB0aGUgc3RlcHMgYXJlIHRoZSBzYW1lLCB0aGV5IG1heSBvY2N1 ciBpbiBhCiAgIGRpZmZlcmVudCBvcmRlciwgYW5kIG1heSBiZSBkb25lIGJ5IGRpZmZlcmVudCBz dWJzeXN0ZW1zLiAgV2l0aAogICB0aGUgZXhpc3RpbmcgUkZDMzQxMSBhcmNoaXRlY3R1cmUsIHNl Y3VyaXR5IHByb2Nlc3Npbmcgc3RhcnRzIHdoZW4KICAgdGhlIE1lc3NhZ2UgUHJvY2Vzc2luZyBN b2RlbCBkZWNvZGVzIHBvcnRpb25zIG9mIHRoZSBlbmNvZGVkIG1lc3NhZ2UKICAgdG8gZXh0cmFj dCBwYXJhbWV0ZXJzIHRoYXQgaWRlbnRpZnkgd2hpY2ggU2VjdXJpdHkgTW9kZWwgc2hvdWxkCiAg IGhhbmRsZSB0aGUgc2VjdXJpdHktcmVsYXRlZCB0YXNrcy4KCiAgIEEgc2VjdXJlIHRyYW5zcG9y dCBwZXJmb3JtcyB0aG9zZSBzZWN1cml0eSBmdW5jdGlvbnMgb24gdGhlIG1lc3NhZ2UsCiAgICpi ZWZvcmUqIHRoZSBtZXNzYWdlIGlzIGRlY29kZWQuICBOb3RlIHRoYXQgc29tZSBvZiB0aGVzZSBm dW5jdGlvbnMKICAgbWlnaHQgdGhlbiBiZSByZXBlYXRlZCBieSB0aGUgc2VsZWN0ZWQgU2VjdXJp dHkgTW9kZWwuCiAgPC9wcm9wb3NhbD4KCkkgYmVsaWV2ZSB0aGlzIGxhc3Qgc2VudGVuY2UgaXMg dHJ1ZSAtIHBhcnRpY3VsYXJseSBpZiB0aGUgbWVzc2FnZQpzcGVjaWZpZXMgYSBub24tVE0tYXdh cmUgU2VjdXJpdHkgTW9kZWwsIHN1Y2ggYXMgVVNNLiAgIFRoaXMgbWF5IG9yCm1heSBub3QgYmUg cmVsZXZhbnQsIGJ1dCBpdCBzZWVtcyB3b3J0aCBtZW50aW9uaW5nLgoKCihjdXJyZW50KSBTZWN0 aW9uIDMuMi4xLjIKCiAgPHByb3Bvc2FsPgogICAgIDMuMi4xLjMuICBQYXNzaW5nIEluZm9ybWF0 aW9uIGJldHdlZW4gU05NUCBFbmdpbmVzCgogICAgIHMvb3RoZXIgU05NUCBlbmdpbmUvb3RoZXIv CiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMuMi4yLjEsIHBhcmFncmFwaCA0CiAgVGhlIGZpcnN0 IHRocmVlIHBhcmFncmFwaHMgb2YgdGhpcyBzZWN0aW9uIG91dGxpbmUgdGhlIGN1cnJlbnQgUkZD MzQxMQphcmNoaXRlY3R1cmUuICBUaGlzIGZpbmFsIHBhcmFncmFwaCBzZWVtcyB0byBkZXNjcmli ZSB0aGUgaW1wbGljYXRpb25zIG9mCmFkZGluZyBhIHNlY3VyZSBUcmFuc3BvcnQgTW9kZWwsIGJ1 dCB0aGlzIGlzbid0IGltbWVkaWF0ZWx5IG9idmlvdXMuCgogIDxwcm9wb3NhbD4KICAgICBUaGUg aW50cm9kdWN0aW9uIG9mIGEgc2VjdXJlIHRyYW5zcG9ydCBwcm90b2NvbCBtZWFucyB0aGF0IHRo ZQogICB0cmFuc2xhdGlvbiBmcm9tIGEgbWVjaGFuaXNtLXNwZWNpZmljIGlkZW50aXR5IHRvIGEg c2VjdXJpdHlOYW1lCiAgIG1pZ2h0IGFsc28gYmUgZG9uZSBieSBhIFRyYW5zcG9ydCBNb2RlbC4g IFRoaXMgcHJvcG9zZWQgc2VjdXJpdHlOYW1lCiAgIG1pZ2h0IHRoZW4gYmUgbWFkZSBhdmFpbGFi bGUgdG8gdGhlIFNlY3VyaXR5IE1vZGVsLCB0b2dldGhlciB3aXRoIGFuCiAgIGluZGljYXRpb24g b2YgdGhlIGxldmVsIG9mIHNlY3VyaXR5IHByb3ZpZGVkIGJ5IHRoZSB0cmFuc3BvcnQgbGF5ZXIu CiAgIEEgU2VjdXJpdHkgTW9kZWwgbWlnaHQgaGF2ZSBtdWx0aXBsZSAuLi4KCiAgIChpbiB0aGUg ZmluYWwgc2VudGVuY2UpIAogICAgIHMvbWFkZSBhdmFpbGFibGUvcHJvcG9zZWQvCiAgPC9wcm9w b3NhbD4KCgpTZWN0aW9uIDMuMi4zLCBwYXJhZ3JhcGggMi00CiAgVGhpcyB0ZXh0IHNob3VsZCBw cm9iYWJseSBjb25jZW50cmF0ZSBvbiB0aGUgaGFuZGxpbmcgb2Ygc2VjdXJpdHkKcGFyYW1ldGVy cywgcmF0aGVyIHRoYW4gcHJvdmlkaW5nIHVubmVjZXNzYXJ5IGRldGFpbHMgb2YgdGhlIHByb2Nl c3NpbmcKd2l0aGluIHRoZSBTZWN1cml0eSBNb2R1bGUuCgogIFRoZSBpbnRlbmRlZCBtZWFuaW5n IG9mIHBhcmFncmFwaCA0IHJlbWFpbnMgc29tZXdoYXQgdW5jbGVhciB0byBtZSwKcGFydGljdWxh cmx5IGFzIGl0IG1pZ2h0IHJlbGF0ZSB0byB0aGUgcGFzc2luZyBvZiBzZWN1cml0eSBwYXJhbWV0 ZXJzCmJldHdlZW4gc3Vic3lzdGVtcy4gIEl0IHNlZW1zIHRvIGJlIGRpc2N1c3NpbmcgdGhlIHB1 cnBvc2UgYW5kIGFjdGlvbnMKb2YgYSBTZWN1cml0eSBNb2RlbCwgd2hlbiB1c2VkIHdpdGggYSBz ZWN1cml0eS1hd2FyZSBUcmFuc3BvcnQgTW9kZWwuCkhvd2V2ZXIgdGhpcyBkb2VzIG5vdCBzZWVt IHRvIGJlIGNvbmNlcm5lZCB3aXRoIHRoZSBoYW5kbGluZyBvZiBzZWN1cml0eQpwYXJhbWV0ZXJz LiAgTm8gcHJvcG9zZWQgYWx0ZXJuYXRpdmUgaXMgc3VnZ2VzdGVkIGZvciB0aGlzIHRleHQsIGFz IEkKd291bGQgcXVlc3Rpb24gd2hldGhlciB0aGlzIHBhcmFncmFwaCBzaG91bGQgYXBwZWFyIGhl cmUgYXQgYWxsLgoKICA8cHJvcG9zYWw+CiAgICAgQSBNZXNzYWdlIFByb2Nlc3NpbmcgTW9kZWwg bWlnaHQgdW5wYWNrIFNOTVAtc3BlY2lmaWMgc2VjdXJpdHkKICAgcGFyYW1ldGVycyBmcm9tIGFu IGluY29taW5nIG1lc3NhZ2UgYmVmb3JlIGNhbGxpbmcgYSBzcGVjaWZpYwogICBTZWN1cml0eSBN b2RlbCB0byBoYW5kbGUgdGhlIHNlY3VyaXR5LXJlbGF0ZWQgcHJvY2Vzc2luZyBvZiB0aGUKICAg bWVzc2FnZS4gIFdoZW4gdXNpbmcgYSBzZWN1cmUgVHJhbnNwb3J0IE1vZGVsLCBzb21lIHNlY3Vy aXR5CiAgIHBhcmFtZXRlcnMgbWlnaHQgYmUgZXh0cmFjdGVkIGZyb20gdGhlIHRyYW5zcG9ydCBs YXllciBieSB0aGlzCiAgIG1vZGVsIGJlZm9yZSB0aGUgbWVzc2FnZSBpcyBwYXNzZWQgdG8gdGhl IE1lc3NhZ2UgUHJvY2Vzc2luZwogICBTdWJzeXN0ZW0uICBUaGlzIGluZm9ybWF0aW9uIHNob3Vs ZCBhbHNvIGJlIG1hZGUgYXZhaWxhYmxlIHRvIAogICB0aGUgU2VjdXJpdHkgTW9kZWwuCgogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGNhY2hlIG1lY2hhbmlzbSAoc2VlIHNlY3Rpb24gNSks IGludG8gd2hpY2gKICAgdGhlIFRyYW5zcG9ydCBNb2RlbCBwdXRzIGluZm9ybWF0aW9uIGFib3V0 IHRoZSB0cmFuc3BvcnQgYW5kIHNlY3VyaXR5CiAgIHBhcmFtZXRlcnMgYXBwbGllZCB0byBhIHRy YW5zcG9ydCBjb25uZWN0aW9uIG9yIGluY29taW5nIG1lc3NhZ2UsIGFuZAogICBmcm9tIHdoaWNo IGEgU2VjdXJpdHkgTW9kZWwgbWF5IGV4dHJhY3QgdGhpcyBpbmZvcm1hdGlvbi4gCiAgIEEgdG1T dGF0ZVJlZmVyZW5jZSBpcyBwYXNzZWQgYXMgYW4gZXh0cmEgcGFyYW1ldGVyIGluIHRoZSBBU0lz CiAgIGJldHdlZW4gdGhlIFRyYW5zcG9ydCwgTWVzc2FnZSBQcm9jZXNzaW5nIGFuZCBTZWN1cml0 eSBTdWJzeXN0ZW1zLCB0bwogICBpZGVudGlmeSB0aGUgcmVsZXZhbnQgY2FjaGUuICBUaGlzIGFw cHJvYWNoIG9mIHBhc3NpbmcgYSBtb2RlbC0KICAgaW5kZXBlbmRlbnQgcmVmZXJlbmNlIGlzIGNv bnNpc3RlbnQgd2l0aCB0aGUgc2VjdXJpdHlTdGF0ZVJlZmVyZW5jZQogICBjYWNoZSBwYXNzZWQg YmV0d2VlbiB0aGUgU2VjdXJpdHksIEFjY2VzcyBDb250cm9sIGFuZCBBcHBsaWNhaW9uCiAgIHN1 YnN5c3RlbXMgaW4gdGhlIFJGQzM0MTEgQVNJcy4KICA8L3Byb3Bvc2FsPgoKClNlY3Rpb24gMy4y LjQsIHBhcmFncmFwaHMgMiYzCiAgVGhlIGZpcnN0IHNlbnRlbmNlIG9mIHBhcmFncmFwaCAyIGlz IGluY29uc2lzdGVudCBpbiBpdHMgdXNlIG9mIHRlbnNlLgpUaGUgcmVzdCBvZiB0aGUgcGFyYWdy YXBoIHNlZW1zIHRvIGJlIHRhbGtpbmcgYWJvdXQgdGhlIG1vZHVsYXIgbmF0dXJlCm9mIHRoZSBh Y2Nlc3MgY29udHJvbCBmcmFtZXdvcmssIGJ1dCBkb2Vzbid0IGFjdHVhbGx5IHNheSBzby4gIEl0 J3Mgbm90CmltbWVkaWF0ZWx5IGNsZWFyIGhvdyB0aGlzIHJlbGF0ZXMgdG8gdGhlIGNvbmNlcHQg b2YgYXV0aGVudGljYXRpb24gdnMKYXV0aG9yaXphdGlvbiAoYW5kIHRoZSBzZXBhcmF0aW9uIGJl dHdlZW4gdGhlbSkuCgogIDxwcm9wb3NhbD4KICAgVGhpcyBzZXBhcmF0aW9uIHdhcyBhIGRlbGli ZXJhdGUgZGVjaXNpb24gb2YgdGhlIFNOTVB2MyBXRywgdG8gYWxsb3cKICAgc3VwcG9ydCBmb3Ig YXV0aGVudGljYXRpb24gcHJvdG9jb2xzIHdoaWNoIGRvIG5vdCBwcm92aWRlIGRhdGEgYWNjZXNz CiAgIGF1dGhvcml6YXRpb24gY2FwYWJpbGl0aWVzLCBhbmQgdG8gc3VwcG9ydCBkYXRhIGFjY2Vz cyBhdXRob3JpemF0aW9uCiAgIHNjaGVtZXMsIHN1Y2ggYXMgVkFDTSwgdGhhdCBkbyBub3QgcGVy Zm9ybSB0aGVpciBvd24gYXV0aGVudGljYXRpb24uCgogICBBIE1lc3NhZ2UgUHJvY2Vzc2luZyBN b2RlbCBkZXRlcm1pbmVzIHdoaWNoIFNlY3VyaXR5IE1vZGVsIGlzIHVzZWQsCiAgIGVpdGhlciBi YXNlZCBvbiB0aGUgbWVzc2FnZSB2ZXJzaW9uIChlLmcuIFNOTVB2MSBhbmQgU05NUHYyYyksIG9y CiAgIHBvc3NpYmx5IGJ5IGEgdmFsdWUgc3BlY2lmaWVkIGluIHRoZSBtZXNzYWdlIChlLmcuIG1z Z1NlY3VyaXR5TW9kZWwKICAgZmllbGQgaW4gU05NUHYzKS4KICA8L3Byb3Bvc2FsPgoKClNlY3Rp b24gMy4yLjQsIHBhcmFncmFwaHMgNiY3CiAgTW9yZSBnZW5lcmFsbHksIHRoZSBmaXJzdCBmaXZl IHBhcmFncmFwaHMgb2YgdGhpcyBzZWN0aW9uIHNlZW0gdG8KYmUgc3VtbWFyaXNpbmcgdGhlIG92 ZXJhbGwgc2VjdXJpdHktcmVsYXRlZCBhc3BlY3RzIG9mIHRoZSBSRkMzNDExCmFyY2hpdGVjdHVy ZSwgd2l0aCBwYXJhZ3JhcGhzIHNpeCBhbmQgc2V2ZW4gZGlzdXNzaW5nIHRoZSBpbXBsaWNhdGlv bnMKZm9yIHRoZSBUcmFuc3BvcnQgTW9kZWwgc3Vic3lzdGVtLiAgSG93ZXZlciB0aGVzZSBsYXR0 ZXIgY29uY2VudHJhdGVzCm9uIHRoZSBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgTWVzc2FnZSBQcm9j ZXNzaW5nIGFuZCBTZWN1cml0eSBzdWJzeXN0ZW1zCih3aGljaCBoYXZlIGFscmVhZHkgYmVlbiBj b3ZlcmVkKSwgYW5kIGRvZXMgbm90IHJlYWxseSBhZGRyZXNzIGludGVyYWN0aW9uCndpdGggdGhl IEFjY2VzcyBDb250cm9sIHN1YnN5c3RlbS4gIFByZXN1bWFibHkgYmVjYXVzZSB0aGVyZSBpc24n dCBhbnksCmdpdmVuIHRoZSBzZXBhcmF0aW9uIGJldHdlZW4gQXV0aGVudGljYXRpb24gYW5kIEF1 dGhvcml6YXRpb24hCgogIFRoZSBvYnZpb3VzIHRoaW5nIHRvIGNvdmVyIGhlcmUgd291bGQgYmUg YSBzdW1tYXJ5IG9mIHRoZSByZWNlbnQKZGlzY3Vzc2lvbiByZWdhcmRpbmcgdHJhbnNwb3J0LWlu ZGVwZW5kZW50IHZzIHRyYW5zcG9ydC1kZXBlbmRlbnQKc2VjdXJpdHlOYW1lIG1hcHBpbmdzLCBh cyBwYXNzZWQgZnJvbSB0aGUgU2VjdXJpdHkgc3Vic3lzdGVtIHVwIHRvIHRoZQpBY2Nlc3MgQ29u dHJvbCBhbmQgQXBwbGljYXRpb24gc3Vic3lzdGVtcy4gIFRoZSBwcm9wb3NlZCBwcmVmaXgtYmFz ZWQKbWFwcGluZyB3b3VsZCBtb3JlIHNlbnNpYmx5IGJlIGNvdmVyZWQgaW4gdGhlIFRTTSBkb2N1 bWVudCwgYnV0IHRoaXMKc2VjdGlvbiBjb3VsZCBhdCBsZWFzdCBwcmVwYXJlIHRoZSBncm91bmQg Zm9yIHRoYXQgbWVjaGFuaXNtLgoKICA8cHJvcG9zYWw+CiAgICAgQSBUcmFuc3BvcnQgTW9kZWwg ZG9lcyBub3Qga25vdyB3aGF0IFNlY3VyaXR5IE1vZGVsIHdpbGwgYmUgdXNlZAogICBmb3IgYW4g aW5jb21pbmcgbWVzc2FnZSwgc28gY2Fubm90IGtub3cgaG93IHRoZSBzZWN1cml0eU5hbWUgYW5k CiAgIHNlY3VyaXR5TGV2ZWwgcGFyYW1ldGVycyB3aWxsIGJlIGRldGVybWluZWQuICBJdCBjYW4g cHJvcG9zZSBhbgogICBhdXRoZW50aWNhdGVkIGlkZW50aXR5ICh2aWEgdGhlIHRtU2VjdXJpdHlO YW1lIGZpZWxkKSwgYnV0IHRoZXJlCiAgIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoaXMgdmFsdWUg d2lsbCBiZSB1c2VkIGJ5IHRoZSBTZWN1cml0eSBNb2RlbC4KICAgRm9yIGV4YW1wbGUsIG5vbi10 cmFuc3BvcnQtYXdhcmUgU2VjdXJpdHkgTW9kZWxzIHdpbGwgdHlwaWNhbGx5CiAgIGRldGVybWlu ZSB0aGUgc2VjdXJpdHlOYW1lIChhbmQgc2VjdXJpdHlMZXZlbCkgYmFzZWQgb24gdGhlIGNvbnRl bnRzCiAgIG9mIHRoZSBTTk1QIG1lc3NhZ2UgaXRzZWxmLiAgU3VjaCBTZWN1cml0eSBNb2RlbHMg d2lsbCBzaW1wbHkgbm90CiAgIGtub3cgdGhhdCB0aGUgdG1TdGF0ZVJlZmVyZW5jZSBjYWNoZSBl eGlzdHMuCgogICBGdXJ0aGVyLCBldmVuIGlmIHRoZSBUcmFuc3BvcnQgTW9kZWwgY2FuIGluZmx1 ZW5jZSB0aGUgY2hvaWNlIG9mCiAgIHNlY3VyaXR5TmFtZSwgaXQgY2Fubm90IGRpcmVjdGx5IGRl dGVybWluZSB0aGUgYXV0aG9yaXphdGlvbiBhbGxvd2VkCiAgIHRvIHRoaXMgaWRlbnRpdHkuICBJ ZiB0d28gZGlmZmVyZW50IFRyYW5zcG9ydCBNb2RlbCBlYWNoIGF1dGhlbnRpY2F0ZQogICBhIHRy YW5zcG9ydCBwcmluY2lwYWwsIHRoYXQgYXJlIHRoZW4gYm90aCBtYXBwZWQgdG8gdGhlIHNhbWUK ICAgc2VjdXJpdHlOYW1lLCB0aGVuIHRoZXNlIHR3byBpZGVudGl0aWVzIHdpbGwgdHlwaWNhbGx5 IGJlIGFmZm9yZGVkCiAgIGV4YWN0bHkgdGhlIHNhbWUgYXV0aG9yaXphdGlvbiBieSB0aGUgQWNj ZXNzIENvbnRyb2wgTW9kZWwuCgogICBUaGUgb25seSB3YXkgZm9yIHRoZSBBY2Nlc3MgQ29udHJv bCBNb2RlbCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4KICAgaWRlbnRpdGllcyBiYXNlZCBvbiB0 aGUgdW5kZXJseWluZyBUcmFuc3BvcnQgTW9kZWwsIHdvdWxkIGJlIGZvcgogICBzdWNoIHRyYW5z cG9ydC1hdXRoZW50aWNhdGVkIGlkZW50aXRpZXMgdG8gYmUgbWFwcGVkIHRvIGRpc3RpbmN0CiAg IHNlY3VyaXR5TmFtZXMuICBIb3cgYW5kIGlmIHRoaXMgaXMgZG9uZSBpcyBTZWN1cml0eS1Nb2Rl bC1kZXBlbmRlbnQuCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMuMywgcGFyYWdyYXBoIDMKICBU aGlzIHRleHQsIGRpc2N1c3NpbmcgdGhlIHNlc3Npb24gc2VsZWN0aW9uLCBjb3ZlcnMgdmVyeSBz aW1pbGFyCm1hdGVyaWFsIHRvIHBhcmFncmFwaCAxICYgNSBvZiBzZWN0aW9uIDMuMy4xLCBhbmQg cGFyYWdyYXBoIDIgb2YKc2VjdGlvbiAzLjMuMy4gIEl0IG1pZ2h0IGJlIHNlbnNpYmxlIHRvIG1l cmdlIHRoZXNlIGRlc2NyaXB0aW9ucywKcGVyaGFwcyBhcyBhIHNlcGFyYXRlIG5ldyBzdWJzZWN0 aW9uOgoKICA8cHJvcG9zYWw+CiAgICAgMy4zLjEuICBTZXNzaW9uIFNlbGVjdGlvbgoKICAgICBU aGUgYXJjaGl0ZWN0dXJlIGRlZmluZWQgaW4gW1JGQzM0MTFdIGRvZXMgbm90IGluY2x1ZGUgYSBz ZXNzaW9uCiAgIHNlbGVjdG9yIGluIHRoZSBBYnN0cmFjdCBTZXJ2aWNlIEludGVyZmFjZXMsIGFu ZCBub3IgZG8gdGhlIEFTSXMKICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGZvciB0aGUgVHJh bnNwb3J0IFN1YnN5c3RlbS4gIE5laXRoZXIKICAgZG9lcyB0aGUgVHJhbnNwb3J0IFN1YnN5c3Rl bSBoYXZlIGFjY2VzcyB0byB0aGUgcGR1VHlwZSwgc28gY2Fubm90CiAgIHNlbGVjdCBhIGdpdmVu IHNlc3Npb24gZm9yIHBhcnRpY3VsYXIgdHlwZXMgb2YgdHJhZmZpYy4gIEhvd2V2ZXIKICAgY2Vy dGFpbiBwYXJhbWV0ZXJzIG9mIHRoZXNlIEFTSXMgY2FuIGJlIHVzZWQgdG8gZ3VpZGUgdGhlIHNl bGVjdGlvbgogICBvZiB0aGUgYXBwcm9wcmlhdGUgc2Vzc2lvbiB0byB1c2UgZm9yIGEgZ2l2ZW4g cmVxdWVzdC4KCiAgIFRoZSB0cmFuc3BvcnREb21haW4gYW5kIHRyYW5zcG9ydEFkZHJlc3MgaWRl bnRpZnkgdGhlIHRyYW5zcG9ydAogICBjb25uZWN0aW9uIHRvIGEgcmVtb3RlIG5ldHdvcmsgbm9k ZS4gIEVsZW1lbnRzIG9mIHRoZSB0cmFuc3BvcnQKICAgYWRkcmVzcyAoc3VjaCBhcyB0aGUgcG9y dCBudW1iZXIpIGNhbiBiZSB1c2VkIHRvIHNlbGVjdCBkaWZmZXJlbnQKICAgc2Vzc2lvbnMgZm9y IHBhcnRpY3VsYXIgcmVxdWVzdCB0eXBlcy4gIEZvciBleGFtcGxlLCBVRFAgcG9ydHMKICAgMTYx IGFuZCAxNjIgaGF2ZSB0eXBpY2FsbHkgYmVlbiB1c2VkIHRvIHNlcGFyYXRlIFNOTVAgbm90aWZp Y2F0aW9ucwogICBmcm9tIG90aGVyIHJlcXVlc3QvcmVzcG9uc2UgdHJhZmZpYy4KCiAgIFRoZSBz ZWN1cml0eU5hbWUgaWRlbnRpZmllcyB3aGljaCBzZWN1cml0eSBwcmluY2lwYWwgdG8gY29tbXVu aWNhdGUKICAgd2l0aCBhdCB0aGUgcmVtb3RlIG5ldHdvcmsgbm9kZSAoZS5nLiwgZGlmZmVyZW50 IE5NUyBhcHBsaWNhdGlvbnMKICAgcnVubmluZyBvbiB0aGUgc2FtZSBzeXN0ZW0pLiAgVGhlIHNl Y3VyaXR5TGV2ZWwgY291bGQgYmUgdXNlZCB0bwogICBzZWxlY3Qgc2Vzc2lvbnMgd2l0aCBkaWZm ZXJlbnQgc2V0cyBvZiBzZWN1cml0eSBwcm9wZXJ0aWVzIGZvcgogICBkaWZmZXJlbnQgcHVycG9z ZXMgKGUuZy4sIGVuY3J5cHRlZCBTRVRzIHZzLiAgbm9uLWVuY3J5cHRlZCBHRVRzKS4KICAgTm90 ZSB0aGF0IHRoaXMgcmVtYWlucyB0cnVlIGV2ZW4gaWYgYWxsIHRoZSBzZXNzaW9ucyBhY3R1YWxs eSBwcm92aWRlCiAgIHRoZSBzYW1lIGxldmVsIG9mIHNlY3VyaXR5IHByb3RlY3Rpb24uCgogICBJ biBzdW1tYXJ5LCBhIHVuaXF1ZSBjb21iaW5hdGlvbiBvZiB0cmFuc3BvcnREb21haW4sIHRyYW5z cG9ydEFkZHJlc3MsCiAgIHNlY3VyaXR5TmFtZSwgYW5kIHNlY3VyaXR5TGV2ZWwgd291bGQgc2Vy dmUgdG8gaWRlbnRpZnkgYSBnaXZlbiBzZXNzaW9uLgogICBEaWZmZXJlbnQgdmFsdWVzIGZvciBh bnkgb2YgdGhlc2UgcGFyYW1ldGVycyB3b3VsZCBpbXBseSB0aGUgdXNlIG9mCiAgIGEgZGlmZmVy ZW50IHNlc3Npb24uICBBbiBpbW1lZGlhdGUgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0CiAg IGltcGxlbWVudGF0aW9ucyBTSE9VTEQgYmUgYWJsZSB0byBtYWludGFpbiBzb21lIHJlYXNvbmFi bGUgbnVtYmVyIG9mCiAgIGNvbmN1cnJlbnQgc2Vzc2lvbnMuCgogICBJbXBsZW1lbnRlcnMsIG9m IGNvdXJzZSwgbWlnaHQgcHJvdmlkZSBub24tc3RhbmRhcmQgbWVjaGFuaXNtcyB0bwogICBzZWxl Y3Qgc2Vzc2lvbnMuCiAgPC9wcm9wb3NhbD4KICAgCk5vdGUoMSk6ICBUaGUgcGFyYWdyYXBoIHN0 YXJ0aW5nICJUbyByZWR1Y2UgcmVkdW5kYW5jeS4uLiIgd291bGQgcmVtYWluCiAgYXMgcGFydCBv ZiBzZWN0aW9uIDMuMy4KCk5vdGUoMik6ICBUaGUgc2VjdXJpdHlOYW1lIGFuZCBzZWN1cml0eUxl dmVsIGFyZSBub3QgZXhwbGljaXRseSBpbmNsdWRlZAogIGluIHRoZSBzZW5kTWVzc2FnZSBhbmQg cmVjZWl2ZU1lc3NhZ2UgQVNJcy4gIFRoZXNlIHR3byB2YWx1ZXMgd291bGQKICB0aGVyZWZvcmUg bmVlZCB0byBiZSBpbmNsdWRlZCB3aXRoaW4gdGhlIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUsIGlu CiAgb3JkZXIgdG8gc3VwcG9ydCBzZXNzaW9uIHNlbGVjdGlvbi4gIFRoZSBjdXJyZW50IHRleHQg ZGVzY3JpYmluZwogIHRtU3RhdGVSZWZlcmVuY2UgZG9lcyBub3QgbWFrZSB0aGlzIGV4cGxpY2l0 LgogICAgVGhpcyBpcyBhZGRyZXNzZWQgYnkgdGhlIHByb3Bvc2VkIHN0YW5kYXJkIHRleHQgZm9y IHRtU3RhdGVSZWZlcmVuY2UsCiAgY29tbW9uIHRvIGFsbCB0aHJlZSBkb2N1bWVudHMuCgoKKGN1 cnJlbnQpIFNlY3Rpb24gMy4zLjEKICBUaGlzIHdvdWxkIG5lZWQgdG8gYmUgcmVudW1iZXJlZCAo YWxvbmcgd2l0aCB0aGUgZm9sbG93aW5nIHN1YnNlY3Rpb25zKSwKYW5kIHRoZSBzZWxlY3Rpb24g YXNwZWN0cyByZW1vdmVkOgoKICA8cHJvcG9zYWw+CiAgICAgMy4zLjIuICBTZXNzaW9uIEVzdGFi bGlzaG1lbnQgUmVxdWlyZW1lbnRzCgogICAgIEFzIGluZGljYXRlZCBhYm92ZSwgU05NUCBzdWJz eXN0ZW1zIChpbmNsdWRpbmcgU05NUCBhcHBsaWNhdGlvbnMpCiAgIGNhbiBzcGVjaWZ5IGEgcGFy dGljdWxhciB0cmFuc3BvcnQgc2Vzc2lvbiBieSBwYXNzaW5nIGEgdW5pcXVlCiAgIGNvbWJpbmF0 aW9uIG9mIHRyYW5zcG9ydERvbWFpbiwgdHJhbnNwb3J0QWRkcmVzcywgc2VjdXJpdHlOYW1lLAog ICBhbmQgc2VjdXJpdHlMZXZlbC4gIElmIHRoaXMgY29tYmluYXRpb24gZG9lcyBub3QgbWF0Y2gg YW4gZXhpc3RpbmcKICAgdHJhbnNwb3J0IHNlc3Npb24sIHRoaXMgd2lsbCByZXF1ZXN0IHRoZSBU cmFuc3BvcnQgU3Vic3lzdGVtIHRvCiAgIGVzdGFibGlzaCBhIG5ldyBzZXNzaW9uLgoKICAgSWYg dGhlIFRyYW5zcG9ydCBNb2RlbCBjYW5ub3QgcHJvdmlkZSBhdCBsZWFzdCB0aGUgcmVxdWVzdGVk IGxldmVsCiAgIG9mIHNlY3VyaXR5LCB0aGUgVHJhbnNwb3J0IE1vZGVsIFNIT1VMRCBkaXNjYXJk IHRoZSBtZXNzYWdlIGFuZAogICBub3RpZnkgdGhlIGRpc3BhdGNoZXIgdGhhdCBlc3RhYmxpc2hp bmcgYSBzZXNzaW9uIGFuZCBzZW5kaW5nIHRoZQogICBtZXNzYWdlIGZhaWxlZC4gIFNpbWlsYXJs eSwgaWYgdGhlIHNlc3Npb24gY2Fubm90IGJlIGVzdGFibGlzaGVkLAogICB0aGVuIHRoZSBtZXNz YWdlIHNob3VsZCBiZSBkaXNjYXJkZWQgYW5kIHRoZSBkaXNwYXRjaGVyIG5vdGlmaWVkLgoKICAg VHJhbnNwb3J0IHNlc3Npb24gZXN0YWJsaXNobWVudCBtaWdodCByZXF1aXJlIHByb3Zpc2lvbmlu ZwogICBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBhdCBhbiBlbmdpbmUsIGVpdGhlciBzdGF0 aWNhbGx5IG9yCiAgIGR5bmFtaWNhbGx5LiAgSG93IHRoaXMgaXMgZG9uZSBpcyBkZXBlbmRlbnQg b24gdGhlIHRyYW5zcG9ydCBtb2RlbAogICBhbmQgdGhlIGltcGxlbWVudGF0aW9uLgogIDwvcHJv cG9zYWw+CgoKKGN1cnJlbnQpIFNlY3Rpb24gMy4zLjMKICAgVGhlIG9yZGVyIGluIHdoaWNoIG1h dGVyaWFsIGlzIGNvdmVyZWQgaW4gdGhlIHNlY29uZCBoYWxmIG9mIHRoZQpmaXJzdCBwYXJhZ3Jh cGggaXMgc29tZXdoYXQgcmFuZG9tLiAgSXQgd291bGQgYmUgY2xlYXJlciBpZiBlYWNoIGNvbmNl cHQKd2FzIGhhbmRsZWQgaW5kaXZpZHVhbGx5LiAgVGhlIHNlY29uZCBwYXJhZ3JhcGggb2YgU2Vj dGlvbiA1LjIgYWxzbwpkaXNjdXNzZXMgY3Jvc3Mtc2Vzc2lvbiBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucywgYW5kIHdvdWxkIHByb2JhYmx5CmZpdCBiZXR0ZXIgYXMgcGFydCBvZiB0aGlzIGRlc2Ny aXB0aW9uLgoKICBUaGUgc2Vjb25kIGFuZCB0aGlyZCBwYXJhZ3JhcGhzIGFyZSBlZmZlY3RpdmVs eSBjb3ZlcmVkIGluIHRoZSAobmV3KQpzdWJzZWN0aW9uIDMuMy4xLCBhbmQgZG9uJ3QgbmVlZCB0 byBiZSByZXBlYXRlZCBoZXJlLgoKICBUaGUganVzdGlmaWNhdGlvbiBvZiB3aHkgbXVsdGlwbGUg bGV2ZWxzIG9mIHNlY3VyaXR5IGFyZSBhdmFpbGFibGUgCihpbiBwYXJhZ3JhcGhzIDQmNSkgaXMg bm90IHJlYWxseSByZWxldmFudCB0byBhIGRpc2N1c3Npb24gb2YgbWVzc2FnZQp2cyBzZXNzaW9u IHNlY3VyaXR5LCBhbmQgc2VydmVzIHRvIG9ic2N1cmUgdGhlIG1haW4gcG9pbnQgYmVpbmcgbWFk ZS4KCiAgPHByb3Bvc2FsPgogICAgIC4uLiBTSE9VTEQgZW5zdXJlIHRoYXQgZnJlc2ggbmV3IHNl c3Npb24ga2V5cyBhcmUgZ2VuZXJhdGVkIGZvcgogICBlYWNoIHNlc3Npb24uICBUaGlzIHdvdWxk IGVuc3VyZSB0aGF0IGEgY3Jvc3Mtc2Vzc2lvbiByZXBsYXkgYXR0YWNrCiAgIHdvdWxkIGJlIHVu c3VjY2Vzc2Z1bDsgdGhhdCBpcywgYW4gYXR0YWNrZXIgY291bGQgbm90IHRha2UgYSBtZXNzYWdl CiAgIG9ic2VydmVkIG9uIG9uZSBzZXNzaW9uLCBhbmQgc3VjZXNzZnVsbHkgcmVwbGF5IHRoaXMg b24gYW5vdGhlcgogICBzZXNzaW9uLgoKICAgQSBnb29kIHNlY3VyaXR5IHByb3RvY29sIHdvdWxk IGFsc28gcHJvdGVjdCBhZ2FpbnN0IHJlcGxheSBhdHRhY2tzCiAgIF93aXRoaW5fIGEgc2Vzc2lv bjsgdGhhdCBpcywgYW4gYXR0YWNrZXIgY291bGQgbm90IHRha2UgYSBtZXNzYWdlCiAgIG9ic2Vy dmVkIG9uIGEgc2Vzc2lvbiwgYW5kIHN1Y2Nlc3NmdWxseSByZXBsYXkgdGhpcyBsYXRlciBpbiB0 aGUKICAgc2FtZSBzZXNzaW9uLiAgIE9uZSBhcHByb2FjaCB3b3VsZCBiZSB0byB1c2Ugc2VxdWVu Y2UgaW5mb3JtYXRpb24KICAgd2l0aGluIHRoZSBwcm90b2NvbCwgYWxsb3dpbmcgdGhlIHBhcnRp Y2lwYW50cyB0byBkZXRlY3QgaWYgbWVzc2FnZXMKICAgd2VyZSByZXBsYXllZCBvciByZW9yZGVy ZWQgd2l0aGluIGEgc2Vzc2lvbi4KCiAgIE5vdGUgdGhhdCBpZiBhIHNlY3VyZSB0cmFuc3BvcnQg c2Vzc2lvbiBpcyBjbG9zZWQgYmV0d2VlbiB0aGUgdGltZQogICBhIHJlcXVlc3QgbWVzc2FnZSBp cyByZWNlaXZlZCwgYW5kIHRoZSBjb3JyZXNwb25kaW5nIHJlc3BvbnNlIG1lc3NhZ2UKICAgaXMg c2VudCwgdGhlbiB0aGUgcmVzcG9uc2UgbWVzc2FnZSBTSE9VTEQgYmUgZGlzY2FyZGVkLCBldmVu IGlmIGEKICAgbmV3IHNlc3Npb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQuICBUaGUgU05NUHYzIFdH IGRlY2lkZWQgdGhhdCB0aGlzCiAgIHNob3VsZCBiZSBhIFNIT1VMRCBhcmNoaXRlY3R1cmFsbHks IGFuZCBpdCBpcyBhIHNlY3VyaXR5LW1vZGVsLXNwZWNpZmljCiAgIGRlY2lzaW9uIHdoZXRoZXIg dG8gUkVRVUlSRSB0aGlzLgoKICAgU05NUHYzIHdhcyBkZXNpZ25lZCB0byBzdXBwb3J0IG11bHRp cGxlIGxldmVscyBvZiBzZWN1cml0eSwKICAgc2VsZWN0YWJsZSBvbiBhIHBlci1tZXNzYWdlIGJh c2lzIGJ5IGFuIFNOTVAgYXBwbGljYXRpb24uICBTb21lCiAgIFRyYW5zcG9ydCBNb2RlbHMgbWln aHQgc3VwcG9ydCAuLi4KCiAgICAgIHMvcmVxdWVzdGVkIHNlY3VyaXR5IGxldmVsLwogICAgICAg IHNlY3VyaXR5IGxldmVsIHJlcXVlc3RlZCBieSBhIHRyYW5zcG9ydC1hd2FyZSBTZWN1cml0eSBN b2RlbC8KICAgICAgICAgICAgICAgKGZpbmFsIHNlbnRlbmNlKQogIDwvcHJvcG9zYWw+CgoKU2Vj dGlvbiA0LCBwYXJhZ3JhcGggMgoKICA8cHJvcG9zYWw+CiAgICAgcy8gcmVnYXJkbGVzcyBvZiBw ZHVUeXBlLC8vICAgICAoZmlyc3QgdGltZSBvbmx5KQogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiA1 CiAgVGhpcyB3aG9sZSBkZXNjcmlwdGlvbiBzaG91bGQgcHJvYmFibHkgYmUgcmVwbGFjZWQgYnkg dGhlIHN0YW5kYXJkCnRleHQgcHJvcG9zZWQgZm9yIHRoZSBDYWNoZWQgSW5mb3JtYXRpb24gYW5k IFJlZmVyZW5jZXMgc2VjdGlvbi4KClRoZSB0ZXh0IHN0YXJ0aW5nICJUaGlzIGRvY3VtZW50IGRv ZXMgbm90IHNwZWNpZnkgYW4gaW1wbGVtZW50YXRpb24Kc3RyYXRlZ3kuLi4iICAocGFyYWdyYXBo IDQgb2YgdGhlIGN1cnJlbnQgdGV4dCksIGNvdWxkIHByb2JhYmx5IGJlCmFwcGVuZGVkIHRvIHRo ZSB0aGlyZCBwYXJhZ3JhcGggb2YgdGhlIHN0YW5kYXJkIGRlc2NyaXB0aW9uLgoKClNlY3Rpb24g NgogICBUaGlzIHNlY3Rpb24gZmVlbHMgYXMgaWYgaXQgd291bGQgYmVuZWZpdCBmcm9tIGEgYnJp ZWYgZGVzY3JpcHRpb24Kb2YgaG93IGl0IHJlbGF0ZXMgdG8gdGhlIEFTSXMgZGVmaW5lZCBpbiBS RkMzNDExLgoKICA8cHJvcG9zYWwgbG9jYXRpb249bmV3X3BhcmFfMj4KICAgICBUaGlzIGRvY3Vt ZW50IGludHJvZHVjZXMgYSBjb3VwbGUgb2YgbmV3IEFTSXMgdG8gZGVmaW5lIHRoZSBpbnRlcmZh Y2UKICAgYmV0d2VlbiB0aGUgVHJhbnNwb3J0IGFuZCBEaXNwYXRjaGVyIFN1YnN5c3RlbXMsICBh bmQgZXh0ZW5kcyBzb21lIG9mCiAgIHRoZSBBU0lzIGRlZmluZWQgaW4gUkZDMzQxMSB0byBpbmNs dWRlIHRyYW5zcG9ydC1yZWxhdGVkIGluZm9ybWF0aW9uLgogIDwvcHJvcG9zYWw+CgoKU2VjdGlv biA2LCBwYXJhZ3JhcGggNAogICBUaGUgZGVzY3JpcHRpb24gb2Ygd2hhdCBpcyBpbmNsdWRlZCBp biBhbiBlcnJvckluZGljYXRpb24gaXMgbm90CmVudGlyZWx5IGNvbnNpc3RlbnQgd2l0aCB0aGUg dXNhZ2UgaW4gb3RoZXIgU05NUHYzIGRvY3VtZW50cy4KCiAgPHByb3Bvc2FsPgogICAgIEFuIGVy cm9yIGluZGljYXRpb24gaW4gc3RhdHVzSW5mb3JtYXRpb24gd2lsbCB0eXBpY2FsbHkgaW5jbHVk ZSB0aGUKICAgT0lEIGFuZCB2YWx1ZSBmb3IgYW4gaW5jcmVtZW50ZWQgZXJyb3IgY291bnRlci4g IFRoaXMgbWF5IGJlIGFjY29tcGFuaWVkCiAgIGJ5IHZhbHVlcyBmb3IgY29udGV4dEVuZ2luZUlE IGFuZCBjb250ZXh0TmFtZSBmb3IgdGhpcyBjb3VudGVyLCBhIHZhbHVlCiAgIGZvciBzZWN1cml0 eUxldmVsLCBhbmQgdGhlIGFwcHJvcHJpYXRlIHN0YXRlIHJlZmVyZW5jZSBpZiB0aGUgaW5mb3Jt YXRpb24KICAgaXMgYXZhaWxhYmxlIGF0IHRoZSBwb2ludCB3aGVyZSB0aGUgZXJyb3IgaXMgZGV0 ZWN0ZWQuCiAgPC9wcm9wb3NhbD4KCk5vdGUgdGhhdCB3aGljaCBzdGF0ZSByZWZlcmVuY2UgaXMg cmV0dXJuZWQgd2lsbCBkZXBlbmQgb24gdGhlIEFTSSBjb25jZXJuZWQuCnNlY3VyaXR5U3RhdGVS ZWZlcmVuY2UgaXMgb25seSByZWxldmFudCB0byB0aGUgU2VjdXJpdHkgc3Vic3lzdGVtIEFTSXMu CgoKU2VjdGlvbiA2LjIKICAgSXQgd291bGQgYmUgdXNlZnVsIHRvIHR3ZWFrIHRoZSB0aXRsZSBv ZiB0aGlzIHN1YnNlY3Rpb24sIHRvIGVtcGhhc2lzZSB0aGF0CnRoaXMgaW52b2x2ZXMgY2hhbmdl cyB0byB0aGUgQVNJcyBhcyBkZWZpbmVkIGluIFJGQzM0MTEuICBJdCB3b3VsZCBwcm9iYWJseQph bHNvIGJlIHVzZWZ1bCB0byByZWZsZWN0IHRoZSBzZWN0aW9uIHN0cnVjdHVyZSBvZiB0aGUgUkZD MzQxMSBkZXNjcmlwdGlvbnMKKHRvIGluZGljYXRlIHdoaWNoIHN1YnN5c3RlbXMgYXJlIGFmZmVj dGVkKSwgYW5kIHRvIGNvdmVyIGFsbCBvZiB0aGUgYW1lbmRlZCBBU0lzOgoKICA8cHJvcG9zYWw+ CiAgICAgNi4yLiAgIENoYW5nZXMgdG8gUkZDMzQxMSBPdXRnb2luZyBBU0lzCgogICAgIEFkZGl0 aW9uYWwgcGFyYW1ldGVycyBoYXZlIGJlZW4gYWRkZWQgdG8gdGhlIEFTSXMgZGVmaW5lZCBpbiBS RkMzNDExLAogICBjb25jZXJuZWQgd2l0aCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIERpc3Bh dGNoZXIgYW5kIE1lc3NhZ2UgUHJvY2Vzc2luZwogICBzdWJzeXN0ZW1zLCBhbmQgYmV0d2VlbiB0 aGUgTWVzc2FnZSBQcm9jZXNzaW5nIGFuZCBTZWN1cml0eSBTdWJzeXN0ZW1zLgoKICAgICA2LjIu MS4gIE1lc3NhZ2UgUHJvY2Vzc2luZyBTdWJzeXN0ZW0gUHJpbWF0aXZlcwoKICAgICBBIHRtU3Rh dGVSZWZlcmVuY2UgcGFyYW1ldGVyIGhhcyBiZWVuIGFkZGVkIGFzIGFuIE9VVCBwYXJhbWV0ZXIg dG8KICAgdGhlIHByZXBhcmVPdXRnb2luZ01lc3NhZ2UgYW5kIHByZXBhcmVSZXNwb25zZU1lc3Nh Z2UgQVNJcy4gVGhpcyBpcwogICBwYXNzZWQgZnJvbSBNZXNzYWdlIFByb2Nlc3NpbmcgU3Vic3lz dGVtIHRvIHRoZSBkaXNwYXRjaGVyLCBhbmQgZnJvbQogICB0aGVyZSB0byB0aGUgVHJhbnNwb3J0 IFN1YnN5c3RlbS4KCiAgIHN0YXR1c0luZm9ybWF0aW9uID0KICAgcHJlcGFyZU91dGdvaW5nTWVz c2FnZSgKICAgICAgIDoKICAgICBPVVQgIHRtU3RhdGVSZWZlcmVuY2UgICAgICAgIC0tIChORVcp IHJlZmVyZW5jZSB0byB0cmFuc3BvcnQgc3RhdGUKICAgKQoKICAgc3RhdHVzSW5mb3JtYXRpb24g PQogICBwcmVwYXJlUmVzcG9uc2VNZXNzYWdlKAogICAgICAgOgogICAgIE9VVCAgdG1TdGF0ZVJl ZmVyZW5jZSAgICAgICAgLS0gKE5FVykgcmVmZXJlbmNlIHRvIHRyYW5zcG9ydCBzdGF0ZQogICAp CgogICAgSG93IG9yIGlmIHRoZSBNZXNzYWdlIFByb2Nlc3NpbmcgU3Vic3lzdGVtIG1vZGlmaWVz IG9yIHV0aWxpdGl6ZXMKICB0aGUgY29udGVudHMgb2YgdGhpcyBjYWNoZSBpcyBtZXNzYWdlLXBy b2Nlc3NpbmctbW9kZWwgc3BlY2lmaWMuCgogICAgIDYuMi4yLiAgU2VjdXJpdHkgU3Vic3lzdGVt IFByaW1hdGl2ZXMKCiAgICAgdHJhbnNwb3J0RG9tYWluIGFuZCB0cmFuc3BvcnRBZGRyZXNzIHBh cmFtZXRlcnMgaGF2ZSBiZWVuIGFkZGVkIGFzIElOCiAgIHBhcmFtZXRlcnMgdG8gdGhlIGdlbmVy YXRlT3V0Z29pbmdNZXNzYWdlIGFuZCBnZW5lcmF0ZVJlc3BvbnNlTWVzc2FnZQogICBBU0lzLCBh bmQgYSB0bVN0YXRlUmVmZXJlbmNlIHBhcmFtZXRlciBoYXMgYmVlbiBhZGRlZCBhcyBhbiBPVVQg cGFyYW1ldGVyLgogICBUaGUgdHJhbnNwb3J0RG9tYWluIGFuZCB0cmFuc3BvcnRBZGRyZXNzIHBh cmFtZXRlcnMgd2lsbCBoYXZlIGJlZW4gcGFzc2VkCiAgIGludG8gdGhlIE1lc3NhZ2UgUHJvY2Vz c2luZyBTdWJzeXN0ZW0gZnJvbSB0aGUgZGlzcGF0Y2hlciwgYW5kIGFyZSBwYXNzZWQKICAgb24g dG8gdGhlIFNlY3VyaXR5IFN1YnN5c3RlbS4gICBUaGUgdG1TdGF0ZVJlZmVyZW5jZSBwYXJhbWV0 ZXIgd2lsbCBiZQogICBwYXNzZWQgZnJvbSB0aGUgU2VjdXJpdHkgU3Vic3lzdGVtIGJhY2sgdG8g dGhlIE1lc3NhZ2UgUHJvY2Vzc2luZwogICBTdWJzeXN0ZW0sIGFuZCBvbiB0byB0aGUgZGlzcGF0 Y2hlciBhbmQgVHJhbnNwb3J0IHN1YnN5c3RlbXMuCgogICBzdGF0dXNJbmZvcm1hdGlvbiA9CiAg IGdlbmVyYXRlT3V0Z29pbmdNZXNzYWdlKAogICAgICAgOgogICAgIElOICAgdHJhbnNwb3J0RG9t YWluICAgICAgICAgLS0gKE5FVykgdHJhbnNwb3J0IERvbWFpbiBvZiByZXF1ZXN0IGRlc3RpbmF0 aW9uCiAgICAgSU4gICB0cmFuc3BvcnRBZGRyZXNzICAgICAgICAtLSAoTkVXKSB0cmFuc3BvcnQg QWRkcmVzcyBvZiByZXF1ZXN0IGRlc3RpbmF0aW9uCiAgICAgICA6CiAgICAgT1VUICB0bVN0YXRl UmVmZXJlbmNlICAgICAgICAtLSAoTkVXKSByZWZlcmVuY2UgdG8gdHJhbnNwb3J0IHN0YXRlCiAg ICkKCiAgIHN0YXR1c0luZm9ybWF0aW9uID0KICAgZ2VuZXJhdGVSZXNwb25zZU1lc3NhZ2UoCiAg ICAgICA6CiAgICAgSU4gICB0cmFuc3BvcnREb21haW4gICAgICAgICAtLSAoTkVXKSB0cmFuc3Bv cnQgRG9tYWluIG9mIHJlcXVlc3QgZGVzdGluYXRpb24KICAgICBJTiAgIHRyYW5zcG9ydEFkZHJl c3MgICAgICAgIC0tIChORVcpIHRyYW5zcG9ydCBBZGRyZXNzIG9mIHJlcXVlc3QgZGVzdGluYXRp b24KICAgICAgIDoKICAgICBPVVQgIHRtU3RhdGVSZWZlcmVuY2UgICAgICAgIC0tIChORVcpIHJl ZmVyZW5jZSB0byB0cmFuc3BvcnQgc3RhdGUKICAgKQoKICAgSWYgYSBjYWNoZSBleGlzdHMgZm9y IGEgc2Vzc2lvbiBpZGVudGlmaWFibGUgZnJvbSB0aGUgdHJhbnNwb3J0RG9tYWluLAogICB0cmFu c3BvcnRBZGRyZXNzLCB0bVNlY3VyaXR5TmFtZSBhbmQgcmVxdWVzdGVkIHNlY3VyaXR5TGV2ZWws IHRoZW4gYQogICB0cmFuc3BvcnQtYXdhcmUgU2VjdXJpdHkgTW9kZWwgbWlnaHQgY3JlYXRlIGEg dG1TdGF0ZVJlZmVyZW5jZSBwYXJhbWV0ZXIKICAgdG8gdGhpcyBjYWNoZSwgYW5kIHBhc3MgdGhh dCBhcyBhbiBPVVQgcGFyYW1ldGVyLgogIDwvcHJvcG9zYWw+CgpOb3RlIHRoYXQgc2VjdXJpdHlN b2RlbCBoYXMgYmVlbiBvbWl0dGVkIGZyb20gdGhpcyBmaW5hbCBwYXJhZ3JhcGgsIGluIGxpbmUK d2l0aCB0aGUgKGNvbW1vbikgZGVzY3JpcHRpb24gb2YgdGhlIHRtU3RhdGVSZWZlcmVuY2UgY2Fj aGUsIGFuZCB0aGUgZWxlbWVudHMKb2YgcHJvY2VkdXJlIGluIG90aGVyIElTTVMgZG9jdW1lbnRz LgoKClNlY3Rpb24gNi4zLCBwYXJhZ3JhcGggMQoKICA8cHJvcG9zYWw+CiAgICAgV2hlbiBhIG1l c3NhZ2UgaXMgcmVjZWl2ZWQgb24gYSBnaXZlbiB0cmFuc3BvcnQgc2Vzc2lvbiwgaWYgYSBjYWNo ZQogICBkb2VzIG5vdCBhbHJlYWR5IGV4aXN0IGZvciB0aGF0IHNlc3Npb24sIHRoZSBUcmFuc3Bv cnQgTW9kZWwgbWlnaHQKICAgY3JlYXRlIG9uZSwgcmVmZXJlbmNlZCBieSB0bVN0YXRlUmVmZXJl bmNlLiAgVGhlIGNvbnRlbnRzIG9mIHRoaXMKICAgY2FjaGUgYXJlIGRpc2N1c3NlZCBpbiBzZWN0 aW9uIDUuMi4gIEhvdyB0aGlzIGluZm9ybWF0aW9uIGlzIGRldGVybWluZWQKICAgaXMgaW1wbGVt ZW50YXRpb24tIGFuZCB0cmFuc3BvcnQtbW9kZWwtc3BlY2lmaWMuCiAgPC9wcm9wb3NhbD4KCgpT ZWN0aW9uIDYuNAogICBBcyB3aXRoIHNlY3Rpb24gNi40LCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g dHdlYWsgdGhlIHRpdGxlIG9mIHRoaXMKc3Vic2VjdGlvbiwgYW5kIHRvIHJlZmxlY3QgdGhlIHN0 cnVjdHVyZSBvZiBSRkMzNDExOgoKICA8cHJvcG9zYWw+CiAgICAgNi40LiAgIENoYW5nZXMgdG8g UkZDMzQxMSBJbmNvbWluZyBBU0lzCgogICAgIFRoZSB0bVN0YXRlUmVmZXJlbmNlIHBhcmFtZXRl ciBoYXMgYWxzbyBiZWVuIGFkZGVkIHRvIHNvbWUgb2YgdGhlCiAgIGluY29taW5nIEFTSXMgZGVm aW5lZCBpbiBSRkMzNDExLiAgSG93IG9yIGlmIGEgTWVzc2FnZSBQcm9jZXNzaW5nIE1vZGVsCiAg IG9yIFNlY3VyaXR5IE1vZGVsIHVzZXMgdG1TdGF0ZVJlZmVyZW5jZSBpcyBtZXNzYWdlLXByb2Nl c3NpbmctIGFuZAogICBzZWN1cml0eS1tb2RlbC1zcGVjaWZpYy4KCiAgICAgNi40LjEuICBNZXNz YWdlIFByb2Nlc3NpbmcgU3Vic3lzdGVtIFByaW1hdGl2ZQoKICAgICBBIHRtU3RhdGVSZWZlcmVu Y2UgcGFyYW1ldGVyIGhhcyBiZWVuIGFkZGVkIGFzIGFuIElOIHBhcmFtZXRlciB0bwogICB0aGUg cHJlcGFyZURhdGFFbGVtZW50cyBBU0kuICBUaGlzIGlzIHJlY2VpdmVkIGZyb20gdGhlIFRyYW5z cG9ydAogICBNb2RlbCBieSB0aGUgZGlzcGF0Y2hlciwgYW5kIHBhc3NlZCB0byB0aGUgTWVzc2Fn ZSBQcm9jZXNzaW5nIFN1YnN5c3RlbS4KCiAgIHN0YXR1c0luZm9ybWF0aW9uID0KICAgcHJlcGFy ZURhdGFFbGVtZW50cygKICAgICAgIDoKICAgICBJTiAgdG1TdGF0ZVJlZmVyZW5jZSAgICAgICAg LS0gKE5FVykgcmVmZXJlbmNlIHRvIHRyYW5zcG9ydCBzdGF0ZQogICAgICAgOgogICAgIE9VVCBz dGF0ZVJlZmVyZW5jZSAgICAgICAgICAtLSByZWZlcmVuY2UgdG8gc3RhdGUgaW5mb3JtYXRpb24K ICAgKQoKICAgIEhvdyBvciBpZiB0aGUgTWVzc2FnZSBQcm9jZXNzaW5nIFN1YnN5c3RlbSBtb2Rp ZmllcyBvciB1dGlsaXRpemVzCiAgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY2FjaGUgaXMgbWVzc2Fn ZS1wcm9jZXNzaW5nLW1vZGVsIHNwZWNpZmljLgoKICAgICA2LjQuMi4gIFNlY3VyaXR5IFN1YnN5 c3RlbSBQcmltYXRpdmUKCiAgICAgQSB0bVN0YXRlUmVmZXJlbmNlIHBhcmFtZXRlciBoYXMgYmVl biBhZGRlZCBhcyBhbiBJTiBwYXJhbWV0ZXIgdG8KICAgdGhlIHByb2Nlc3NJbmNvbWluZ01zZyBB U0ksIGFuZCBpcyBwYXNzZWQgZnJvbSB0aGUgTWVzc2FnZSBQcm9jZXNzaW5nCiAgIFN1YnN5c3Rl bSB0byB0aGUgU2VjdXJpdHkgU3Vic3l0ZW0uCiAgIE1vZGVsIGJ5IHRoZSBkaXNwYXRjaGVyLCBh bmQgcGFzc2VkIHRvIHRoZSBNZXNzYWdlIFByb2Nlc3NpbmcgU3Vic3lzdGVtLgoKICAgc3RhdHVz SW5mb3JtYXRpb24gPQogICBwcm9jZXNzSW5jb21pbmdNc2coCiAgICAgICA6CiAgICAgSU4gIHRt U3RhdGVSZWZlcmVuY2UgICAgICAgICAtLSAoTkVXKSByZWZlcmVuY2UgdG8gdHJhbnNwb3J0IHN0 YXRlCiAgICAgICA6CiAgICAgT1VUIHNlY3VyaXR5U3RhdGVSZWZlcmVuY2UgICAtLSByZWZlcmVu Y2UgdG8gc2VjdXJpdHkgc3RhdGUgaW5mb3JtYXRpb24KICAgKQoKICAgSWYgdG1TdGF0ZVJlZmVy ZW5jZSBpcyBwcmVzZW50IGFuZCB2YWxpZCwgYW4gYXBwcm9wcmlhdGUgU2VjdXJpdHkKICAgTW9k ZWwgbWlnaHQgdXRpbGl6ZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIGNhY2hlLiAgSG93IG9yIGlm IHRoZQogICBTZWN1cml0eSBTdWJzeXN0ZW0gdXRpbGl6ZXMgdGhlIGluZm9ybWF0aW9uIGluIHRo ZSBjYWNoZSBpcyBzZWN1cml0eS0KICAgbW9kZWwtc3BlY2lmaWMuCgogICBUaGlzIG1heSBzb3Vu ZCB1bmRlcnNwZWNpZmllZCwgLi4uLgogIDwvcHJvcG9zYWw+Cgo= ------=_Part_9_16883203.1218493522073 Content-Type: application/octet-stream; name=TSM-comments Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjrmzirp2 Content-Disposition: attachment; filename=TSM-comments U2VjdGlvbiAyCiAgVGhlIGZpcnN0IGhhbGYgb2YgcGFyYWdyYXBocyAyJjMgcmVmZXIgdG8gdGhl IGhhbmRsaW5nIG9mIGluY29taW5nCnJlcXVlc3RzLiAgSXQgd291bGQgcHJvYmFibHkgYmUgdXNl ZnVsIHRvIG1lcmdlIHRoZXNlIHR3byBkZXNjcmlwdGlvbnMKaW50byBvbmUuCiAgU2ltaWxhcmx5 IHdpdGggcGFyYWdyYXBoIDUgYW5kIHRoZSBzZWNvbmQgaGFsZiBvZiBwYXJhZ3JhcGggMi4KCiAg SXQncyBub3QgaW1tZWRpYXRlbHkgY2xlYXIgd2hhdCB0aGUgbGFzdCBjb3VwbGUgb2Ygc2VudGVu Y2VzIG9mCnBhcmFncmFwaCAzIGFyZSB0cnlpbmcgdG8gZXhwbGFpbiwgYW5kIHBhcnRpY3VsYXJs eSBob3cgdGhpcyBtaWdodApyZWxhdGUgdG8gdGhlIHRvcGljIG9mIHRoaXMgc2VjdGlvbi4KCiAg UGFyYWdyYXBoIDQgYXNzdW1lcyB0aGUgY3JlYXRpb24gb2YgYSBuZXcgdG1TdGF0ZVJlZmVyZW5j ZSBjYWNoZSwKYW5kIHNob3VsZCBhY2tub3dsZWRnZSB0aGUgcG9zc2liaWxpdHkgb2YgcmUtdXNp bmcgYW4gZXhpc3Rpbmcgb25lLgoKICA8cHJvcG9zYWw+CiAgIEZvciBpbmNvbWluZyByZXF1ZXN0 cywgYSBzZWN1cmUgVHJhbnNwb3J0IE1vZGVsIHdpbGwgY3JlYXRlCiAgIGEgdG1TdGF0ZVJlZmVy ZW5jZSBjYWNoZSAob3IgdXNlIGFuIGV4aXN0aW5nIG9uZSksIGluY2x1ZGluZwogICB0cmFuc3Bv cnREb21haW4sIHRyYW5zcG9ydEFkZHJlc3MsIHRtU2VjdXJpdHlOYW1lIGFuZAogICB0bVRyYW5z cG9ydFNlY3VyaXR5TGV2ZWwgdmFsdWVzLCBwb3NzaWJseSB0b2dldGhlciB3aXRoIG90aGVyCiAg IHRyYW5zcG9ydC0gc3BlY2lmaWMgaW5mb3JtYXRpb24uICBBIG5vbi1zZWN1cmUgVHJhbnNwb3J0 IE1vZGVsCiAgIHdpbGwgdHlwaWNhbGx5IG5vdCBjcmVhdGUgb3IgcG9wdWxhdGUgdGhpcyBjYWNo ZS4gIFRoZSBUcmFuc3BvcnQKICAgU2VjdXJpdHkgTW9kZWwgd2lsbCBkZXRlcm1pbmUgdGhlIHNl Y3VyaXR5LW1vZGVsLWluZGVwZW5kZW50CiAgIHNlY3VyaXR5TmFtZSBhbmQgc2VjdXJpdHlMZXZl bCwgYW5kIHZlcmlmeSB0aGF0IHRoZSB0cmFuc3BvcnQKICAgc2VjdXJpdHkgcHJvdmlzaW9uIGlz IHN1ZmZpY2llbnQgZm9yIHRoZSByZXF1ZXN0ZWQgbGV2ZWwgb2Ygc2VjdXJpdHkuCiAgIElmIHRo ZSBjYWNoZSBkb2VzIG5vdCBleGlzdCwgaXMgaW5jb21wbGV0ZWx5IHBvcHVsYXRlZCwgb3IgdGhl CiAgIHRtVHJhbnNwb3J0U2VjdXJpdHlMZXZlbCBwcm92aWRlZCBpcyB3ZWFrZXIgdGhhbiB0aGUg cmVxdWVzdGVkCiAgIHNlY3VyaXR5TGV2ZWwsIHRoZSBUcmFuc3BvcnQgU2VjdXJpdHkgTW9kZWwg d2lsbCByZXR1cm4gYW4gZXJyb3IKICAgKHNlZSBzZWN0aW9uIDUuMikuCgogICBGb3Igb3V0Z29p bmcgcmVxdWVzdHMsIHRoZSBUcmFuc3BvcnQgU2VjdXJpdHkgTW9kZWwgd2lsbCBjcmVhdGUKICAg YSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlIChvciB1c2UgYW4gZXhpc3Rpbmcgb25lKSwgY29udGFp bmluZwogICB0aGUgdHJhbnNwb3J0RG9tYWluLCB0cmFuc3BvcnRBZGRyZXNzLCB0bVNlY3VyaXR5 TmFtZSBhbmQKICAgdG1SZXF1ZXN0ZWRTZWN1cml0eUxldmVsIHZhbHVlcywgYW5kIHBhc3NlcyB0 aGUgdG1TdGF0ZVJlZmVyZW5jZQogICB0byB0aGUgc3BlY2lmaWVkIFRyYW5zcG9ydCBNb2RlbC4K ICAKICAgVG8gbWFpbnRhaW4gdGhlIFJGQzM0MTEgbW9kdWxhcml0eSwgdGhlIFRyYW5zcG9ydCBN b2RlbCBkb2VzIG5vdAogICBrbm93IHdoaWNoIFNlY3VyaXR5IE1vZGVsIHdpbGwgYmUgdXNlZCBm b3IgYW4gaW5jb21pbmcgbWVzc2FnZTsKICAgdGhpcyB3aWxsIGJlIGRldGVybWluZWQgYnkgdGhl IE1lc3NhZ2UgUHJvY2Vzc2luZyBNb2RlbC4gIEhlbmNlCiAgIGV2ZW4gaWYgdGhlIFRyYW5zcG9y dCBNb2RlbCBwb3B1bGF0ZXMgdGhlIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUsCiAgIGl0IGlzIHBv c3NpYmxlIHRoYXQgdGhlIHNlbGVjdGVkIFNlY3VyaXR5IE1vZGVsIHdpbGwgaWdub3JlIGl0cwog ICBjb250ZW50cy4gIEZvciBleGFtcGxlLCBib3RoIHRoZSBVU00gYW5kIGNvbW11bml0eS1iYXNl ZCBTZWN1cml0eQogICBNb2RlbHMgd2lsbCBkZXJpdmUgdGhlIHNlY3VyaXR5TmFtZSBmcm9tIHRo ZSBTTk1QIG1lc3NhZ2UgaXRzZWxmLAogICByYXRoZXIgdGhhbiB0aGUgdG1TZWN1cml0eU5hbWUg cHJvdmlkZWQgYnkgYSBzZWN1cmUgdHJhbnNwb3J0LgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiAy LjEuMS4KICAgQXQgZmlyc3Qgc2lnaHQsIHRoZXJlIGlzIGFuIGFwcGFyZW50IGluY29uc2lzdGVu Y3kgYmV0d2VlbiB0aGUKZmlyc3QgdHdvIHBhcmFncmFwaHMgLSBmaXJzdCB0aGUgVFNNIGNsYWlt cyB0byBwcm92aWRlIHByb3RlY3Rpb24sCmFuZCB0aGVuIGl0IGRvZXNuJ3QuICBBIGNsb3NlciBy ZWFkaW5nIGV4cGxhaW5zIHRoZSBkaWZmZXJlbmNlLCBidXQKYSByZXN0cnVjdHVyaW5nIG9mIHRo ZSB0ZXh0IG1pZ2h0IHByb3ZpZGUgYSBjbGVhcmVyIGV4cGxhbmF0aW9uOgoKICA8cHJvcG9zYWw+ CiAgICAgVGhlIFRyYW5zcG9ydCBTZWN1cml0eSBNb2RlbCBpcyBjYWxsZWQgYSBTZWN1cml0eSBN b2RlbCB0byBiZQogICBjb21wYXRpYmxlIHdpdGggdGhlIFJGQzM0MTEgYXJjaGl0ZWN0dXJlLiAg SG93ZXZlciBpdCBkb2VzIG5vdAogICBwcm92aWRlIHNlY3VyaXR5IG1lY2hhbmlzbXMgaXRzZWxm LCBzbyBTSE9VTEQgYWx3YXlzIGJlIHVzZWQKICAgd2l0aCBhIFRyYW5zcG9ydCBNb2RlbCB0aGF0 IHByb3ZpZGVzIGFwcHJvcHJpYXRlIHNlY3VyaXR5LgoKICAgSWYgdXNlZCB3aXRoIGEgc3VpdGFi bGUgVHJhbnNwb3J0IE1vZGVsLCB0aGVuIHRoZSBUcmFuc3BvcnQKICAgU2VjdXJpdHkgTW9kZWwg d2lsbCBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgdGhyZWF0cwogICBpZGVudGlmaWVk IGJ5IFJGQzM0MTEuICBIb3dldmVyIHRoZSByZXNwb25zaWJpbGl0eSBmb3IgcHJvdmlkaW5nCiAg IHRoaXMgcHJvdGVjdGlvbiBpcyBkZWxlZ2F0ZWQgdG8gdGhlIHNlY3VyZSBUcmFuc3BvcnQgTW9k ZWwuICBUaGUKICAgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsIGRvZXMgbm90IGFkZHJlc3MgYW55 IHRocmVhdHMgaXRzZWxmLgoKICAgSWYgdXNlZCB3aXRoIGEgbm9uLXNlY3VyZSBUcmFuc3BvcnQg TW9kZWwsIHRoZW4gdGhlIFRyYW5zcG9ydAogICBTZWN1cml0eSBNb2RlbCB3aWxsICpub3QqIHBy b3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IHN1Y2ggdGhyZWF0cy4KICA8L3Byb3Bvc2FsPgoKU2Vj dGlvbiAyLjIKCiAgPHByb3Bvc2FsPgogICAgIDIuMi4gIFRyYW5zcG9ydCBTZXNzaW9ucwoKICAg VGhlIFRyYW5zcG9ydCBTZWN1cml0eSBNb2RlbCBkb2VzIG5vdCB3b3JrIHdpdGggdHJhbnNwb3J0 IHNlc3Npb25zCiAgIGRpcmVjdGx5LiAgSW5zdGVhZCB0aGUgdHJhbnNwb3J0LXJlbGF0ZWQgc3Rh dGUgaXMgYXNzb2NpYXRlZCB3aXRoCiAgIGEgdW5pcXVlIGNvbWJpbmF0aW9uIG9mIHRyYW5zcG9y dERvbWFpbiwgdHJhbnNwb3J0QWRkcmVzcywgc2VjdXJpdHlOYW1lCiAgIGFuZCBzZWN1cml0eUxl dmVsLCBhbmQgcmVmZXJlbmNlZCB2aWEgdGhlIHRtU3RhdGVSZWZlcmVuY2UgcGFyYW1ldGVyLgog ICBIb3cgYW5kIGlmIHRoaXMgaXMgbWFwcGVkIHRvIGEgcGFydGljdWxhciB0cmFuc3BvcnQgb3Ig Y2hhbm5lbCBpcwogICB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIFRyYW5zcG9ydCBTdWJzeXN0 ZW0uCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDIuMwogIFRoZSBjb250ZW50cyBvZiB0aGlzIHNl Y3Rpb24gc2VlbSB0byBkZXNjcmliZSBub3Qgb25seSB0aGUgY29leGlzdGVuY2UKb2YgdGhlIFRy YW5zcG9ydCBTZWN1cml0eSBNb2RlbCB3aXRoIG90aGVyIFNlY3VyaXR5IE1vZGVscywgYnV0IGhv dyB0aGUKVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsIGNhbiBjb2V4aXN0IChhbmQvb3IgaW50ZXJm YWNlIHdpdGgpIG90aGVyCm1vZGVscyB3aXRoaW4gdGhlIFJGQzM0MTEgYXJjaGl0ZWN0dXJlLiAg SXQgbWlnaHQgYmUgdXNlZnVsIHRvIHN1YmRpdmlkZQp0aGlzIGRlc2NyaXB0aW9uIGludG8gc2Vw YXJhdGUgc3Vic2VjdGlvbnMgZm9yIGVhY2ggb2YgdGhlIFJGQzM0MTEKU3Vic3lzdGVtcy4KCgpT ZWN0aW9uIDIuMywgcGFyYWdyYXBoIDMKICBNb3ZlIHRoaXMgcGFyYWdyYXBoIChhbmQgdGhlIHR3 byB0aGF0IGZvbGxvdykgaW50byBhIG5ldyBzdWJzZWN0aW9uLgoKICA8cHJvcG9zYWw+CiAgICAg Mi4zLjEuICBDb2V4aXN0ZW5jZSB3aXRoIE1lc3NhZ2UgUHJvY2Vzc2luZyBNb2RlbHMKCiAgIFRo ZSBTTk1QdjEgYW5kIFNOTVB2MmMgbWVzc2FnZSBwcm9jZXNzaW5nIGRlc2NyaWJlZCBpbiBbUkZD MzU4NF0KICAgKEJDUCA3NCkgYWx3YXlzIHNlbGVjdCB0aGUgU05NUHYxKDEpIGFuZCBTTk1QdjIo MikgU2VjdXJpdHkgTW9kZWxzCiAgIHJlc3BlY3RpdmVseS4gIFNpbmNlIHRoZXJlIGlzIG5vIG1l Y2hhbmlzbSBkZWZpbmVkIGluIFJGQzM1ODQgdG8KICAgc2VsZWN0IGFuIGFsdGVybmF0aXZlIFNl Y3VyaXR5IE1vZGVsLCBTTk1QdjEgYW5kIFNOTVB2MmMgbWVzc2FnZXMKICAgY2Fubm90IHVzZSB0 aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsLiAgU3VjaCBtZXNzYWdlcyBjYW4gc3RpbGwKICAg YmUgY29udmV5ZWQgb3ZlciBhIHNlY3VyZSB0cmFuc3BvcnQgcHJvdG9jb2wsIGJ1dCB0aGUgdHJh bnNwb3J0CiAgIHNlY3VyaXR5IGluZm9ybWF0aW9uIHdpbGwgbm90IGJlIHVzZWQgYXMgcGFydCBv ZiB0aGUgU05NUC1sZXZlbAogICBhdXRoZW50aWNhdGlvbiBvciBhdXRob3JpemF0aW9uLgoKICAg VGhlIFNOTVB2MnUvU05NUHYyKiBNZXNzYWdlIFByb2Nlc3NpbmcgTW9kZWwgaXMgYSBoaXN0b3Jp Y2FsIGFydGlmYWN0CiAgIGZvciB3aGljaCB0aGVyZSBpcyBubyBleGlzdGluZyBJRVRGIHNwZWNp ZmljYXRpb24uCgogICBUaGUgU05NUHYzIG1lc3NhZ2UgcHJvY2Vzc2luZyBkZWZpbmVkIGluIFtS RkMzNDEyXSwgZXh0cmFjdHMgdGhlCiAgIHNlY3VyaXR5TW9kZWwgZnJvbSB0aGUgbXNnU2VjdXJp dHlNb2RlbCBmaWVsZCBvZiBhbiBpbmNvbWluZwogICBTTk1QdjNNZXNzYWdlLiAgIFdoZW4gdGhp cyB2YWx1ZSBpcyB0cmFuc3BvcnRTZWN1cml0eU1vZGVsKFlZKSwKICAgc2VjdXJpdHkgcHJvY2Vz c2luZyBpcyBkaXJlY3RlZCB0byB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsLgogICBGb3Ig YW4gb3V0Z29pbmcgbWVzc2FnZSB0byBiZSBzZWN1cmVkIHVzaW5nIHRoZSBUcmFuc3BvcnQKICAg U2VjdXJpdHkgTW9kZWwsIHRoZSBhcHBsaWNhdGlvbiBzaG91bGQgc3BlY2lmeSBhIHNlY3VyaXR5 TW9kZWwKICAgcGFyYW1ldGVyIHZhbHVlIG9mIHRyYW5zcG9ydFNlY3VyaXR5TW9kZWwgaW4gdGhl IHNlbmRQZHUgQVNJLgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiAyLjMsIHBhcmFncmFwaCA2CiAg TW92ZSB0aGlzIHBhcmFncmFwaCBpbnRvIGEgbmV3IHN1YnNlY3Rpb24uCgogIDxwcm9wb3NhbD4K ICAgICAyLjMuMi4gIENvZXhpc3RlbmNlIHdpdGggb3RoZXIgU2VjdXJpdHkgTW9kZWxzCgogICAg IFtbIHRleHQgYXMgY3VycmVudGx5IF1dCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDIuMywgcGFy YWdyYXBoIDgKICBNb3ZlIHRoaXMgcGFyYWdyYXBoIGludG8gYSBuZXcgc3Vic2VjdGlvbiwgYW5k IGV4cGFuZCBzbGlnaHRseQoKICA8cHJvcG9zYWw+CiAgICAgMi4zLjMuICBDb2V4aXN0ZW5jZSB3 aXRoIFRyYW5zcG9ydCBNb2RlbHMKCiAgICAgVGhlIHdob2xlIHB1cnBvc2Ugb2YgdGhlIFRyYW5z cG9ydCBTZWN1cml0eSBNb2RlbCBpcyB0byB3b3JrCiAgIHdpdGggYXBwcm9wcmlhdGUgc2VjdXJl IFRyYW5zcG9ydCBNb2RlbHMgdG8gdXNlIHRoZSB0cmFuc3BvcnQtCiAgIGxldmVsIHNlY3VyaXR5 IGluZm9ybWF0aW9uIGZvciBhdXRoZW50aWNhdGluZyBhbmQgYXV0aG9yaXppbmcKICAgYW4gU05N UCByZXF1ZXN0LiAgQW4gaW5kaWNhdGlvbiBvZiB3aGljaCBUcmFuc3BvcnQgTW9kZWwgd2FzIG9y CiAgIHNob3VsZCBiZSB1c2VkIGlzIGluY2x1ZGVkIGFzIHBhcnQgb2YgdGhlIHRtU3RhdGVSZWZl cmVuY2UgY2FjaGUuCgogICBUaGUgTUlCIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQg YWxsb3dzIGFuIGFkbWluaXN0cmF0b3IKICAgdG8gY29uZmlndXJlIHRoZSBUcmFuc3BvcnQgU2Vj dXJpdHkgTW9kZWwgdG8gZGlzYWJsZSBzdXBwb3J0IGZvcgogICBzcGVjaWZpYyB0cmFuc3BvcnQg bW9kZWxzLgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiAyLjMsIHBhcmFncmFwaCA3CiAgTW92ZSB0 aGlzIHBhcmFncmFwaCBpbnRvIGEgbmV3IHN1YnNlY3Rpb24sIGFuZCBleHBhbmQgdG8gZGlzY3Vz cwp0cmFuc3BvcnQtdmlzaWJsZSBzZWN1cml0eU5hbWVzLgoKICA8cHJvcG9zYWw+CiAgICAgMi4z LjQuICBDb2V4aXN0ZW5jZSB3aXRoIEFjY2VzcyBDb250cm9sIE1vZGVscwoKICAgICBBbiBTTk1Q IGVuZ2luZSB3aWxsIHR5cGljYWxseSBpbXBsZW1lbnQgb25seSBvbmUgQWNjZXNzIENvbnRyb2wK ICAgTW9kZWwsIGFuZCB0aGVyZSBpcyBubyBtZWNoYW5pc20gZGVmaW5lZCBpbiBSRkMzNDExIGZv ciBzZWxlY3RpbmcKICAgYmV0d2VlbiBhbHRlcm5hdGl2ZSBBQ01zLiAgVGhlcmUgYXJlIHRoZXJl Zm9yZSBubyBpc3N1ZXMgcmVsYXRpbmcKICAgdG8gdGhlIGNvZXhpc3RlbmNlIG9mIHRoZSBUcmFu c3BvcnQgU2VjdXJpdHkgTW9kZWwgd2l0aCBtdWx0aXBsZQogICBBY2Nlc3MgQ29udHJvbCBNb2Rl bHMuCgogICBDb252ZXJzZWx5LCB0aGUgaXNBY2Nlc3NBbGxvd2VkIHByaW1pdGl2ZSBpbmNsdWRl cyBhIHBhcmFtZXRlciB0bwogICBpbmRpY2F0ZSB0aGUgU2VjdXJpdHkgTW9kZWwgdXNlZCB0byBh dXRoZW50aWNhdGUgYSByZXF1ZXN0LCBzbyB0aGUKICAgQWNjZXNzIENvbnRyb2wgTW9kZWwgc2hv dWxkIGJlIGFibGUgdG8gaGFuZGxlIG11bHRpcGxlIFNlY3VyaXR5CiAgIE1vZGVscyAoaW5jbHVk aW5nIHRoZSBUcmFuc3BvcnQgU2VjdXJpdHkgTW9kZWwpLgoKICAgSG93ZXZlciB0aGUgaXNBY2Nl c3NBbGxvd2VkIGRvZXMgbm90IHByb3ZpZGUgYW55IGluZm9ybWF0aW9uIGFib3V0CiAgIHRoZSBU cmFuc3BvcnQgTW9kZWwgdXNlZCBvciB0cmFuc3BvcnQtbGV2ZWwgc2VjdXJpdHkgcGFyYW1ldGVy cy4KICAgQXMgYSByZXN1bHQsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBoYXZlIGRpZmZlcmVudCBh Y2Nlc3MgY29udHJvbAogICBydWxlcyBmb3IgZGlmZmVyZW50IFRyYW5zcG9ydCBNb2RlbHMuICBP ciBhdCBsZWFzdCwgbm90IGRpcmVjdGx5IC0gdGhlCiAgIG9ubHkgd2F5IHRvIGluZmx1ZW5jZSBh Y2Nlc3MgY29udHJvbCBiYXNlZCBvbiB0cmFuc3BvcnQgY29uc2lkZXJhdGlvbnMKICAgd291bGQg YmUgdG8gdXNlIGRpZmZlcmVudCBzZWN1cml0eU5hbWUgdmFsdWVzIGZvciBkaWZmZXJlbnQgdHJh bnNwb3J0cy4KICA8L3Byb3Bvc2FsPgoKClNlY3Rpb24gMi40CiAgUmVmZXJyaW5nIHRvIHRoZSBN SUIgaXMgdW5uZWNlc3NhcnkgYXQgdGhpcyBwb2ludC4gIEl0IHdvdWxkIGJlCmNsZWFyZXIgKGFu ZCBjb25zaXN0ZW50IHdpdGggdGhlIFRyYW5zcG9ydCBzdWJzeXN0ZW0gZG9jdW1lbnQpIHRvCmRp c2N1c3MgcHJvY2Vzc2luZyBpcyB0ZXJtcyBvZiB0aGUgdG1TdGF0ZVJlZmVyZW5jZSBjYWNoZS4K ICBEZXRhaWxzIG9mIHRoZSBwcmVjaXNlIHByb2Nlc3NpbmcgcmVxdWlyZWQgYmVsb25nIGluIHRo ZSBFbGVtZW50cwpvZiBQcm9jZWR1cmUuICBJdCdzIHByb2JhYmx5IG5vdCB1c2VmdWwgdG8gZ28g aW50byBxdWl0ZSBzbyBtdWNoCmRldGFpbCBoZXJlLgoKICA8cHJvcG9zYWw+CiAgICAgRm9yIG91 dGdvaW5nIG1lc3NhZ2VzLCB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsIHVzZXMgcGFyYW1l dGVycwogICBwcm92aWRlZCBieSB0aGUgU05NUCBhcHBsaWNhdGlvbiB0byBsb29rdXAgb3IgY3Jl YXRlIGFuIGVudHJ5IGluIHRoZQogICB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlLiAgVGhlIHdob2xl TXNnIGFuZCB0bVN0YXRlUmVmZXJlbmNlIHBhcmFtZXRlcgogICBhcmUgcGFzc2VkIHRvIHRoZSBh cHByb3ByaWF0ZSBUcmFuc3BvcnQgTW9kZWwgYXMgZGVzY3JpYmVkIGluCiAgIFtJRC5pZXRmLWlz bXMtdG1zbV0uCgogICBGb3IgaW5jb21pbmcgbWVzc2FnZXMsIGEgVHJhbnNwb3J0IE1vZGVsIGFj Y2VwdHMgdGhlIG1lc3NhZ2UgZnJvbQogICB0aGUgbG93ZXIgbGF5ZXIgdHJhbnNwb3J0LCBhbmQg cmVjb3JkcyB0aGUgdHJhbnNwb3J0LSBhbmQgc2VjdXJpdHktCiAgIHJlbGF0ZWQgaW5mb3JtYXRp b24gaW4gdGhlIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUuICBUaGUgd2hvbGVNc2cKICAgYW5kIHRt U3RhdGVSZWZlcmVuY2UgcGFyYW1ldGVyIGFyZSBwYXNzZWQgdG8gdGhlIGFwcHJvcHJpYXRlIAog ICBTZWN1cml0eSBNb2RlbCBhcyBkZXNjcmliZWQgaW4gW0lELmlldGYtaXNtcy10bXNtXS4KCiAg IFRoZSBjb250ZW50cyBvZiB0aGlzIGNhY2hlIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiAzLjIu CiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMKICBUaGlzIHdob2xlIGRlc2NyaXB0aW9uIHNob3Vs ZCBwcm9iYWJseSBiZSByZXBsYWNlZCBieSB0aGUgc3RhbmRhcmQKdGV4dCBwcm9wb3NlZCBmb3Ig dGhlIENhY2hlZCBJbmZvcm1hdGlvbiBhbmQgUmVmZXJlbmNlcyBzZWN0aW9uLgpOb3RlIHRoYXQg dGhpcyBlZmZlY3RpdmVseSBzd2l0Y2hlcyB0aGUgb3JkZXIgb2Ygc3Vic2VjdGlvbnMgMy4xIGFu ZAozLjIsIHRvIG1hdGNoIHRoZSBvcmRlciB1c2VkIGluIHRoZSBvdGhlciBJU01TIGRvY3VtZW50 cy4KCkFkZCB0aGUgZm9sbG93aW5nIHRvIHRoZSBlbmQgb2Ygc2VjdGlvbiAzLjEgKHNlY3VyaXR5 U3RhdGVSZWZlcmVuY2UpCgogIDxwcm9wb3NhbD4KICAgICBUaGUgdG1TdGF0ZVJlZmVyZW5jZSBw YXJhbWV0ZXIgaXMgdXNlZCB0byBlbnN1cmUgdGhhdCB0aGUKICAgc2VjdXJpdHkgcGFyYW1ldGVy cyB1c2VkIGZvciBhIHJlc3BvbnNlIG1hdGNoIHRob3NlIGZvciB0aGUKICAgb3JpZ2luYWwgcmVx dWVzdC4gIFRoZSBUcmFuc3BvcnQgU2VjdXJpdHkgTW9kZWwgc2hvdWxkIGFkZAogICB0aGUgdG1T dGF0ZVJlZmVyZW5jZSByZWNlaXZlZCBmcm9tIHRoZSBwcm9jZXNzSW5jb21pbmdNc2cKICAgQVNJ IHRvIHRoZSBzZWN1cml0eVN0YXRlUmVmZXJlbmNlLiAgVGhpcyB0bVN0YXRlUmVmZXJlbmNlIGNh bgogICB0aGVuIGJlIHJldHJpZXZlZCBkdXJpbmcgdGhlIGdlbmVyYXRlUmVzcG9uc2VNc2cgQVNJ LCBzbyB0aGF0CiAgIGl0IGNhbiBiZSBwYXNzZWQgYmFjayB0byB0aGUgVHJhbnNwb3J0IE1vZGVs LgogIDwvcHJvcG9zYWw+CgpUaGlzIHNlZW1zIHRvIGJlIHRoZSBpbnRlbnRpb24gb2YgdGhlIHNl Y29uZCBwYXJhZ3JhcGggb2YgdGhlCihjdXJyZW50KSBTZWN0aW9uIDMuMiwgYWx0aG91Z2ggdGFs a2luZyBhYm91dCB0aGUgVHJhbnNwb3J0IE1vZGVsCmhhdmluZyBhY2Nlc3MgdG8gdGhlIHNlY3Vy aXR5U3RhdGVSZWZlcmVuY2UgY2FjaGUgaXMgY29uZnVzaW5nLgoKClNlY3Rpb24gNC4yLCBzdGVw IDEKICAgV2hldGhlciB0aGUgU2VjdXJpdHkgTW9kZWwgaXMgcHJvY2Vzc2luZyBhIHJlc3BvbnNl IG1lc3NhZ2UKKGFzIG9wcG9zZWQgdG8gYSByZXF1ZXN0KSBjYW4gYmUgZGV0ZXJtaW5lZCBieSB3 aGljaCBBU0kgaXMgdXNlZCwKcmF0aGVyIHRoYW4gdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2Yg YSBnaXZlbiBwYXJhbWV0ZXJzLgoKICA8cHJvcG9zYWw+CiAgICAgMSkgV2hlbiBnZW5lcmF0ZVJl c3BvbnNlTXNnIGlzIHVzZWQgdG8gaGFuZGxlIGFuIFNOTVAgcmVzcG9uc2UsCiAgIHRoZSBzZWN1 cml0eVN0YXRlUmVmZXJlbmNlIGNhY2hlIHdpbGwgY29udGFpbiBpbmZvcm1hdGlvbiBmcm9tCiAg IHRoZSBjb3JyZXNwb25kaW5nIHJlcXVlc3QsIGluY2x1ZGluZyBzZWN1cml0eU5hbWUsIHNlY3Vy aXR5TGV2ZWwsCiAgIGFuZCB0aGUgdG1TdGF0ZVJlZmVyZW5jZS4gIFRoZSBUcmFuc3BvcnQgU2Vj dXJpdHkgTW9kZWwgc2hvdWxkCiAgIGV4dHJhY3QgdGhlc2UgdmFsdWVzLCBhbmQgY2FuIHRoZW4g ZGlzY2FyZCB0aGUgY2FjaGVkIHNlY3VyaXR5CiAgIGRhdGEgYW5kIHRoZSBzZWN1cml0eVN0YXRl UmVmZXJlbmNlLgoKICAgVGhlIHRtUmVxdWVzdGVkU2VjdXJpdHlMZXZlbCBpbiB0aGUgdG1TdGF0 ZVJlZmVyZW5jZSBjYWNoZQogICBzaG91bGQgYmUgc2V0IHRvIHRoZSB2YWx1ZSBvZiB0aGUgZXh0 cmFjdGVkIHNlY3VyaXR5TGV2ZWwsCiAgIGFuZCB0aGUgdG1TYW1lU2VjdXJpdHkgcGFyYW1ldGVy IHNob3VsZCBiZSBzZXQgdG8gdHJ1ZS4KICA8L3Byb3Bvc2FsPgoKUW46ICBIb3cgZG8gdGhlIHNl Y3VyaXR5TmFtZSBhbmQgc2VjdXJpdHlMZXZlbCBJTiBwYXJhbWV0ZXJzCiAgICAgcmVsYXRlIHRv IHRoZSBlcXVpdmFsZW50IHNlY3VyaXR5U3RhdGVSZWZlcmVuY2UgY2FjaGUgZmllbGRzPwogICAg IEFyZSB0aGVzZSBwYXJhbWV0ZXJzIHVzZWQgYXQgYWxsPwpRbjogIFNob3VsZCB0aGUgc25tcFRz bUxDRFRyYW5zZm9ybVRhYmxlIGJlIHJlZmVyZW5jZWQgdG8gY2hlY2sKICAgICB3aGV0aGVyIHRo ZSBzcGVjaWZpZWQgdHJhbnNwb3J0IGlzIHN0aWxsIGVuYWJsZWQ/ClFuOiAgU2hvdWxkIHRoZSBz ZWN1cml0eU5hbWUgKGZyb20gdGhlIHNlY3VyaXR5U3RhdGVSZWZlcmVuY2UpCiAgICAgYmUgbWFw cGVkIGJhY2sgdG8gYSB0bVNlY3VyaXR5TmFtZSwgb3Igd2lsbCB0aGUgZXhpc3RpbmcKICAgICB0 bVNlY3VyaXR5TmFtZSBmcm9tIHRoZSB0bVN0YXRlUmVmZXJlbmNlIGJlIHVzZWQ/CgoKU2VjdGlv biA0LjIsIHN0ZXBzIDImMwogICBUaGVzZSB0d28gc3RlcHMgYm90aCBhcHBseSB0byB0aGUgZ2Vu ZXJhdGVSZXF1ZXN0TXNnIEFTSS4KSXQgd291bGQgcHJvYmFibHkgYmUgY2xlYXJlciB0byBjb21i aW5lIHRoZW0gaW50byBhIHNpbmdsZSBzdGVwLgoKICA8cHJvcG9zYWw+CiAgICAgMikgV2hlbiBn ZW5lcmF0ZVJlcXVlc3RNc2cgaXMgY2FsbGVkIHRvIGhhbmRsZSBhbiBTTk1QIHJlcXVlc3QsCiAg IHRoZSBwYXJhbWV0ZXJzIHdvbid0IGluY2x1ZGUgYSBzZWN1cml0eVN0YXRlUmVmZXJlbmNlIGNh Y2hlLgogICBJbnN0ZWFkLCB0aGUgdHJhbnNwb3J0IGFuZCBzZWN1cml0eSByZXF1aXJlbWVudHMg d2lsbCBiZSBzdXBwbGllZAogICBieSB0aGUgYXBwbGljYXRpb24gdmlhIHRoZSBJTiBwYXJhbWV0 ZXJzLgoKICAgRmlyc3RseSwgdGhlIHJlcXVlc3RlZCB0cmFuc3BvcnREb21haW4gc2hvdWxkIGJl IGxvb2tlZCB1cCBpbiB0aGUKICAgc25tcFRzbUxDRFRyYW5zZm9ybVRhYmxlLiAgSWYgdGhlcmUg aXMgbm8gZW50cnkgZm9yIHRoaXMgZG9tYWluLAogICBvciB0aGUgc25tcFRzbUxDRFBvbGljeSB2 YWx1ZSBpcyBzZXQgdG8gZGlzYWJsZSgzKSwgdGhlbiAuLi4KICAgLi4uIHByb2Nlc3Npbmcgc3Rv cHMgZm9yIHRoaXMgbWVzc2FnZS4KCltbIElmIHRoZSB2YWx1ZSBvZiBzbm1wVHNtTENEVHJhbnNm b3JtUG9saWN5IGlzIHByaXZhdGUoMSksIHRoZW4gXV0KICAgdGhlIHZhbHVlcyBzdXBwbGllZCBm b3IgdHJhbnNwb3J0RG9tYWluLCB0cmFuc3BvcnRBZGRyZXNzLAogICBzZWN1cml0eU5hbWUgYW5k IHNlY3VyaXR5TGV2ZWwgYXJlIHVzZWQgdG8gbG9va3VwIG9yIGNyZWF0ZSBhbgogICBlbnRyeSBp biB0aGUgc25tcFRzbUxDRFRhYmxlLCBhbmQgdGhlIHNubXBUc21MQ0RUbVNlY3VyaXR5TmFtZQog ICBjb2x1bW4gdmFsdWUgdXNlZCBmb3IgdG1TZWN1cml0eU5hbWUuICBbWyBPdGhlcndpc2UsIHRt U2VjdXJpdHlOYW1lCiAgIHNob3VsZCBiZSBzZXQgdG8gYmUgdGhlIHNhbWUgYXMgdGhlIHN1cHBs aWVkIHNlY3VyaXR5TmFtZS4gIF1dCgogICBDcmVhdGUgYSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hl IHdpdGggdG1TZWN1cml0eU5hbWUgc2V0IHRvCiAgIHRoZSB2YWx1ZSBkZXRlcm1pbmVkIGFib3Zl LCB0bVJlcXVlc3RlZFNlY3VyaXR5TGV2ZWwgdG8gdGhlCiAgIHN1cHBsaWVkIHNlY3VyaXR5TGV2 ZWwgdmFsdWUsIGFuZCB0bVNhbWVTZWN1cml0eSB0byBmYWxzZS4KICA8L3Byb3Bvc2FsPgoKUW46 IEhvdyBzaG91bGQgdGhlIHNlY3VyaXR5TmFtZSAtPiB0bVNlY3VyaXR5TmFtZSBtYXBwaW5nIGJl IGRvbmUKICAgIGlmIHRoZXJlIGlzIGFuIGluY29uc2lzdGVuY3kgYmV0d2VlbiBzbm1wVHNtTENE VHJhbnNmb3JtUG9saWN5CiAgICBhbmQgc25tcFRzbUxDRFRtU2VjdXJpdHlOYW1lPyAgIChpLmUu IGEgcG9saWN5IG9mICdkZWZhdWx0JwogICAgYW5kIGEgdmFsdWUgb2YgdG1TZWN1cml0eU5hbWUg dGhhdCBkb2Vzbid0IG1hdGNoIHNlY3VyaXR5TmFtZSkKCiAgICBUaGUgZnVsbCBkZXNjcmlwdGlv biBhYm92ZSAoaW5jbHVkaW5nIFtbdGV4dF1dKSBvbmx5IHJlZmVyZW5jZXMKICAgIHRoZSBzbm1w VHNtTENEVGFibGUgZm9yIG5vbi1kZWZhdWx0IHNlY3VyaXR5TmFtZSBtYXBwaW5nLCBhbmQKICAg IGFwcGxpZXMgdGhlIGlkZW50aXR5IG1hcHBpbmcgYXV0b21hdGljYWxseSAod2l0aG91dCByZXF1 aXJpbmcKICAgIGEgc25tcFRzbUxDRFRhYmxlIHJvdyBhdCBhbGwpLiAgVGhlIHByZXZpb3VzIHRl eHQgd291bGQgYXBwbHkKICAgIGEgY29uZmlndXJlZCBub24taWRlbnRpdHkgbWFwcGluZyBldmVu IHdpdGggdGhlIGRlZmF1bHQgcG9saWN5CiAgICBmb3IgdGhhdCB0cmFuc3BvcnQgZG9tYWluLgoK ICAgIElmIHRoaXMgaXMgdGhlIGludGVuZGVkIGJlaGF2aW91ciwgaXQgd291bGQgYmUgc2Vuc2li bGUgdG8KICAgIHN0YXRlIHRoaXMgZXhwbGljaXRseS4KCiAgClNlY3Rpb24gNS4yCiAgSXQgd291 bGQgc2VlbSBtb3JlIG5hdHVyYWwgdG8gcGVyZm9ybSBhbGwgb2YgdGhlIHZhbGlkYXRpb24gc3Rl cHMKZmlyc3QsIGJlZm9yZSBzdGFydGluZyB0byBwb3B1bGF0ZSB0aGUgT1VUIHBhcmFtZXRlciB2 YWx1ZXMuCgogIFRoZSBzcGVjaWZpZWQgcHJvY2VkdXJlIGZvciBkZXRlcm1pbmluZyB0aGUgc2Vj dXJpdHlOYW1lICh1c2luZwphIG5vbi1pZGVudGl0eSBtYXBwaW5nKSBpcyB3cm9uZywgc2luY2Ug aXQgYWN0dWFsbHkgc2V0cyB0aGUgTUlCCnRhYmxlIHRtU2VjdXJpdHlOYW1lIGNvbHVtbi4gIFRo aXMgdmFsdWUgaXMgYWxyZWFkeSBwcm92aWRlZCBpbiB0aGUKdG1TdGF0ZVJlZmVyZW5jZSBjYWNo ZS4gIFRoZSBmb2xsb3dpbmcgdGV4dCBwcm9wb3NlcyBhbiBhbHRlcm5hdGl2ZQphcHByb2FjaCwg dGhhdCBkb2VzIG1hcCB0bVNlY3VyaXR5TmFtZSB0byBzZWN1cml0eU5hbWUuCiAgTm90ZSB0aGF0 IGFzIHdpdGggdGhlIHByb3Bvc2FsIGZvciA0LjIgYWJvdmUsIHRoaXMgbWFwcGluZyBvbmx5CnJl ZmVyZW5jZXMgdGhlIHNubXBUc21MQ0RUYWJsZSBmb3IgdGhlIG5vbi1kZWZhdWx0IHRyYW5zZm9y bSBwb2xpY3kuCgogIDxwcm9wb3NhbD4KICAgMSkgSWYgdG1TdGF0ZVJlZmVyZW5jZSBkb2VzIG5v dCByZWZlciB0byBhIHZhbGlkIGNhY2hlLCBjb250YWluaW5nCiAgICAgIHZhbHVlcyBmb3IgdHJh bnNwb3J0RG9tYWluLCB0cmFuc3BvcnRBZGRyZXNzLCB0bVNlY3VyaXR5TmFtZQogICAgICBhbmQg dG1UcmFuc3BvcnRTZWN1cml0eUxldmVsLCB0aGVuIHRoZSBzbm1wVHNtSW52YWxpZENhY2hlIC4u LgoKICAgMikgSWYgdGhlcmUgaXMgbm8gZW50cnkgaW4gc25tcFRzbUxDRFRyYW5zZm9ybVRhYmxl IGNvcnJlc3BvbmRpbmcKICAgICAgdG8gdGhlIHNwZWNpZmllZCB0cmFuc3BvcnREb21haW4sIG9y IHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlIC4uLgoKICAgICAgcy90b2dldGhlciB3aXRoIHRoZSBP SUQgYW5kIHZhbHVlIG9mIHRoZSBpbmNyZW1lbnRlZCBjb3VudGVyLy8KICAgICAgcy9UcmFuc3Bv cnQgU2VjdXJpdHkgTW9kZWwvU2VjdXJpdHkgTW9kZWwvCgogICAzKSBDb21wYXJlIHRoZSBsZXZl bCBvZiBzZWN1cml0eSBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0CiAgICAgICh0bVRyYW5zcG9y dFNlY3VyaXR5TGV2ZWwgaW4gdGhlIHRtU3RhdGVSZWZlcmVuY2UpIHdpdGgKICAgICAgdGhhdCBy ZXF1aXJlZCBieSB0aGUgU05NUCBtZXNzYWdlICh0aGUgc2VjdXJpdHlMZXZlbAogICAgICBwYXJh bWV0ZXIgcGFzc2VkIGluIHRoZSBwcm9jZXNzSW5jb21pbmdNc2cgQVNJKS4gIElmIHRoZQogICAg ICB0cmFuc29ydCBzZWN1cml0eSBpcyB3ZWFrZXIgdGhhbiB0aGF0IHJlcXVpcmVkLCB0aGVuIHRo ZQogICAgICBzbm1wVHNtSW5hZGVxdWF0ZVNlY3VyaXR5TGV2ZWxzIGNvdW50ZXIgaXMgaW5jcmVt ZW50ZWQsCiAgICAgIGFuIGVycm9yIGluZGljYXRpb24gaXMgcmV0dXJuZWQgdG8gdGhlIGNhbGxp bmcgbW9kdWxlLAogICAgICBhbmQgU2VjdXJpdHkgTW9kZWwgcHJvY2Vzc2luZyBzdG9wcyBmb3Ig dGhpcyBtZXNzYWdlLgoKICAgNCkgU2V0IHNlY3VyaXR5RW5naW5lSUQgdG8gdGhlIGxvY2FsIHNu bXBFbmdpbmVJRC4KCiAgIDUpIElmIHRoZSBzbm1wVHNtTENEVHJhbnNmb3JtUG9saWN5IHZhbHVl IGZvciB0aGUgc3BlY2lmaWVkCiAgICAgIHRyYW5zcG9ydERvbWFpbiBpcyBkZWZhdWx0KDEpLCB0 aGVuIHNldCBzZWN1cml0eU5hbWUgdG8gdGhlCiAgICAgIHZhbHVlIG9mIHRtU2VjdXJpdHlOYW1l IGZyb20gdGhlIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUuCgogICAgICBJZiB0aGUgc25tcFRzbUxD RFRyYW5zZm9ybVBvbGljeSB2YWx1ZSBpcyBwcml2YXRlLCB0aGVuCiAgICAgIHNlYXJjaCB0aGUg c25tcFRzbUxDRFRhYmxlIGZvciBhbiBlbnRyeSB3aXRoIHRoZSBzcGVjaWZpZWQKICAgICAgdHJh bnNwb3J0RG9tYWluLCB0cmFuc3BvcnRBZGRyZXNzIGFuZCBzZWN1cml0eUxldmVsCiAgICAgIFtb IFhYWCAtIG9yIHRtVHJhbnNwb3J0U2VjdXJpdHlMZXZlbCA/PyBdXSBpbmRleGVzLCBhbmQKICAg ICAgYSBzbm1wVHNtTENEVG1TZWN1cml0eU5hbWUgdmFsdWUgdGhhdCBtYXRjaGVzIHRoZSB2YWx1 ZQogICAgICBvZiB0bVNlY3VyaXR5TmFtZSBmcm9tIHRoZSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hl LgogICAgICBJZiBzdWNoIGEgcm93IGlzIHByZXNlbnQsIHRoZW4gc2V0IHNlY3VyaXR5TmFtZSB0 byB0aGUKICAgICAgY29ycmVzcG9uZGluZyBzbm1wVHNtTENEU2VjdXJpdHlOYW1lIGluZGV4IHZh bHVlLgoKICAgICAgSWYgbm8gc3VjaCByb3cgZXhpc3RzLCBjYWxjdWxhdGUgc2VjdXJpdHlOYW1l IGZyb20gdGhlCiAgICAgIHNwZWNpZmllZCB0bVNlY3VyaXR5TmFtZSB1c2luZyB0aGUgYXBwcm9w cmlhdGUgcHJpdmF0ZSAKICAgICAgYWxnb3JpdGhtLiAgQ3JlYXRlIGEgcm93IGluIHRoZSBzbm1w VHNtTENEVGFibGUgaW5kZXhlZAogICAgICBieSB0aGUgc3BlY2lmaWVkIHRyYW5zcG9ydERvbWFp biwgdHJhbnNwb3J0QWRkcmVzcywKICAgICAgc2VjdXJpdHlMZXZlbCBbWyBYWFggLSBvciB0bVRy YW5zcG9ydFNlY3VyaXR5TGV2ZWwgXV0KICAgICAgdmFsdWVzIGFuZCB0aGlzIGNhbGN1bGF0ZWQg c2VjdXJpdHlOYW1lLiAgU2V0IHRoZQogICAgICBzbm1wVHNtTENEVG1TZWN1cml0eU5hbWUgY29s dW1uIHRvIHRoZSB0bVNlY3VyaXR5TmFtZQogICAgICBmcm9tIHRoZSB0bVN0YXRlUmVmZXJlbmNl IGNhY2hlLgoKICAgNikgRXh0cmFjdCB0aGUgc2NvcGVkUERVIGZyb20gdGhlIHdob2xlTXNnLgoK ICAgNykgQ2FsY3VsYXRlIHRoZSBtYXhTaXplUmVzcG9uc2VTY29wZWRQRFUuICBbWyBIT1cgPz8g XV0KICAgICAgVGhpcyBpcyB0aGUgbWF4aW11bSBzaXplIGFsbG93ZWQgZm9yIGEgc2NvcGVkUERV IGZvcgogICAgICBhIHBvc3NpYmxlIFJlc3BvbnNlIG1lc3NhZ2UuCiAKICAgOCkgQ3JlYXRlIGEg Y2FjaGUgY29udGFpbmluZyB0aGUgc2VjdXJpdHkgZGF0YSBmb3IgdGhpcwogICAgICBtZXNzYWdl LCByZWZlcmVuY2VkIGJ5IHNlY3VyaXR5U3RhdGVSZWZlcmVuY2UsIHNvIHRoYXQKICAgICAgYSBw b3NzaWJsZSByZXNwb25zZSBjYW4gdXNlIHRoZSBzYW1lIHNlY3VyaXR5IHBhcmFtZXRlcnMuCiAg ICAgIEZvciB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsLCB0aGlzIHNlY3VyaXR5IGNhY2hl CiAgICAgIHNob3VsZCBpbmNsdWRlIHRoZSB0bVN0YXRlUmVmZXJlbmNlLgoKICAgOSkgUmV0dXJu IGEgc3VjY2VzcyBpbmRpY2F0aW9uIHRvIHRoZSBjYWxsaW5nIG1vZHVsZSwKICAgICAgcGFzc2lu ZyB0aGUgT1VUIHBhcmFtZXRlcnMgZGV0ZXJtaW5lZCBhYm92ZS4KICA8L3Byb3Bvc2FsPgoKUW46 IFNob3VsZCB0aGUgdG1TZWN1cml0eU5hbWUgLT4gc2VjdXJpdHlOYW1lIG1hcHBpbmcgbG9va3Vw CiAgICBiZSBkb25lIHVzaW5nIHRoZSBzZWN1cml0eUxldmVsIGZyb20gdGhlIFNOTVAgcmVxdWVz dAogICAgKGFuYWxvZ291cyB3aXRoIHRoZSBvdXRnb2luZyBjYXNlKSwgb3Igd2l0aCB0aGUgbGV2 ZWwKICAgIHByb3ZpZGVkIGJ5IHRoZSB0cmFuc3BvcnQgbGF5ZXIgKHBvdGVudGlhbGx5IGZsYXR0 ZW5pbmcKICAgIG11bHRpcGxlIHBhcmFsbGVsIHNlc3Npb25zIGludG8gb25lKT8KCgpTZWN0aW9u IDYKICBUaGUgc3VtbWFyeSBvZiB0aGUgTUlCIGNvbnRlbnRzIGlzIHNsaWdodGx5IGluYWNjdXJh dGUuCgogIDxwcm9wb3NhbD4KICAgICBUaGlzIE1JQiBtb2R1bGUgcHJvdmlkZXMgbWFuYWdlbWVu dCBvZiB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsLgogICBJdCBjb250YWlucyB0aHJlZSBz dGF0aXN0aWNzIG9iamVjdHMsIGFuZCB0d28gdGFibGVzIGZvciBtYW5hZ2luZwogICB0aGUgYmVo YXZpb3VyIG9mIHRoZSBUcmFuc3BvcnQgU2VjdXJpdHkgTW9kZWwuCiAgPC9wcm9wb3NhbD4KCgpT ZWN0aW9uIDYuMwogIEEgbGl0dGxlIG1vcmUgZGV0YWlsIGFib3V0IHRoZSBjb250ZW50cyBvZiB0 aGUgc25tcFRjbUxDRCBzdWJ0cmVlCndvdWxkIHByb2JhYmx5IGJlIHVzZWZ1bC4KCiAgPHByb3Bv c2FsPgogICAgIDYuMy4xIHNubXBUc21MQ0RUcmFuc2Zvcm1UYWJsZQoKICAgVGhpcyB0YWJsZSBs aXN0cyB0aGUgW1sgc2VjdXJlPyBdXSB0cmFuc3BvcnRzIGltcGxlbWVudGVkIGJ5IHRoZQogICBT Tk1QIGVudGl0eSwgYW5kIGluZGljYXRlcyB0aGUgc2VjdXJpdHlOYW1lIG1hcHBpbmcgcG9saWN5 IHVzZWQKICAgZm9yIHRyYWZmaWMgdmlhIGVhY2ggdHJhbnNwb3J0LiAgVGhpcyB0YWJsZSBzaG91 bGQgYmUgcG9wdWxhdGVkCiAgIGF1dG9tYXRpY2FsbHkgYnkgdGhlIFNOTVAgZW5naW5lLCB3aXRo IG9uZSByb3cgZm9yIGVhY2ggc3VwcG9ydGVkCiAgIHRyYW5zcG9ydC4KCiAgICAgNi4zLjEgc25t cFRzbUxDRFRhYmxlCgogICBUaGlzIHRhYmxlIHByb3ZpZGVzIGRldGFpbHMgb2YgdGhlIHByZWNp c2UgbWFwcGluZyBiZXR3ZWVuIFNOTVAKICAgc2VjdXJpdHlOYW1lcyBhbmQgdHJhbnNwb3J0LXNw ZWNpZmljIHRtU2VjdXJpdHlOYW1lcywgZm9yIGJvdGgKICAgZXhpc3RpbmcgYW5kIHByZS1jb25m aWd1cmVkIHVzZXIgbmFtZXMuCiAgPC9wcm9wb3NhbD4KClFuOiAgSXMgaXQgbmVjZXNzYXJ5IGZv ciB0aGUgc25tcFRzbUxDRFRhYmxlIHRvIGNvbnRhaW4gZW50cmllcyBmb3IKICAgICBmaXhlZCAo aWRlbnRpdHkgKD8pYW5kIHByZWZpeCkgbWFwcGluZ3M/ClFuOiAgU2hvdWxkIHRoZSB0cmFuc2Zv cm0gdGFibGUgbGlzdCBub24tc2VjdXJlIHRyYW5zcG9ydHMKICAgICAoZS5nLiB0cmFkaXRpb25h bCBTTk1QLW92ZXItVURQLCBTTk1QLW92ZXItVENQLCBldGMpPwoKClNlY3Rpb24gNi40CiAgVGhl IG90aGVyIHJlbGV2YW50IE1JQiB0byBtZW50aW9uIGhlcmUgd291bGQgYmUgdGhlIHRoYXQgYmVs b25naW5nCiAgdG8gdGhlIGFwcHJvcHJpYXRlIEFjY2VzcyBDb250cm9sIE1vZGVsICh0eXBpY2Fs bHkgdGhlIFZBQ00gTUlCKS4KCiAgPHByb3Bvc2FsPgogICAgIGEvIGFuZCB0aGUgdGhlIGFwcHJv cHJpYXRlIEFjY2VzcyBDb250cm9sIE1vZGVsIE1JQgogICAgICAgIChmb3IgZXhhbXBsZSwgdGhl IFNOTVAtVklFVy1CQVNFRC1BQ00tTUlCIFtSRkMzNDE1XSkvCiAgPC9wcm9wb3NhbD4KICAKClNl Y3Rpb24gNi40LjEKICBUaGUgRWxlbWVudHMgb2YgUHJvY2VkdXJlIGRvbid0IGFjdHVhbGx5IG1h a2UgYW55IG1lbnRpb24gb2YgdGhlCnNubXBJbkFTTlBhcnNlRXJycy4KCiAgPHByb3Bvc2FsPgog ICAgIHMvJ3N5c3RlbScgZ3JvdXAvJ3NubXAnIGdyb3VwL2cKICAgICBzL2R1cGxpY2F0ZSB0aGVz ZSBvYmplY3RzL2R1cGxpY2F0ZSB0aGlzIG9iamVjdC8KICAgICBEZWxldGUgc2VudGVuY2VzIDMm NCAob3IgcG9zc2libHkgdGhpcyB3aG9sZSBzZWN0aW9uPykuCiAgPC9wcm9wb3NhbD4KCgpTZWN0 aW9uIDYuNC4yCgogIDxwcm9wb3NhbD4KICAgICBzL2RlZmluaXRpb25zIGZvciB0aGUgY29uY2Vw dHMgb2Ygc25tcEVuZ2luZUlELC8vCiAgICAgcy9vYmplY3QgZGVmaW5pdGlvbnMvYW4gb2JqZWN0 IGRlZmluaXRpb24vCiAgPC9wcm9wb3NhbD4KClRoZSBzZWN1cml0eUxldmVsIGVudW1lcmF0aW9u IHZhbHVlcyB3aWxsIGJlIHVzZWQgdG8gaW1wbGVtZW50CnRoZSBTTk1QLVRTTSBNSUIuCgoKKG5l dykgU2VjdGlvbiA2LjQuMwoKICA8cHJvcG9zYWw+CiAgICAgVGhlIFRyYW5zcG9ydCBTZWN1cml0 eSBNb2RlbCBhbHNvIG1hcHMgYmV0d2VlbiB0cmFuc3BvcnQtCiAgIHByb3ZpZGVkIGlkZW50aXRp ZXMgYW5kIHRoZSBTTk1QIHNlY3VyaXR5TmFtZSBmb3IgdXNlIGluCiAgIHRoZSBBY2Nlc3MgQ29u dHJvbCBwcm9jZXNzaW5nLiAgSXQgaXMgdGhlcmVmb3JlIGV4cGVjdGVkCiAgIHRoYXQgYW4gZW50 aXR5IGltcGxlbWVudGluZyB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsCiAgIHdpbGwgYWxz byBpbXBsZW1lbnQgdGhlIGFwcHJvcHJpYXRlIEFDTSBNSUIgKHN1Y2ggYXMgdGhlCiAgIFNOTVAt VklFVy1CQVNFRC1BQ00tTUlCIFtSRkMzNDE1XSkuCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDcs IHNubXBUc21JbmFkZXF1YXRlU2VjdXJpdHlMZXZlbHMKCiAgPHByb3Bvc2FsPgogICAgIHMvYnkg dGhlIGFwcGxpY2F0aW9uL2J5IHRoZSBhcHBsaWNhdGlvbiBvciBTTk1QIFBEVS8KICA8L3Byb3Bv c2FsPgoKClNlY3Rpb24gNywgc25tcFRzbUxDRERvbWFpblRhYmxlCiAgVGhlIG5hbWUgb2YgdGhl IHRhYmxlIGRvZXNuJ3QgbWF0Y2ggdGhhdCB1c2VkIGluIHRoZQpkZWZpbml0aW9uIG9mIHRoZSBz bm1wVHNtTENEVHJhbnNmb3JtRW50cnkgb2JqZWN0LgoKICA8cHJvcG9zYWw+CiAgICAgcy9zbm1w VHNtTENERG9tYWluVGFibGUvc25tcFRzbUxDRFRyYW5zZmVyVGFibGUvCiAgPC9wcm9wb3NhbD4K CgpTZWN0aW9uIDcsIHNubXBUc21MQ0RUcmFuc2Zvcm1Qb2xpY3kKUW46IFNob3VsZCB0aGlzIG9i amVjdCBpbmNsdWRlIGEgc2VwYXJhdGUgZW51bWVyYXRpb24KICAgIGZvciB0aGUgcHJlZml4IG1h cHBpbmc/CgoKU2VjdGlvbiA3LCBzbm1wVHNtTENEVGFibGUKICBUaGUgaW5kZXggb2JqZWN0cyBh cmUgZGVmaW5lZCBhcyAibm90LWFjY2Vzc2libGUiLApzbyBzaG91bGQgbm90IGJlIGluY2x1ZGVk IGluIHRoZSBleGFtcGxlIFNFVCBjb21tYW5kLgoKVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gaW50 ZXJuYWwgb3BlcmF0aW9uIGFuZCBleHRlcm5hbGx5CmNvbmZpZ3VyZWQgcm93cyBjb3VsZCBiZSBz bGlnaHRseSBjbGVhcmVyLgoKICA8cHJvcG9zYWw+CiAgICAgcy9tYXkgYmUgaW5zdGFudGlhdGVk L2NhbiBiZSBpbnN0YW50aWF0ZWQgYXV0b21hdGljYWxseS8KICAgICBzLywgYW5kIHRoZXkgY2Fu IGJlLy4gIFRoZXkgbWF5IGJlIGV4cGxpY2l0bHkvCgogICAgIHMvc25tcFRzbUxDRFRyYW5zcG9y dERvbWFpbj0oZGVzaXJlZCB2YWx1ZSksLy8KICAgICBzL3NubXBUc21MQ0RUcmFuc3BvcnRBZGRy ZXNzPShkZXNpcmVkIHZhbHVlKSwvLwogICAgIHMvc25tcFRzbUxDRFNlY3VyaXR5TmFtZT0oZGVz aXJlZCB2YWx1ZSksLy8KICAgICBzL3NubXBUc21MQ0RTZWN1cml0eUxldmVsPShkZXNpcmVkIHZh bHVlKSwvLwogIDwvcHJvcG9zYWw+CgpRbjogU2hvdWxkIHRoaXMgdGFibGUgbGlzdCBhbGwga25v d24gKGV4aXN0aW5nIGFuZC9vcgogICAgcHJlLWNvbmZpZ3VyZWQpIHVzZXJzLCBvciBqdXN0IHRo ZSBub24tZGVmYXVsdCBtYXBwaW5ncz8KCgpTZWN0aW9uIDcsIHNubXBUc21MQ0RUcmFuc3BvcnRE b21haW4KICA8cHJvcG9zYWw+CiAgICAgcy90cmFuc3BvcnQgdHlwZS90cmFuc3BvcnQgZG9tYWlu LwogICAgIGEvVGhpcyBpbmRpY2F0ZXMgdGhlIFRyYW5zcG9ydCBNb2RlbCB0aGF0IHdpbGwgYmUg dXNlZC4vCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDcsIHNzaFRzbUxDRFRtU2VjdXJpdHlOYW1l CgogIDwvcHJvcG9zYWw+CiAgICAgIEEgaHVtYW4gcmVhZGFibGUgc3RyaW5nIHJlcHJlc2VudGlu ZyB0aGUgdHJhbnNwb3J0LQogICAgYXV0aGVudGljYXRlZCBpZGVudGl0eSB0byBib3RoIHRoZSBU cmFuc3BvcnQgYW5kCiAgICBTZWN1cml0eSBNb2RlbHMuIEl0IGlzIHBhc3NlZCBiZXR3ZWVuIHRo ZW0gaW4KICAgIHRtU2VjdXJpdHlOYW1lLgoKICAgIFRoaXMgbWF5IG9yIG1heSBub3QgYmUgdGhl IHNhbWUgYXMgc3NoVHNtTENEU2VjdXJpdHlOYW1lLgogIDxwcm9wb3NhbD4KClFuOiBDYW4gdGhp cyB2YWx1ZSBiZSBjaGFuZ2VkIG9uY2UgYSB0cmFuc3BvcnQgY29ubmVjdGlvbgogICAgaGFzIGJl ZW4gZXN0YWJsaXNoZWQ/ICBJZiBzbywgd2hhdCBhcmUgdGhlIHNlY3VyaXR5CiAgICBpbXBsaWNh dGlvbnMgb2YgZG9pbmcgdGhpcz8KUW46IENhbiB0aGlzIHZhbHVlIGJlIHNldC9jaGFuZ2VkIHRv IGluZGljYXRlIGEgbm9uLWlkZW50aXR5CiAgICBtYXBwaW5nLCBpZiB0aGUgdHJhbnNmb3JtIHBv bGljeSBpcyBzZXQgdG8gZGVmYXVsdD8KCgpTZWN0aW9uIDgKICBUaGVyZSBpcyBhIGNlcnRhaW4g YW1vdW50IG9mIHJlcGV0aXRpb24gaW4gdGhpcyBkZXNjcmlwdGlvbiwKcGFydGljdWxhcmx5IGJl dHdlZW4gdGhlIGZpcnN0IHR3byBwYXJhZ3JhcGhzLgoKICA8cHJvcG9zYWw+CiAgICAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBTZWN1cml0eSBNb2RlbCwgY29tcGF0aWJsZSB3aXRoCiAgIHRo ZSBSRkMzNDExIGFyY2hpdGVjdHVyZSwgdGhhdCBwZXJtaXRzIFNOTVAgdG8gdXRpbGlzZQogICBz ZWN1cml0eSBzZXJ2aWNlcyBwcm92aWRlZCB0aHJvdWdoIGFuIFNOTVAgVHJhbnNwb3J0IE1vZGVs LgogICBUaGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsIHByb3ZpZGVzIG5vIHNlY3VyaXR5IGl0 c2VsZiwKICAgYnV0IHJlbGllcyBvbiBhIHNlY3VyZSBUcmFuc3BvcnQgTW9kZWwgdG8gcHJvdmlk ZSBhbgogICBhdXRoZW50aWNhdGVkIHByaW5jaXBhbCBmb3IgdXNlIGluIEFjY2VzcyBDb250cm9s IGRlY2lzaW9ucywKICAgYW5kIGFuIGFzc2VydGlvbiBvZiB0cmFuc3BvcnQgc2VjdXJpdHlMZXZl bCB0byBlbnN1cmUKICAgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuCgogICBJdCBTSE9V TEQgYWx3YXlzIGJlIHVzZWQgd2l0aCBhIFRyYW5zcG9ydCBNb2RlbCB0aGF0IHByb3ZpZGVzCiAg IHNlY3VyaXR5LCBidXQgdGhpcyBpcyBhIHJ1bi10aW1lIGRlY2lzaW9uIG9mIHRoZSBvcGVyYXRv ciBvcgogICBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uLCBvciBhIGNvbmZpZ3VyYXRpb24gZGVjaXNp b24gb2YgdGhlCiAgIG9wZXJhdG9yLgoKICAgVGhlIHNlY3VyaXR5IHRocmVhdHMgYW5kIGhvdyB0 aGVzZSB0aHJlYXRzIGFyZSBtaXRpZ2F0ZWQKICAgc2hvdWxkIGJlIGNvdmVyZWQgaW4gZGV0YWls IGluIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0aGUKICAgVHJhbnNwb3J0IE1vZGVsIGFuZCB0aGUg dW5kZXJseWluZyBzZWN1cmUgdHJhbnNwb3J0LgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiA5LCBE SVNDVVNTCiAgVGhlIGNob2ljZSBvZiBkZWZhdWx0IHBvcnRzIGlzIHN1cmVseSBhbiBpc3N1ZSBm b3IgdGhlIFRyYW5zcG9ydApzdWJzeXN0ZW0gKGkuZS4gaW5kaXZpZHVhbCBUcmFuc3BvcnQgTW9k ZWwgZGVmaW5pdGlvbiBkb2N1bWVudHMpLApyYXRoZXIgdGhhbiB0aGUgVHJhbnNwb3J0IFNlY3Vy aXR5IFN5c3RlbS4K ------=_Part_9_16883203.1218493522073 Content-Type: application/octet-stream; name=SSH-comments Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjrmzp3o3 Content-Disposition: attachment; filename=SSH-comments U2VjdGlvbiAxLjQKICBNdWNoIG9mIHRoZSBtb3RpdmF0aW9uIGRlc2NyaXB0aW9uIChwYXJhZ3Jh cGhzIDEsMiw1ICYgNikgZmVlbHMKdG9vIGRldGFpbGVkIGZvciB0aGlzIHBhcnRpY3VsYXIgZG9j dW1lbnQuICBNb3N0IG9mIHRoZSBqdXN0aWZpY2F0aW9uCmlzIGZhaXJseSBnZW5lcmljLCBhbmQg d291bGQgYXBwbHkgdG8gdGhlIHVzZSBvZiBhbnkgc2VjdXJlIHRyYW5zcG9ydC4KQXMgc3VjaCwg dGhpcyBkZXRhaWxlZCBkZXNjcmlwdGlvbiByZWFsbHkgYmVsb25ncyBpbiB0aGUgVHJhbnNwb3J0 CnN1YnN5c3RlbSBkb2N1bWVudCwgcmF0aGVyIHRoYW4gaGVyZS4KICBBIG11Y2ggc2ltcGxlciBk ZXNjcmlwdGlvbiB3b3VsZCBiZSBzdWZmaWNpZW50LCB3aXRoIGEgcmVmZXJlbmNlIHRvCnRoZSBm dWxsZXIgZGVzY3JpcHRpb24gaW4gdGhlIFRyYW5zcG9ydCBzdWJzeXN0ZW0gZG9jdW1lbnQuCgog IDxwcm9wb3NhbD4KICAgICBXaWRlc3ByZWFkIHVzZSBvZiB2ZXJzaW9uIDMgb2YgdGhlIFNpbXBs ZSBOZXR3b3JrIE1hbmFnZW1lbnQKICAgUHJvdG9jb2wgKFNOTVB2Mykgd2l0aCB0aGUgVXNlci1i YXNlZCBTZWN1cml0eSBNb2RlbCAoVVNNKSBoYXMKICAgYmVlbiBoYW1wZXJlZCBieSB0aGUgbmVl ZCB0byBkZXBsb3kgYSBzZXBhcmF0ZSB1c2VyIGFuZCBrZXkKICAgbWFuYWdlbWVudCBpbmZyYXN0 cnVjdHVyZS4gIE9wZXJhdG9ycyBoYXZlIHJlcG9ydGVkIGEgZGVzaXJlIHRvCiAgIHVuaXR5IHRo ZSBhZG1pbmlzdHJhdGl2ZSBzZWN1cml0eSB1c2VkIGZvciBTTk1QLCB3aXRoIHRoYXQgdXNlZAog ICBmb3IgQ29tbWFuZCBMaW5lIEludGVyZmFjZXMgKENMSSkgYW5kIG90aGVyIG1hbmFnZW1lbnQg aW50ZXJmYWNlcy4KICAgW0ktRC5pZXRmLWlzbXMtdG1zbV0gZGVmaW5lcyBhIFRyYW5zcG9ydCBz dWJzeXN0ZW0sIGRlc2lnbmVkIHRvCiAgIGFsbG93IFNOTVAgdG8gdGFrZSBhY2NvdW50IG9mIHRy YW5zcG9ydC1sYXllciBzZWN1cml0eSBpbmZvcm1hdGlvbi4KCiAgIENMSXMgY29tbW9ubHkgdXNl IHRoZSBzZWN1cml0eSBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUgU2VjdXJlCiAgIFNoZWxsLCBh bmQgdGhpcyBpcyBhbHNvIHRoZSBhcHByb2FjaCBiZWluZyBhZG9wdGVkIGZvciB1c2Ugd2l0aAog ICBORVRDT05GIFtSRkM0NzQyXS4gIFRoaXMgbWVtbyBkZXNjcmliZXMgYSBtZXRob2QgZm9yIGlu dm9raW5nCiAgIGFuZCBydW5uaW5nIHRoZSBTTlAgcHJvdG9jb2wgd2l0aGluIGEgU2VjdXJlIFNo ZWxsIChTU0gpIHNlc3Npb24uCiAgIFRoaXMgcHJvdmlkZXMgZm9yIG11dHVhbCBhdXRoZW50aWNh dGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLAogICBkYXRhIHZhbGlkYXRpb24gYW5kIGNv bmZpZGVudGlhbGl0eSwgYW5kIGFsbG93cyBTTk1QIHRvIG1ha2UgdXNlCiAgIG9mIHRoZSBTU0gt YXV0aGVudGljYXRlZCBpZGVudGl0eSBpbiBhdXRob3JpemF0aW9uIHBvbGljaWVzIGZvcgogICBN SUIgZGF0YSBhY2Nlc3MuCgogICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgY2hhbGxlbmdlcyB0byBi ZSBhZGRyZXNzZWQgLi4gZGV0YWlsIGJlbG93LgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiAyLCBw YXJhZ3JhcGggMgogIFRoZSBkZXNjcmlwdGlvbiBvZiBTU0ggcG9zdC1jb25uZWN0aW9uIHByb2Nl c3NpbmcgKGZvbGxvd2luZyB0aGUKbGlzdCBvZiBTU0ggY29tcG9uZW50cykgaXMgc29tZXdoYXQg dmFndWUuICBBIGxlc3MgZ2VuZXJhbCBzdW1tYXJ5LAptb3JlIGNsb3NlbHkgYWxpZ25lZCB0byB0 eXBpY2FsIHVzYWdlLCBtaWdodCBiZSBtb3JlIGhlbHBmdWwuCgogIDxwcm9wb3NhbD4KICAgICBP bmNlIGEgc2VjdXJlIHRyYW5zcG9ydCBsYXllciBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlz aGVkLAogICBbYW5kIHRoZSBzZXJ2ZXIgaWRlbnRpdHkgdmVyaWZpZWQ/XSwgdGhlIGNsaWVudCBz ZW5kcyBhIHNlcnZpY2UKICAgcmVxdWVzdCB0byBpbml0aWF0ZSBjbGllbnQtc2lkZSB1c2VyIGF1 dGhlbnRpY2F0aW9uLiAgVGhpcyBpcwogICB0aGVuIHR5cGljYWxseSBmb2xsb3dlZCBieSBhIHNl Y29uZCBzZXJ2aWNlIHJlcXVlc3QgdG8gZXN0YWJsaXNoCiAgIGFuIFNTSCBTZXNzaW9uLgogIDwv cHJvcG9zYWw+CgoKU2VjdGlvbiAzCgogIDxwcm9wb3NhbD4KICAgICBzL0ZpdHMgaW50byB0aGUg VHJhbnNwb3J0IFN1YnN5c3RlbS8KICAgICAgIEZpdHMgaW50byB0aGUgU05NUCBBcmNoaXRlY3R1 cmUvCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMuMS4xCiAgVGhlIHRocmVhdHMgYXJlIGRpc2N1 c3NlZCBpbiBhIGRpZmZlcmVudCBvcmRlciB0byB0aGUgbGlzdCBpbgp0aGUgVHJhbnNwb3J0IHN1 YnN5c3RlbSBkb2N1bWVudCAod2hpY2ggbWF0Y2hlcyB0aGF0IGluIFJGQzM0MTEpLgpGb3IgY29u c2lzdGVuY3ksIGl0IHdvdWxkIHByb2JhYmx5IGJlIHVzZWZ1bCB0byBhbHdheXMgY292ZXIKdGhl c2UgdGhyZWF0cyBpbiB0aGUgc2FtZSBvcmRlci4KCiAgVGhlIGRlc2NyaXB0aW9ucyBmb3IgdGhl IG1haW4gZm91ciB0aHJlYXRzIGZlZWwgc29tZXdoYXQgc2hvcnQgYW5kCnVuY29udmluY2luZy4g IFRoZXJlIGlzIHR5cGljYWxseSBhIHN0YXRlbWVudCB0aGF0IHRoZSBTU0ggVHJhbnNwb3J0Ck1v ZGVsIGFkZHJlc3NlcyB0aGlzIHRocmVhdCwgd2l0aCBubyBqdXN0aWZpY2F0aW9uIG9yIGV4cGxh bmF0aW9uIG9mCmhvdyB0aGlzIGlzIGFjaGlldmVkLgoKICBUaGUgb3RoZXIgdGhyZWUgbnVtYmVy ZWQgcG9pbnRzICg0LCA1ICYgNykgc2VlbSB0byBiZSBwYXJ0aWN1bGFyCmNhc2VzIG9mIHRoZSBm b3VyIG1haW4gdGhyZWF0cywgYW5kIHdvdWxkIGJlIGJldHRlciBwcmVzZW50ZWQgYXMKc3VjaC4g IFRoaXMgd291bGQgYWxzbyBhZGRyZXNzIHRoZSBsYWNrIG9mIGp1c3RpZmljYXRpb24gYWJvdmUu CgogIDxwcm9wb3NhbD4KICAgMS4gIE1vZGlmaWNhdGlvbiBvZiBJbmZvcm1hdGlvbiAtIFNTSCBw cm92aWRlcyBmb3IgdmVyaWZpY2F0aW9uCiAgICAgICB0aGF0IHRoZSBjb250ZW50cyBvZiBlYWNo IG1lc3NhZ2UgaGFzIG5vdCBiZWVuIG1vZGlmaWVkCiAgICAgICBkdXJpbmcgaXRzIHRyYW5zbWlz c2lvbiB0aHJvdWdoIHRoZSBuZXR3b3JrLCBieSBkaWdpdGFsbHkKICAgICAgIHNpZ25pbmcgZWFj aCBTU0ggcGFja2V0LgoKICAgMi4gIE1hc3F1ZXJhZGUgLSBTU0ggcHJvdmlkZXMgZm9yIHZlcmlm aWNhdGlvbiBvZiB0aGUgaWRlbnRpdHkKICAgICAgIG9mIHRoZSBTU0ggc2VydmVyIHRocm91Z2gg dGhlIFNTSCBUcmFuc3BvcnQgUHJvdG9jb2wKICAgICAgIHNlcnZlciBhdXRoZW50aWNhdGlvbiAo W1JGQzQyNTNdKS4gICBUaGlzIGFsbG93cyBhbiBvcGVyYXRvcgogICAgICAgb3IgbWFuYWdlbWVu dCBzdGF0aW9uIHRvIGVuc3VyZSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZQogICAgICAgU05NUCBl bmdpbmUgdGhhdCBwcm92aWRlcyBNSUIgZGF0YS4KCiAgICAgICBTU0ggYWxzbyBwcm92aWRlcyBh IG51bWJlciBvZiBtZWNoYW5pc21zIGZvciB2ZXJpZmljYXRpb24KICAgICAgIG9mIHRoZSBpZGVu dGlmeSBvZiB0aGUgU1NIIGNsaWVudC1zaWRlIHByaW5jaXBhbCwgdXNpbmcKICAgICAgIHRoZSBT ZWN1cmUgU2hlbGwgQXV0aGVudGljYXRpb24gUHJvdG9jb2wgKFtSRkM0MjUyXSkuCiAgICAgICBU aGVzZSBpbmNsdWRlIHB1YmxpYyBrZXksIHBhc3N3b3JkIGFuZCBob3N0LWJhc2VkIG1lY2hhbmlz bS4KICAgICAgIFRoaXMgYWxsb3dzIHRoZSBTTk1QIGFjY2VzcyBjb250cm9sIHN1YnN5c3RlbSB0 byBlbnN1cmUKICAgICAgIHRoYXQgb25seSBhdXRob3JpemVkIHByaW5jaXBhbHMgaGF2ZSBhY2Nl c3MgdG8gcG90ZW50aWFsbHkKICAgICAgIHNlbnNpdGl2ZSBkYXRhLgoKICAgMy4gIE1lc3NhZ2Ug U3RyZWFtIE1vZGlmaWNhdGlvbiAtIFNTSCBwcm90ZWN0cyBhZ2FpbnN0IG1hbGljaW91cwogICAg ICAgcmUtb3JkZXJpbmcgb3IgcmVwbGF5aW5nIG9mIG1lc3NhZ2VzIHdpdGhpbiBhIHNpbmdsZSBT U0gKICAgICAgIHNlc3Npb24gYnkgdXNpbmcgc2VxdWVuY2UgbnVtYmVycyBhbmQgaW50ZWdyaXR5 IGNoZWNrcy4KICAgICAgIFNTSCBwcm90ZWN0cyBhZ2FpbnN0IHJlcGxheSBvZiBtZXNzYWdlcyBh Y3Jvc3MgU1NIIHNlc3Npb25zCiAgICAgICBieSBlbnN1cmluZyB0aGF0IHRoZSBjcnlwdG9ncmFw aGljIGtleXMgdXNlZCBmb3IgZW5jcnlwdGlvbgogICAgICAgYW5kIGludGVncml0eSBjaGVja3Mg YXJlIGdlbmVyYXRlZCBhZnJlc2ggZm9yIGVhY2ggc2Vzc2lvbi4KICAgICAgICAKICAgNC4gIERp c2Nsb3N1cmUgLSBTU0ggcHJvdGVjdHMgYWdhaW5zdCB0aGUgZGlzY2xvc3VyZSBvZgogICAgICAg aW5mb3JtYXRpb24gdG8gdW5hdXRob3JpemVkIHJlY2lwaWVudHMgb3IgZWF2ZXNkcm9wcGVycwog ICAgICAgYnkgZW5jcnlwdGluZyBhbGwgdHJhZmZpYyBiZXR3ZWVuIFNOTVAgZW5naW5lcy4KICA8 L3Byb3Bvc2FsPgoKClNlY3Rpb24gMy4xLjIsIHBhcmFncmFwaHMgMi8zCiAgVGhlIGRpc3RpbmN0 aW9uIGJldHdlZW4gdGhlIHRvcGljcyBvZiB0aGUgc2Vjb25kIGFuZCB0aGlyZApwYXJhZ3JhcGhz IGlzIG5vdCBhdCBhbGwgY2xlYXIsIGV2ZW4gYWZ0ZXIgbXVsdGlwbGUgcmVhZGluZ3MuCgpUaGUg YWJzb2x1dGUgcHJvaGliaXRpb24gb24gYW55dGhpbmcgb3RoZXIgdGhhbiBhdXRoUHJpdiBpbiBw YXJhZ3JhcGgKMyBjb25mbGljdHMgd2l0aCB0aGUgKHdlYWtlcikgcmVjb21tZW5kYXRpb25zIGVs c2V3aGVyZSBpbiB0aGUKZG9jdW1lbnQgKHNlY3Rpb24gMS40LCB0aGUgZmlyc3QgcGFyYWdyYXBo IG9mIHRoaXMgc2VjdGlvbiwgc2VjdGlvbiA5KS4KCiAgPHByb3Bvc2FsPgogICAgIHBhcmFncmFw aCAyCiAgIHMvdHlwZSBhbmQgYWRkcmVzcy9hZGRyZXNzLwogICBzL3RoZSBTU0ggVHJhbnNwb3J0 IE1vZGVsIHByb3ZpZGVzL3Byb3ZpZGVzLwogICAgCiAgICAgKG5ldyBwYXJhZ3JhcGgpCiAgIFRo ZSB0cmFuc3BvcnQgbGF5ZXIgYWxnb3JpdGhtcyB1c2VkIHRvIHByb3ZpZGUgYXV0aGVudGljYXRp b24sIGRhdGEKICAgaW50ZWdyaXR5IGFuZCBlbmNyeXB0aW9uIFNIT1VMRCBOT1QgYmUgZXhwb3Nl ZCB0byB0aGUgU1NIIFRyYW5zcG9ydAogICBNb2RlbCBsYXllci4gIFRoZSBUcmFuc3BvcnQgTW9k ZWwgbXVzdCBzaW1wbHkgdHJ1c3QgdGhhdCB0aGUKICAgdW5kZXJseWluZyBTU0ggY29ubmVjdGlv biBoYXMgYmVlbiBwcm9wZXJseSBjb25maWd1cmVkIHRvIHN1cHBvcnQKICAgYXV0aFByaXYgc2Vj dXJpdHkgY2hhcmFjdGVyaXN0aWNzLiAgT3V0Z29pbmcgbWVzc2FnZXMgc3BlY2lmaWVkCiAgIHdp dGggYSBzZWN1cml0eUxldmVsIG9mIG5vQXV0aE5vUHJpdiBvciBhdXRoTm9Qcml2LCBhcmUgYWN0 dWFsbHkKICAgc2VudCBieSB0aGUgU1NIIFRyYW5zcG9ydCBNb2RlbCB3aXRoIGF1dGhQcml2LWxl dmVsIHByb3RlY3Rpb24uCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMuMS4zLCBwYXJhZ3JhcGgg MgogIFRoZSBkZXNjcmlwdGlvbiBvZiBpbnRlZ3JhdGlvbiB3aXRoIG90aGVyIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMKZmVlbHMgdG9vIGRldGFpbGVkLiAgQSBzaW1wbGVyIGRlc2NyaXB0aW9u IHdvdWxkIHByb2JhYmx5IGJlIGJldHRlcjoKCiAgPHByb3Bvc2FsPgogICBUaGUgcGFzc3dvcmQg YXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGFsbG93cyBmb3IgaW50ZWdyYXRpb24gd2l0aAogICBk ZXBsb3llZCBwYXNzd29yZC1iYXNlZCBpbmZyYXN0cnVjdHVyZSwgc3VjaCBhcyBSQURJVVMgW1JG QzI4NjVdCiAgIG9yIERpYW1ldGVyIFtSRkMzNTg4XSwgZWl0aGVyIGRpcmVjdGx5IG9yIHVzaW5n IHBhc3N3b3JkIHZhbGlkYXRpb24KICAgcHJvdG9jb2xzIHN1Y2ggYXMgQ0hBUCBbUkZDMTk5NF0g b3IgZGlnZXN0IGF1dGhlbnRpY2F0aW9uIFtSRkM1MDkwXS4KICA8L3Byb3Bvc2FsPgoKClNlY3Rp b24gMy4xLjUKICBUaGlzIG1hdGVyaWFsIGlzIGVmZmVjdGl2ZWx5IGNvdmVyZWQgYnkgdGhlIGRl c2NyaXB0aW9uIG9mIHRocmVhdHMKaW4gc2VjdGlvbiAzLjEuMS4gIEl0J3MgcHJvYmFibHkgbm90 IG5lY2Vzc2FyeSB0byBjb3ZlciBpdCBhZ2FpbiBoZXJlLgoKICA8cHJvcG9zYWw+CiAgICAgRHJv cCB0aGlzIHNlY3Rpb24gYWx0b2dldGhlciAoYW5kIHJlbnVtYmVyIHRoZSBmb2xsb3dpbmcgc2Vj dGlvbikuCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDMuMS42LCBwYXJhZ3JhcGggNAoKICA8cHJv cG9zYWw+CiAgICAgcy90cmFuc3BvcnRBZGRyZXNzVHlwZS90cmFuc3BvcnREb21haW4vCiAgPC9w cm9wb3NhbD4KCgpTZWN0aW9uIDMuMywgcGFyYWdyYXBoIDIKICBUaGlzIHNlY3Rpb24gaXMgZW50 aXRsZWQgIk5vdGlmaWNhdGlvbnMgYW5kIFByb3h5IiwgYnV0IHRoZSB0ZXh0CmNvbmNlbnRyYXRl cyBvbiBkaXNjdXNzaW5nIG5vdGlmaWNhdGlvbiBoYW5kbGluZy4KCiAgPHByb3Bvc2FsPgogICAg IHMvbm90aWZpY2F0aW9ucy9ub3RpZmljYXRpb25zIG9yIHByb3h5IHJlcXVlc3RzLwogIDwvcHJv cG9zYWw+CgoKU2VjdGlvbiA0CiAgVGhlIGludHJvZHVjdGlvbiB0byB0aGlzIHNlY3Rpb24gc2hv dWxkIHByb2JhYmx5IGJlIHJlcGxhY2VkIGJ5CnRoZSBzdGFuZGFyZCB0ZXh0IHByb3Bvc2VkIGZv ciB0aGUgQ2FjaGVkIEluZm9ybWF0aW9uIGFuZCBSZWZlcmVuY2VzCnNlY3Rpb24gKFgsIFguMSBh bmQgWC4yKSwgd2l0aCBhIGNvdXBsZSBvZiBtaW5vciB0d2Vha3M6CgooY29tbW9uKSBTZWN0aW9u IFguMgogIHBhcmFncmFwaCAzOiAKICA8cHJvcG9zYWw+CiAgICAgcy9UcmFuc3BvcnQgTW9kZWxz L3RoZSBTU0ggVHJhbnNwb3J0IE1vZGVsLwogIDwvcHJvcG9zYWw+CgogIGFwcGVuZCBhZnRlciB0 aGUgc3VtbWFyeSBvZiB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlIGZpZWxkczoKICA8cHJvcG9zYWw+ CiAgICAgU2VlIHRoZSBFbGVtZW50cyBvZiBQcm9jZWR1cmVzIGZvciBkZXRhaWxlZCBwcm9jZXNz aW5nCiAgIGluc3RydWN0aW9ucyBvbiB0aGUgdXNlIG9mIHRoZXNlIGZpZWxkcyBieSB0aGUgU1NI IFRyYW5zcG9ydCBNb2RlbC4KICA8L3Byb3Bvc2FsPgoKClRoZSByZW1haW5kZXIgb2YgdGhpcyBz dGFuZGFyZCB0ZXh0IGNhbiBiZSBzaWduaWZpY2FudGx5IHNpbXBsaWZpZWQgdG8KY29uY2VudHJh dGUgb24gdGhlIHBhcnRpY3VsYXIgcmVxdWlyZW1lbnRzIG9mIHRoZSBTU0ggVHJhbnNwb3J0IE1v ZGVsLgoKICA8cHJvcG9zYWw+CiAgICAgNC4yLjEuICBUcmFuc3BvcnQgaW5mb3JtYXRpb24KCiAg IFRoZSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlIGZvciBhIGdpdmVuIFNTSCBjb25uZWN0aW9uIHNo b3VsZAogICBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzb3VyY2Ugb2YgaW5jb21pbmcg U05NUCBtZXNzc2FnZXMsCiAgIHNvIHRoYXQgdGhpcyBpcyBhY2Nlc3NpYmxlIHRvIHRyYW5zcG9y dC1hd2FyZSBTZWN1cml0eSBNb2RlbHMKCiAgICAgLSB0cmFuc3BvcnREb21haW4KICAgICAgICAg c25tcFNTSERvbWFpbiAoZGVmaW5lZCBpbiB0aGUgU1NIVE0tTUlCLCBzZWUgc2VjdGlvbiA3KQoK ICAgICAtIHRyYW5zcG9ydEFkZHJlc3MKICAgICAgICAgdGhlIHJlbW90ZSBlbmQgb2YgdGhlIFNT SCBjb25uZWN0aW9uLCByZXByZXNlbnRlZCBhcyBhbgogICAgICAgICBzbm1wU1NIQWRkcmVzcyAo ZGVmaW5lZCBpbiB0aGUgU1NIVE0tTUlCLCBzZWUgc2VjdGlvbiA3KQoKICAgICA0LjIuMi4gIHNl Y3VyaXR5TmFtZQoKICAgICBIb3cgdGhlIFNTSCB0cmFuc3BvcnQgcHJpbmNpcGFsIGlzIGV4dHJh Y3RlZCBmcm9tIHRoZSBTU0gKICAgICBsYXllciBpcyBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQu ICBCeSBkZWZhdWx0LCB0aGlzIHdpbGwKICAgICB0eXBpY2FsbHkgYmUgdGFrZW4gZnJvbSB0aGUg dmFsdWUgb2YgdGhlIHVzZXIgbmFtZSBmaWVsZAogICAgIG9mIHRoZSBTU0hfTVNHX1VTRVJBVVRI X1JFUVVFU1QgbWVzc2FnZSBmb3Igd2hpY2ggYQogICAgIFNTSF9NU0dfVVNFUkFVVEhfU1VDQ0VT UyBoYXMgYmVlbiByZWNlaXZlZC4gICBUaGUgU1NIIHByb3RvY29sCiAgICAgaXMgbm90IGFsd2F5 cyBjbGVhciBvbiB3aGV0aGVyIHRoaXMgdXNlciBuYW1lIGZpZWxkIG11c3QgYmUKICAgICBmaWxs ZWQgaW4sIHNvIGZvciBzb21lIGltcGxlbWVudGF0aW9ucywgaXQgbWF5IGJlIG5lY2Nlc3NhcnkK ICAgICB0byByZXRyaWV2ZSB0aGUgdHJhbnNwb3J0IHByaW5jaXBhbCBpbiBzb21lIG90aGVyIHdh eS4KCiAgICAgSG93IHRoZSBTU0ggdHJhbnNwb3J0IHByaW5jaXBhbCBpcyBtYXBwZWQgdG8vZnJv bSBhIHRtU2VjdXJpdHlOYW1lCiAgICAgc2hvdWxkIGJlIGFkbWluaXN0cmF0aXZlbHkgY29uZmln dXJhYmxlLCBpbmNsdWRpbmcgd2hldGhlciB0aGlzIGlzCiAgICAgYSBzdHJhaWdodCBpZGVudGl0 eSBtYXBwaW5nLCBvciBzb21lIGFsdGVybmF0aXZlIHRyYW5zZm9ybWF0aW9uLgogICAgIFRoZSBT U0hUTS1NSUIgKHNlZSBzZWN0aW9uIDcpIGluY2x1ZGVzIGEgc3NodExDRFRyYW5zZm9ybVBvbGlj eQogICAgIG9iamVjdCBhbmQgc3NodG1MQ0RUYWJsZSwgd2hpY2ggYXJlIHVzZWQgZHVyaW5nIHRo ZSBFbGVtZW50cyBvZgogICAgIFByb2NlZHVyZSB0byBkZXRlcm1pbmUgdGhpcyBtYXBwaW5nLgoK ICAgICBUcmFuc3BvcnQgTW9kZWwgdHJhbnNmb3JtcyBTSE9VTEQgZ2VuZXJhdGUgcHJlZGljdGFi bGUKICAgICB0bVNlY3VyaXR5TmFtZXMgdG8gcmVwcmVzZW50IHRyYW5zcG9ydCBwcmluY2lwYWxz LgogIAogICAgIDQuMi4zLiAgc2VjdXJpdHlMZXZlbAoKICAgICBTU0ggdHJhbnNwb3J0IGNvbm5l Y3Rpb25zIGFyZSBib3RoIHZlcmlmaWVkIGFuZCBlbmNyeXB0ZWQsCiAgICAgc28gaW5oZXJlbnRs eSBvZmZlciB0aGUgc3Ryb25nZXN0IHNlY3VyaXR5TGV2ZWwgcHJvdGVjdGlvbi4KCiAgICAgLSB0 bVRyYW5zcG9ydFNlY3VyaXR5TGV2ZWwKICAgICAgICAgYXV0aFByaXYKCiAgICAgLSB0bVJlcXVl c3RlZFNlY3VyaXR5TGV2ZWwKICAgICAgICAgdGhpcyB2YWx1ZSB3aWxsIGJlIGlnbm9yZWQgZm9y IG91dGdvaW5nIG1lc3NhZ2VzCiAgICAgICAgIChzaW5jZSBhbGwgU1NIIGNvbm5lY3Rpb25zIGF1 dG9tYXRpY2FsbHkgcHJvdmlkZQogICAgICAgICAgYW4gYWRlcXVhdGUgbGV2ZWwgb2Ygc2VjdXJp dHkpCgogICAgIDQuMi40LiAgU2Vzc2lvbiBpbmZvcm1hdGlvbgoKICAgICBUaGUgdG1TdGF0ZVJl ZmVyZW5jZSBjYWNoZSBmb3IgYW4gU1NIIGNvbm5lY3Rpb24gU0hPVUxEIGluY2x1ZGUKICAgICBh IHRtU2Vzc2lvbklEIHRvIGluZGljYXRlIHdoaWNoIFNTSCBzZXNzaW9uIGl0IHJlZmVycyB0by4K CiAgICAgSWYgdGhlIFRyYW5zcG9ydCBNb2RlbCByZWNlaXZlcyBhbiBvdXRnb2luZyBtZXNzYWdl IHdpdGggdGhlCiAgICAgdG1TYW1lU2VjdXJpdHkgcGFyYW1ldGVyIHNldCwgYnV0IHRoZSBzZXNz aW9uIGlkZW50aWZpZWQgaW4KICAgICB0aGUgdG1TdGF0ZVJlZmVyZW5jZSBkb2VzIG5vdCBtYXRj aCB0aGUgY3VycmVudCBlc3RhYmxpc2hlZAogICAgIFNTSCBzZXNzaW9uIGZvciB0aGUgc3BlY2lm aWVkIHRyYW5zcG9ydERvbWFpbiwgdHJhbnNwb3J0QWRkcmVzcywKICAgICB0bVNlY3VyaXR5TmFt ZSBhbmQgdG1SZXF1ZXN0ZWRTZWN1cml0eUxldmVsLCB0aGVuIHRoZSBtZXNzYWdlCiAgICAgTVVT VCBiZSBkaXNjYXJkZWQsIGFuZCB0aGUgZGlzcGF0Y2hlciBub3RpZmllZCB0aGF0IHRoZSBzZW5k aW5nCiAgICAgb2YgdGhlIG1lc3NhZ2UgZmFpbGVkLgogIDwvcHJvcG9zYWw+CgoKU2VjdGlvbiA1 CiAgVGhlIEFTSXMgcmVsZXZhbnQgdG8gdGhlIFNTSCBUcmFuc3BvcnQgTW9kZWwgYXJlIHRoZSB0 d28gZGVmaW5lZCBpbgp0aGUgVHJhbnNwb3J0IHN1c2JzeXN0ZW0gZG9jdW1lbnQgKHJlY2VpdmVN ZXNzYWdlIGFuZCBzZW5kTWVzc2FnZSksCnJhdGhlciB0aGFuIHRob3NlIGZyb20gUkZDMzQxMS4K ClRoZSByZWxlYXNlIG9mIHN0YXRlIGluZm9ybWF0aW9uIGlzIGluY2x1ZGVkIGFzIHBhcnQgb2Yg dGhlIGNvbW1vbgpkZXNjcmlwdGlvbiBvZiBDYWNoZWQgSW5mb3JtYXRpb24gYW5kIFJlZmVyZW5j ZXMsIGFuZCBjYW4gdGhlcmVmb3JlCnNhZmVseSBiZSBvbWl0dGVkIGhlcmUuCgpUaGUgZGVzY3Jp cHRpb24gb2YgZXJyb3IgaGFuZGxpbmcgKHdoaWNoIG9ubHkgYXBwbGllcyB0byBzZW5kTWVzc2Fn ZSkKY291bGQgdXNlZnVsbHkgYmUgc2ltcGxpZmllZCB0byBjb25jZW50cmF0ZSBvbiB0aGUgcHJp bWFyeSBlcnJvcgppbmRpY2F0aW9uICh0aGUgZXJyb3IgY291bnRlciBPSUQgYW5kIHZhbHVlKQoK ICA8cHJvcG9zYWw+CiAgICAgQWJzdHJhY3Qgc2VydmljZSBpbnRlcmZhY2VzIGZvciB0aGUgVHJh bnNwb3J0IHN1YnN5c3RlbSBoYXZlIGJlZW4KICAgZGVmaW5lZCBieSBbSUQuaWV0Zi1pc21zLXRt c21dLiAgVGhlIFNTSCBUcmFuc3BvcnQgTW9kZWwgdXNlcyB0aGVzZQogICBjb25jZXB0dWFsIGRh dGEgZmxvd3Mgd2hlbiBjb21tdW5pY2F0aW5nIHdpdGggdGhlIERpc3BhdGNoZXIuCgogICBBbiBl cnJvciBpbmRpY2F0aW9uIGluIHN0YXR1c0luZm9ybWF0aW9uIHdpbGwgdHlwaWNhbGx5CiAgIGlu Y2x1ZGUgdGhlIE9JRCBhbmQgdmFsdWUgZm9yIGFuIGluY3JlbWVudGVkIGVycm9yIGNvdW50ZXIu CiAgIFRoaXMgbWF5IGJlIGFjY29tcGFuaWVkIGJ5IHRoZSByZXF1ZXN0ZWQgc2VjdXJpdHlMZXZl bCwgYW5kCiAgIHRoZSB0bVN0YXRlUmVmZXJlbmNlLiAgUGVyLW1lc3NhZ2UgY29udGV4dCBpbmZv cm1hdGlvbiBpcyBub3QKICAgYWNjZXNzaWJsZSB0byBUcmFuc3BvcnQgTW9kZWxzLCBzbyBjb250 ZXh0RW5naW5lIHdvdWxkIGJlIHNldAogICB0byB0aGUgbG9jYWwgdmFsdWUgb2Ygc25tcEVuZ2lu ZUlELCBhbmQgY29udGV4dE5hbWUgdG8gdGhlCiAgIGRlZmF1bHQgY29udGV4dCBmb3IgZXJyb3Ig Y291bnRlcnMuCiAgPC9wcm9wb3NhbD4KCkl0IGlzIHVuY2xlYXIgd2hldGhlciBpdCdzIHVzZWZ1 bCB0byBkaXNjdXNzIGNvbnRleHQgaGVyZSBhdCBhbGwuCgoKU2VjdGlvbiA1LjEKICBNb3N0IG9m IHRoaXMgZGVzY3JpcHRpb24gaXMgY29uY2VybmVkIHdpdGggd2hhdCBzaG91bGQgYmUgZG9uZQp3 aGVuIGFjY2VwdGluZyBhIG5ldyBpbmNvbWluZyBTU0ggY29ubmVjdGlvbi4gIE9uY2Ugc3VjaCBh IGNvbm5lY3Rpb24KaGFzIGJlZW4gZXN0YWJsaXNoZWQsIGl0J3MgcHJvYmFibHkgbm90IG5lY2Vz c2FyeSB0byByZXBlYXQgYWxsIHRoaXMKcHJvY2Vzc2luZyBmb3IgZXZlcnkgc3Vic2VxdWVudCBt ZXNzYWdlIHJlY2VpdmVkIG9uIHRoZSBzYW1lIGNvbm5lY3Rpb24uCiAgSXQgd291bGQgYmUgdXNl ZnVsIHRvIHNlcGFyYXRlIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2Vzc2luZwpyZXF1aXJl ZCBmb3IgYWNjZXB0aW5nIGFuIGluY29taW5nIGNvbm5lY3Rpb24sIGZyb20gdGhhdCBmb3IgaGFu ZGxpbmcKYW4gaW5jb21pbmcgbWVzc2FnZS4KCiAgPHByb3Bvc2FsPgogICAgIDUuMS4gICBQcm9j ZWR1cmUgZm9yIGFjY2VwdGluZyBhbiBpbmNvbWluZyBTU0ggc2Vzc2lvbgoKICAgVGhlIFNTSCBU cmFuc3BvcnQgTW9kZWwgcHJvdmlkZXMgdGhlIGZvbGxvd2luZyBhYnN0cmFjdCBzZXJ2aWNlCiAg IGludGVyZmFjZSAoQVNJKSB0byBkZXNjcmliZSB0aGUgZGF0YSBwYXNzZWQgYmV0d2VlbiB0aGUg U1NICiAgIHNlcnZpY2UgYW5kIHRoZSBTU0ggVHJhbnNwb3J0IE1vZGVsLiAgSXQgaXMgYW4gaW1w bGVtZW50YXRpb24KICAgZGVjaXNpb24gaG93IHN1Y2ggZGF0YSBpcyBwYXNzZWQuCgogICAgIGFj Y2VwdFNlc3Npb24oCiAgICAgICBJTiAgc291cmNlVHJhbnNwb3J0QWRkcmVzcwogICAgICAgSU4g IHNzaFByaW5jaXBhbAogICAgICAgSU4gIHNzaFNlc3Npb25JRAogICAgICAgT1VUIHRtU3RhdGVS ZWZlcmVuY2UKICAgICApCgogICBUaGUgZm9sbG93aW5nIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJl IHRvIGZvbGxvdyB3aGVuIGVzdGFibGlzaGluZwogICBhbiBpbmNvbWluZyBzZXNzaW9uIHRvIHJ1 biBTTk1QIG92ZXIgU1NILiAgVGhpcyB3aWxsIGJlIGRvbmUKICAgYXV0b21hdGljYWxseSBmb3Ig YW4gU05NUCBhcHBsaWNhdGlvbiB0aGF0IHJlY2VpdmVzIGFuIHVuc29saWNpdGVkCiAgIHRyYW5z YWN0aW9uLCBzdWNoIGFzIGEgQ29tbWFuZCBSZXNwb25kZXIsIG9yIGEgTm90aWZpY2F0aW9uIFJl Y2VpdmVyLgoKICAgMSkgUXVlcnkgdGhlIFNTSCBlbmdpbmUsIGluIGFuIGltcGxlbWVudGF0aW9u LWRlcGVuZGVudCBtYW5uZXIsCiAgICAgIHRvIGRldGVybWluZSB0aGUgdHJhbnNwb3J0QWRkcmVz cyB0aGF0IGluaXRpYXRlZCB0aGUgY29ubmVjdGlvbiwKICAgICAgdGhlIHByaW5jaXBhbCBuYW1l IGF1dGhlbnRpY2F0ZWQgYnkgU1NIIGFuZCBhIHNlc3Npb24gaWRlbnRpZmllci4KCiAgICAgIEJ5 IGRlZmF1bHQsIHRoZSBwcmluY2lwYWwgbmFtZSB3aWxsIGJlIHRoZSB2YWx1ZSBvZiB0aGUKICAg ICAgdXNlciBuYW1lIGZpZWxkIG9mIHRoZSBTU0hfTVNHX1VTRVJBVVRIX1JFUVVFU1QsIGZvciB3 aGljaAogICAgICBhIFNTSF9NU0dfVVNFUkFVVEhfU1VDQ0VTUyB3YXMgc2VudC4gIEhvdyB0aGlz IG5hbWUgaXMKICAgICAgZXh0cmFjdGVkIGZyb20gdGhlIFNTSCBlbnZpcm9ubWVudCBpcyBpbXBs ZW1lbnRhdGlvbi1kZXBlbmRlbnQuCgogICAyKSBEZXRlcm1pbmUgdGhlIHRtU2VjdXJpdHlOYW1l IGNvcnJlc3BvbmRpbmcgdG8gdGhlIHNzaFByaW5jaXBhbAogICAgICBwYXJhbWV0ZXIuICBJZiB0 aGUgU1NIIFRyYW5zcG9ydCBNb2RlbCBpcyB1c2luZyB0aGUgaWRlbnRpdHkKICAgICAgbWFwcGlu ZyAoYXMgaW5kaWNhdGVkIGJ5IHRoZSBzc2h0bUxDRFRyYW5zZm9ybVBvbGljeSBvYmplY3QpLAog ICAgICB0aGlzIHdpbGwgYmUgdGhlIHNhbWUgYXMgdGhlIHNzaFByaW5jaXBhbCBwYXJhbWV0ZXIu ICBPdGhlcndpc2UsCiAgICAgIHRoZSB0bVNlY3VyaXR5TmFtZSBzaG91bGQgYmUgZGV0ZXJtaW5l ZCBieSBhbiBpbXBsZW1lbnRhdGlvbi0KICAgICAgc3BlY2lmaWMgbWFwcGluZyBhbGdvcml0aG0u CgogICAgICAgICBbW1sgWFhYIC0gSG93IC0gdmlhIGEgcmV2ZXJzZS1sb29rdXAgaW4gc3NtdG1M Q0RUYWJsZT8gXV1dCgogICAzKSBDcmVhdGUgYSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlIGNvbnRh aW5pbmcgdGhlIGZvbGxvd2luZyB2YWx1ZXM6CgogICAgICAgICB0cmFuc3BvcnREb21haW4gICA9 IHNubXBTU0hEb21haW4gIChkZWZpbmVkIGluIFNTSC1UTSwgc2VlIHNlY3Rpb24gNykKICAgICAg ICAgdHJhbnNwb3J0QWRkcmVzcyAgPSBzb3VyY2VUcmFuc3BvcnRBZGRyZXNzIHBhcmFtZXRlcgog ICAgICAgICB0bVNlY3VyaXR5TmFtZSAgICA9IHRoZSB2YWx1ZSBkZXRlcm1pbmVkIGluIHN0ZXAg MikgYWJvdmUKICAgICAgICAgdG1UcmFuc3BvcnRTZWN1cml0eUxldmVsID0gYXV0aFByaXYKICAg ICAgICAgdG1TZXNzaW9uSUQgICAgICAgPSBzc2hTZXNzaW9uSUQgcGFyYW1ldGVyCgogICA0KSBD cmVhdGUgYW4gZW50cnkgaW4gdGhlIHNzaHRtTENEVGFibGUgY29udGFpbmluZyB0aGUgdmFsdWVz OgoKICAgICAgICAgc3NodG1UcmFuc3BvcnRBZGRyZXNzICA9IHNvdXJjZVRyYW5zcG9ydEFkZHJl c3MgcGFyYW1ldGVyCiAgICAgICAgIHNzaHRtTENEVG1TZWN1cml0eU5hbWUgPSB0bVNlY3VyaXR5 TmFtZSAoZnJvbSBzdGVwIDIpIGFib3ZlKQogICAgICAgICBzc2h0bUxDRFByaW5jaXBhbCAgICAg ID0gc3NoUHJpbmNpcGFsIHBhcmFtZXRlcgogICAgICAgICBzc2h0bUxDRFNlc3Npb25JRCAgICAg ID0gc3NoU2Vzc2lvbklEIHBhcmFtZXRlcgogICAgICAgICBzc2h0bVN0b3JhZ2VUeXBlICAgICAg ID0gdm9sYXRpbGUoMikKICAgICAgICAgc3NodG1Sb3dTdGF0dXMgICAgICAgICA9IGNyZWF0ZUFu ZEdvKDQpCgogICAgUmV0dXJuIHRoZSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlIGZvciB0aGlzIHNl c3Npb24uCgogICAgIDUuMi4gICBQcm9jZWR1cmUgZm9yIGFuIGluY29taW5nIG1lc3NhZ2UKCiAg ICBSZXRyaWV2ZSB0aGUgdG1TdGF0ZVJlZmVyZW5jZSBmb3IgdGhlIFNTSCBzZXNzaW9uIHVzZWQg dG8gcmVjZWl2ZQogICAgdGhlIGluY29taW5nIG1lc3NhZ2UuICAgIFBhc3MgdGhlIG1lc3NhZ2Ug dG8gdGhlIERpc3BhdGNoZXIgdXNpbmcKICAgIHRoZSBmb2xsb3dpbmcgQVNJOgoKICAgICAgc3Rh dHVzSW5mb3JtYXRpb24gPQogICAgICByZWNlaXZlTWVzc2FnZSgKICAgICAgICAgSU4gICAgdHJh bnNwb3J0RG9tYWluICAgICAtLSBzbm1wU1NIRG9tYWluCiAgICAgICAgIElOICAgIHRyYW5zcG9y dEFkZHJlc3MgICAgLS0gZnJvbSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlCiAgICAgICAgIElOICAg IHdob2xlTWVzc2FnZQogICAgICAgICBJTiAgICB3aG9sZU1lc3NhZ2VMZW5ndGgKICAgICAgICAg SU4gICAgdG1TdGF0ZVJlZmVyZW5jZQogICAgICApCiAgPC9wcm9wb3NhbD4KClFuOiBDb3VsZCBh IHJvdyBleGlzdCBpbiB0aGUgc3NodG1MQ0RUYWJsZSBiZWZvcmUgdGhlIGNvcnJlc3BvbmRpbmcg U1NICiAgICBzZXNzaW9uIHdhcyBlc3RhYmxpc2hlZCAoZS5nLiB0byBwcmUtY29uZmlndXJlIGEg c3VpdGFibGUgbWFwcGluZwogICAgYmV0d2VlbiBTU0ggcHJpbmNpcGFsIGFuZCB0bVNlY3VyaXR5 TmFtZSkuCiAgICAgIE9yIHdvdWxkIGNyZWF0aW5nIHN1Y2ggYSByb3cgYXV0b21hdGljYWxseSBl c3RhYmxpc2ggdGhlIGNvbm5lY3Rpb24/CgogICAgSW4gZWl0aGVyIGNhc2UsIHByZXN1bWFibHkg ZXN0YWJsaXNoaW5nIHRoZSBzZXNzaW9uIHNob3VsZCBzZXQgdGhlCiAgICB2YWx1ZSBmb3IgdG1T ZXNzaW9uSUQgKGFuZCBwZXJoYXBzIG1ha2UgdGhlIHJvdyBhY3RpdmUpCgpRbjogV291bGQgaXQg YmUgc2Vuc2libGUgdG8gaGF2ZSBhIHNlcGFyYXRlIHNzaHRtU2Vzc2lvbkFjY2VwdHMgY291bnRl cj8KICAgIE9yIHNob3VsZCBpbmNvbWluZyBzZXNzaW9ucyBiZSBpbmNsdWRlZCBpbiBzc2h0bVNl c3Npb25PcGVucz8KCgpTZWN0aW9uIDUuMwogIFRoZSBkZXNjcmlwdGlvbiBpcyBzb21ld2hhdCBj b25mdXNpbmcgaW4gcGxhY2VzLCBhbmQgd291bGQgYmVuZWZpdApmcm9tIGEgc2xpZ2h0IHNpbXBs aWZpY2F0aW9uIGFuZCBjbGFyaWZpY2F0aW9uLiAgU29tZSBvZiB0aGUgcHJvY2Vzc2luZwpzcGVj aWZpZWQgaXMgYWN0dWFsbHkgcmVsYXRlZCB0byBzZW5kaW5nIGFuIG91dGdvaW5nIG1lc3NhZ2Us IHJhdGhlcgp0aGFuIG9wZW5pbmcgYSBuZXcgU1NIIHNlc3Npb24uCiAgVGhlIG1heE1lc3NhZ2VT aXplIElOIHBhcmFtZXRlciBpcyBuZXZlciBhY3R1YWxseSB1c2VkLgogIFRoZXJlIGlzIG5vIG1l Y2hhbmlzbSBmb3IgcmV0dXJuaW5nIHRoZSBTU0ggc2Vzc2lvbgogIAogIDxwcm9wb3NhbD4KICAg ICBwYXJhZ3JhcGggMQogICBzL2FwcGxpY2F0aW9uIHNlcnZpY2UgaW50ZXJmYWNlL2Fic3RyYWN0 IHNlcnZpY2UgaW50ZXJmYWNlLwoKICAgICBBU0kgZGVmaW5pdGlvbgogICBkL0lOICBtYXhNZXNz YWdlU2l6ZS8KICAgYS9PVVQgc3NoU2Vzc2lvbi8KCiAgICAgc3RlcCAxKQogICBzL3VzaW5nIHRo ZSBTU0ggdHJhbnNwb3J0IHByb3RvY29sLy8KICAgcy91c2VkIHRvIGF1dGhlbnRpY2F0ZS91c2Vk IHRvIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyLwogICBzL2FuZCBhbiBPcGVuU2Vzc2lvbiBlcnJv ciBpbmRpY2F0aW9uL2FuIGVycm9yIGluZGljYXRpb24vCgogCiAgIDIpIElmIHNzaHRtTENEVHJh bnNmb3JtUG9saWN5IGlzIGRlZmF1bHQsIHRoZSBTU0ggcHJpbmNpcGFsIGlzIHNldAogICAgICB0 byB0bVNlY3VyaXR5TmFtZS4gIE90aGVyd2lzZSwgdGhlIFNTSCBwcmluY2lwYWwgaXMgY2FsY3Vs YXRlZAogICAgICBmcm9tIHRtU2VjdXJpdHlOYW1lIHVzaW5nIHRoZSBpbXBsZW1lbnRhdGlvbi1z cGVjaWZpYyBtYXBwaW5nCiAgICAgIGFsZ29yaXRobS4KCiAgICAgIFRoaXMgcHJpbmNpcGFsIGlz IHBhc3NlZCB0byB0aGUgU1NIIGxheWVyIGZvciBhdXRoZW50aWNhdGlvbi4KICAgICAgVGhlIGNy ZWRlbnRpYWxzIGFuZCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIHRvIHVzZSBhcmUgZGV0ZXJtaW5l ZAogICAgICBpbiBhbiBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQgbWFubmVyLgoKICAgICAgSWYg YXV0aGVudGljYXRpb24gaXMgdW5zdWNjZXNzZnVsLCB0aGVuIHRoZSB0cmFuc3BvcnQgY29ubmVj dGlvbgogICAgICBpcyBjbG9zZWQsIHRoZSBzc2h0bVNlc3NzaW9uVXNlckF1dGhGYWlsdXJlcyBj b3VudGVyIGlzCiAgICAgIGluY3JlbWVudGVkLCBhbiBlcnJvciBpbmRpY2F0aW9uIGlzIHJldHVy bmVkIHRvIHRoZSBjYWxsaW5nCiAgICAgIG1vZHVsZSwgYW5kIE9wZW5TZXNzaW9uIHByb2Nlc3Np bmcgc3RvcHMuCgogICAzKSBPbmNlIHRoZSBwcmluY2lwYWwgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IGF1dGhlbnRpY2F0ZWQsIHRoZQogICAgICBjbGllbnQgc2hvdWxkIGludm9rZSB0aGUgInNzaC1j b25uZWN0aW9uIiBzZXJ2aWNlLCByZXF1ZXN0IGEKICAgICAgY2hhbm5lbCBvZiB0eXBlICJzZXNz aW9uIiwgW2FuZCBzZXQgdXAgYW4gInNubXAiIHN1YnN5c3RlbV0uCiAgICAgIElmIHVuc3VjY2Vz c2Z1bCwgdGhlbiB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gaXMgY2xvc2VkLCB0aGUKICAgICAg c3NodG1TZXNzc2lvbkNoYW5uZWxPcGVuRmFpbHVyZXMgY291bnRlciBpcyBpbmNyZW1lbnRlZCwg YW4KICAgICAgZXJyb3IgaW5kaWNhdGlvbiBpcyByZXR1cm5lZCB0byB0aGUgY2FsbGluZyBtb2R1 bGUsIGFuZAogICAgICBPcGVuU2Vzc2lvbiBwcm9jZXNzaW5nIHN0b3BzLgoKICAgNCkgSWYgc3Vj Y2Vzc2Z1bCwgdGhpcyB3aWxsIHJlc3VsdCBpbiBhbiBTU0ggc2Vzc2lvbi4gIENyZWF0ZSBhbgog ICAgICBlbnRyeSBpbiB0aGUgc3NodG1MQ0RUYWJsZSwgaW5kZXhlZCBieSBkZXN0VHJhbnNwb3J0 QWRkcmVzcwogICAgICBhbmQgdG1TZWN1cml0eU5hbWUsIGNvbnRhaW5pbmcKCiAgICAgICAgIHNz aHRtTENEUHJpbmNpcGFsID0gdGhlIFNTSCBwcmluY2lwYWwgZGV0ZXJtaW5lZCBpbiBzdGVwIDIp CiAgICAgICAgIHNzaHRtTENEU2Vzc2lvbklEID0gdGhlIElEIG9mIHRoZSBzZXNzaW9uIGp1c3Qg ZXN0YWJsaXNoZWQKCiAgICAgIFRoZSBzc2h0bVNlc3Npb25PcGVucyBjb3VudGVyIHNob3VsZCBi ZSBpbmNyZW1lbnRlZCwgYW5kIHRoZQogICAgICBTU0ggc2Vzc2lvbiByZXR1cm5lZCB0byB0aGUg Y2FsbGluZyBtb2R1bGUuCiAgPC9wcm9wb3NhbD4KClFuOiBUaGUgZGlzY3Vzc2lvbiBvZiBTU0gg c3Vic3lzdGVtcyBpcyBzb21ld2hhdCB1bmNsZWFyLCBidXQgZmVlbHMgCiAgICBtb3JlIGxpa2Ug aW1wbGVtZW50YXRpb24vY29uZmlndXJhdGlvbiByZWNvbW1lbmRhdGlvbnMgcmF0aGVyCiAgICB0 aGFuIEVsZW1lbnRzIG9mIFByb2NlZHVyZS4gIEl0IG1pZ2h0IHBlcmhhcHMgYmUgYmV0dGVyIGlu Y2x1ZGVkCiAgICBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50LiAgV2hlcmU/CgpRbjogU2hvdWxk IGEgZmFpbHVyZSB0byBzZXQgdXAgYW4gInNubXAiIHN1YnN5c3RlbSB0cmlnZ2VyIGEKICAgIFNl c3Npb25DaGFubmVsT3BlbkZhaWx1cmUgZXJyb3I/CgpRbjogVGhpcyB0ZXh0IGFsc28gcmVmZXJz IHRvIGFuIElBTkEtYXNzaWduZWQgVENQIHBvcnQsIGJ1dCB0aGlzIGlzCiAgICBuZXZlciBkaXNj dXNzZWQgYW55d2hlcmUgaW4gdGhpcyBkb2N1bWVudC4KCgpTZWN0aW9uIDUuMgogIEl0IG1pZ2h0 IGJlIG1vcmUgc2Vuc2libGUgdG8gZGlzY3VzcyB0aGUgcHJvY2Vzc2luZyBvZiBvdXRnb2luZwpt ZXNzYWdlcyAqYWZ0ZXIqIHRoZSBwcm9jZWR1cmVzIGZvciBvcGVuaW5nIGEgc2Vzc2lvbiAoZm9s bG93aW5nCnRoZSBtb2RlbCBvZiBhY2NlcHRpbmcgYSBzZXNzaW9uL3JlY2VpdmluZyBhIG1lc3Nh Z2UgYWJvdmUpLgoKVGhlcmUgaXMgbm8gcHJvdmlzaW9uIGluIHRoZSBzc2h0bUxDRFRhYmxlIGZv ciBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYwpwYXJhbWV0ZXJzIC0gdXNpbmcgdGhlIE1JQiB0YWJs ZSBmb3IgdGhpcyBzZWVtcyBpbmFwcHJvcHJpYXRlLgoKICA8cHJvcG9zYWw+CiAgICAgNS40LiAg UHJvY2VkdXJlIGZvciBzZW5kaW5nIGFuIE91dGdvaW5nIE1lc3NhZ2UKCiAgIDEpIFVzZSB0aGUg dHJhbnNwb3J0QWRkcmVzcyBhbmQgdG1TZWN1cml0eU5hbWUgZnJvbSB0aGUKICAgICAgdG1TdGF0 ZVJlZmVyZW5jZSB0byBkZXRlcm1pbmUgaWYgYSBjb3JyZXNwb25kaW5nIHJvdwogICAgICBleGlz dHMgaW4gdGhlIHNzaHRtTENEVGFibGUuCiAgICAgICAKICAgMikgSWYgdGhlcmUgaXMgc3VjaCBh IHJvdywgZXh0cmFjdCB0bVNhbWVTZXNzaW9uIGFuZCB0bVNlc3Npb25JRAogICAgICBmcm9tIHRo ZSB0bVN0YXRlUmVmZXJlbmNlIGNhY2hlLiAgSWYgdG1TYW1lU2Vzc2lvbiBpcyB0cnVlLAogICAg ICBhbmQgdG1TZXNzaW9uSUQgZG9lcyBub3QgbWF0Y2ggc3NodG1MQ0RTZXNzaW9uSUQsIC4uLi4K CiAgIDMpIElmIHRoZXJlIGlzIG5vIHN1Y2ggcm93LCB0aGVuIGNhbGwgT3BlblNlc3Npb24gd2l0 aAogICAgICB0cmFuc3BvcnRBZGRkcmVzcyBhbmQgdG1TZWN1cml0eU5hbWUgYXMgcGFyYW1ldGVy cy4KICAgICAgSWYgT3BlblNlc3Npb24gZmFpbHMsIHRoZW4gZGlzY2FyZCB0aGUgbWVzc2FnZSwg cmVsZWFzZQogICAgICB0bVN0YXRlUmVmZXJlbmNlIGFuZCBwYXNzIHRoZSBlcnJvciBpbmRpY2F0 aW9uIHJldHVybmVkCiAgICAgIGJ5IE9wZW5TZXNzaW9uIGJhY2sgdG8gdGhlIGNhbGxpbmcgbW9k dWxlLgogICAgICBQcm9jZXNzaW5nIHN0b3BzIGZvciB0aGlzIG1lc3NhZ2UuCgogICA0KSBQYXNz IHRoZSBvdXRnb2luZ01lc3NhZ2UgdG8gU1NIIGZvciBlbmNhcHN1bGF0aW9uIGFzCiAgICAgIGRh dGEgaW4gYW4gU1NIIG1lc3NhZ2Ugb3ZlciB0aGUgc3BlY2lmaWVkIFNTSCBzZXNzaW9uCiAgICAg IChyZXR1cm5lZCBmcm9tIE9wZW5TZXNzaW9uIG9yIGlkZW50aWZpZWQgYnkgdG1TZXNzaW9uSUQp LgogICAgICBBbnkgbmVjZXNzYXJ5IGFkZGl0aW9uYWwgU1NILXNwZWNpZmljIHBhcmFtZXRlcnMg c2hvdWxkCiAgICAgIGJlIHByb3ZpZGVkIGluIGFuIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudCBt YW5uZXIuCiAgPC9wcm9wb3NhbD4KClFuOiBUaGlzIGRlc2NyaXB0aW9uIHVzZXMgdHJhbnNwb3J0 QWRkcmVzcyBmcm9tIHRoZSB0bVN0YXRlUmVmZXJlbmNlCiAgICBjYWNoZSwgcmF0aGVyIHRoYW4g dGhlIElOIHBhcmFtZXRlciAoZGVzdFRyYW5zcG9ydEFkZHJlc3MpLgogICAgSXMgdGhpcyBJTiBw YXJhbWV0ZXIgZXZlciB1c2VkLCBvciBzaW1wbHkgaWdub3JlZD8KClFuOiBIb3cgc2hvdWxkIHRo aXMgQVNJIGhhbmRsZSBhbiBpbmNvbXBsZXRlL2ludmFsaWQgdG1TdGF0ZVJlZmVyZW5jZQogICAg Y2FjaGU/ICBPciBpcyBzdWNoIGFuIG9jY3VycmFuY2UgU2ltcGx5IE5vdCBQb3NzaWJsZT8KCgpT ZWN0aW9uIDUuNApRbjogSXMgJ2Nsb3NlU2Vzc2lvbicgaW52b2tlZCAoY29uY2VwdHVhbGx5KSBm b3IgcmVtb3RlLWluaXRpYXRlZAogICAgc2Vzc2lvbiB0ZXJtaW5hdGlvbiBhcyB3ZWxsPwoKClNl Y3Rpb24gNgoKICA8cHJvcG9zYWw+CiAgICAgVGhpcyBNSUIgbW9kdWxlIHByb3ZpZGVzIG1hbmFn ZW1lbnQgb2YgdGhlIFNlY3VyZSBTaGVsbCBUcmFuc3BvcnQKICAgTW9kZWwuICBJdCBkZWZpbmVz IGFuIE9JRCB0byBpZGVudGlmeSB0aGUgU05NUC1vdmVyLVNTSCB0cmFuc3BvcnQKICAgZG9tYWlu LCBhIHRleHR1YWwgY29udmVudGlvbiBmb3IgU1NIIEFkZHJlc3Nlcywgc2V2ZXJhbCBzdGF0aXN0 aWNzCiAgIGNvdW50ZXJzIGFuZCBhIE1JQiB0YWJsZSByZXByZXNlbnRpbmcgdGhlIFNTSCBUcmFu c3BvcnQgTW9kZWwgTG9jYWwKICAgQ29uZmlndXJhdGlvbiBEYXRhc3RvcmUgKExDRCkuCiAgPC9w cm9wb3NhbD4KCgpTZWN0aW9uIDYuMwogIFRoZSBUcmFuc3BvcnQgc3VzYnN5c3RlbSBkb2N1bWVu dCBkb2VzIG5vdCBkZWZpbmUgYSBNSUIgbW9kdWxlLgoKVGhlIHNlY29uZCBwYXJhZ3JhcGggdGFs a3MgYWJvdXQgd2hhdCB0aGlzIE1JQiBwcm92aWRlcyAocmF0aGVyIHRoYW4KaXRzIHJlbGF0aW9u c2hpcCB3aXRoIG90aGVyIE1JQiBtb2R1bGVzKS4gIFRoaXMgaGFzIGFscmVhZHkgYmVlbgpjb3Zl cmVkIGF0IHRoZSBzdGFydCBvZiB0aGlzIG1haW4gc2VjdGlvbi4KCkl0IG1pZ2h0IGFsc28gYmUg d29ydGggbWVudGlvbmluZyB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsLgoKICA8cHJvcG9z YWw+CiAgICAgcy9hbmQgdGhlIFNOTVAtVFJBTlNQT1JULU1JQiBbSS1ELmlldGYtaXNtcy10bXNt XS8vCgogICAgIEl0IGlzIGV4cGVjdGVkIHRoYXQgYW4gZW50aXR5IGltcGxlbWVudGluZyB0aGlz IE1JQiB3aWxsCiAgIGFsc28gc3VwcG9ydCB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsIFtJ LUQuaWV0Zi1pc21zLXRzbV0sCiAgIGFuZCB0aGVyZWZvcmUgaW1wbGVtZW50IHRoZSBTTk1QLVRT TS1NSUIuCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDcsIFNubXBTU0hBZGRyZXNzIGRlZmluaXRp b24KCiAgPHByb3Bvc2FsPgogICAgcGFyYWdyYXBoIDMKICAgICAgcy9hIGRvdHRlZCBkZWNpbWFs L2luIGRvdHRlZCBkZWNpbWFsLwogICAgcGFyYWdyYXBoIDQKICAgICAgcy9zdXJyb3VuZGVkIGJ5 IGJyYWNrZXRzL3N1cnJvdW5kZWQgYnkgc3F1YXJlIGJyYWNrZXRzLwogICAgcGFyYWdyYXBoIDUK ICAgICAgcy9tYXkgbm90IGJlIHVzZWFibGUvbWF5IG5vdCBuZWNlc3NhcmlseSBiZSB1c2VhYmxl LwogICAgICAgICAod2FybmluZywgcmF0aGVyIHRoYW4gcHJvaGliaXRpb24pCiAgICBSZWZlcmVu Y2UKICAgICAgcy9SRkMzODk2L1JGQzM5ODYvCiAgPC9wcm9wb3NhbD4KClFuOiAgVGhlIHB1cnBv c2Ugb2YgcGFyYWdyYXBoIDcgaXMgbm90IHBhcnRpY3VsYXJseSBjbGVhci4KICAgICBJZiB0aGUg VEMgc2hvdWxkIG5vdCBiZSB1c2VkLCB0aGVuIHdoYXQgaXMgdGhlIHBvaW50CiAgICAgb2YgcHJv dmlkaW5nIHRoaXMgZGVmaW5pdGlvbj8KClFuOiAgVGhpcyB0eXBlIGlzIGRlc2NyaWJlZCBwdXJl bHkgaW4gdGVybXMgb2YgSVAgYWRkcmVzc2VzCiAgICAgKG9yIGhvc3RuYW1lcykuICBJcyBpdCBp bnRlbmRlZCB0byBzdXBwb3J0IFNTSC1vdmVyLW5vbklQCiAgICAgdHJhbnNwb3J0cyBhcyB3ZWxs PwogICAgIElmIG5vdCwgc2hvdWxkIHRoZSBzbm1wU1NIRG9tYWluIGRlc2NyaXB0aW9uICg/YW5k IG5hbWUpCiAgICAgYmUgIHR3ZWFrZWQgdG8gbWFrZSB0aGlzIHJlc3RyaWN0aW9uIGV4cGxpY2l0 PwoKClNlY3Rpb24gNywgc3NodG1MQ0RTcGluTG9jawogIFRoZSBjb21tZW50IGltbWVkaWF0ZWx5 IGJlZm9yZSB0aGUgc3NtdG1MQ0RTcGluTG9jayBkZWZpbml0aW9uCmZlZWxzIGxpa2UgYSBjdXQt YW5kLXBhc3RlIGVycm9yIGZyb20gdGhlIFNOTVAtVFNNLU1JQi4KCiAgPC9wcm9wb3NhbD4KICAg ICAgRGVsZXRlIHRoZXNlIHR3byBsaW5lcwogIDxwcm9wb3NhbD4KCgpTZWN0aW9uIDcsIHNzaHRt TENEVGFibGUgZGVmaW5pdGlvbgogIFRoZSBpbmRleCB2YWx1ZXMgKFRyYW5zcG9ydEFkZHJlc3Mg YW5kIFRtU2VjdXJpdHlOYW1lKSBhcmUgZGVmaW5lZAphcyAibm90LWFjY2Vzc2libGUiLCBzbyBz aG91bGQgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBleGFtcGxlIFNFVC4KClFuOiAgV2hhdCBpcyB0 aGUgaW50ZW5kZWQgYmVoYXZpb3VyIG9mIGNyZWF0aW5nIGFuIGVudHJ5IGluIHRoaXMgdGFibGU/ CiAgICAgU2hvdWxkIHRoYXQgYXR0ZW1wdCB0byBvcGVuIGEgY29ycmVzcG9uZGluZyBTU0ggc2Vz c2lvbgogICAgIGF1dG9tYXRpY2FsbHksIG9yIHdvdWxkIFNOTVAtY3JlYXRlZCByb3dzIGJlIHVz ZWQgdG8gcHJlLWNvbmZpZ3VyZQogICAgIGEgbm9uLWlkZW50aXR5IG1hcHBpbmcgYmV0d2VlbiBT U0ggcHJpbmNpcGFsIGFuZCB0bVNlY3VyaXR5TmFtZT8KCkl0J3Mgbm90IGNsZWFyIGhvdyBhbiBl eHRlcm5hbCBTTk1QIGNvbW1hbmQgY291bGQgcG9zc2libHkga25vdyB0aGUKYXBwcm9wcmlhdGUg U1NIIHNlc3Npb24gSUQgdG8gc3BlY2lmeSBmb3IgYSBmdXR1cmUgU1NIIHNlc3Npb24gKGFuZAp0 aGUgc3BpbkxvY2sgdmFsdWUgaXMgYWxtb3N0IGd1YXJhbnRlZWQgdG8gYmUgd3JvbmchKS4KICBJ dCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIG9taXQgdGhpcyB2YXJiaW5kLCBhbmQgbGVh dmUgdGhlClNTSCB0cmFuc3BvcnQgbW9kZWwgdG8gc3VwcGx5IHRoZSBhcHByb3ByaWF0ZSB2YWx1 ZS4KCiAgPHByb3Bvc2FsPgogICAgIHMvc3NodG1MQ0RUcmFuc3BvcnRBZGRyZXNzPShkZXNpcmVk IHZhbHVlKSwvLwogICAgIHMvc3NodG1MQ0RUbVNlY3VyaXR5TmFtZT0oZGVzaXJlZCB2YWx1ZSks Ly8KICAgICBzL3NzaHRtTENEU2Vzc2lvbklEPXNWYWx1ZSwvLwogIDwvcHJvcG9zYWw+CgoKU2Vj dGlvbiA3LCBzc2h0bUxDRFRtU2VjdXJpdHlOYW1lCgogIDwvcHJvcG9zYWw+CiAgICBBIGh1bWFu IHJlYWRhYmxlIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIHRyYW5zcG9ydC1hdXRoZW50aWNhdGVk CiAgICBpZGVudGl0eSB0byBib3RoIHRoZSBUcmFuc3BvcnQgYW5kIFNlY3VyaXR5IE1vZGVscy4g SXQgaXMgcGFzc2VkCiAgICBiZXR3ZWVuIHRoZW0gYXMgdG1TZWN1cml0eU5hbWUuCgogICAgVGhp cyBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgc2FtZSBhcyBzc2h0bUxDRFByaW5jaXBhbC4KICA8cHJv cG9zYWw+CgpRbjogSG93IHdvdWxkIHRoZSBkZWZpbml0aW9uIG9mIHRoaXMgb2JqZWN0IGJlIGFm ZmVjdGVkIGJ5IHRoZSBwcm9wb3NlZAogICAgdXNlIG9mIHRyYW5zcG9ydC1wcmVmaXhlcyBpbiB0 aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsCiAgICB0bVNlY3VyaXR5TmFtZSA8LT4gc2VjdXJp dHlOYW1lIG1hcHBpbmc/CgogICAgU2hvdWxkIHRoZSBzaXplIG9mIHRoaXMgb2JqZWN0IGJlIHJl ZHVjZWQsIG9yIHNob3VsZCB0aGUgcHJlZml4IGJlCiAgICBhZGRlZCBieSB0aGUgVHJhbnNwb3J0 IE1vZGVsIGl0c2VsZj8KCgpTZWN0aW9uIDcsIHNzaHRtTENEUHJpbmNpcGFsCgogIDwvcHJvcG9z YWw+CiAgICBBIGh1bWFuIHJlYWRhYmxlIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIHRyYW5zcG9y dC1hdXRoZW50aWNhdGVkCiAgICBpZGVudGl0eSBpbiBhbiBpbXBsZW1lbnRhdGlvbi1zcGVjaWZp YyBtYW5uZXIuICBJdCBpcyBvbmx5IHVzZWQKICAgIHdpdGhpbiB0aGUgU1NIIFRyYW5zcG9ydCBN b2RlbCBpdHNlbGYsIGFuZCBpcyB0eXBpY2FsbHkgdGhlIFNTSAogICAgdXNlciBuYW1lLgoKICAg IFRoaXMgbWF5IG9yIG1heSBub3QgYmUgdGhlIHNhbWUgYXMgc3NodG1MQ0RUbVNlY3VyaXR5TmFt ZS4KICA8cHJvcG9zYWw+CgoKU2VjdGlvbiA3LCBzc2h0bUxDRFNlc3Npb25JRAogIFRoZSBkZWZp bml0aW9uIGZvciB0aGlzIG9iamVjdCBpcyBtaXNzaW5nIGFsdG9nZXRoZXIhICBJIHN1c3BlY3QK dGhhdCB0aGlzIGNvbHVtbiBzaG91bGQgcHJvYmFibHkgYmUgZGVmaW5lZCBhcyAncmVhZC1vbmx5 JyAoYW5kCmRvY3VtZW50ZWQgYXMgYmVpbmcgcHJvdmlkZWQgYnkgdGhlIFNTSCBlbmdpbmUpLgoK ClNlY3Rpb24gNywgc3NodG1MQ0RSb3dTdGF0dXMKUW46IERvZXMgdGhlIHZhbHVlIG9mIHRoaXMg b2JqZWN0ICgnYWN0aXZlJyB2cyAnbm90SW5TZXJ2aWNlJykKICAgIGluZGljYXRlIHdoZXRoZXIg dGhlcmUgaXMgYSBjb3JyZXNwb25kaW5nIGVzdGFibGlzaGVkIFNTSCBzZXNzaW9uPwogICAgSWYg c28sIHRoZW4gaXQgd291bGQgYmUgc2Vuc2libGUgdG8gZG9jdW1lbnQgdGhpcy4KClFuOiBUaGUg ZGVzY3JpcHRpb24gc3RhdGVzIHRoYXQgdGhlIHByaW5jaXBhbCB2YWx1ZSBjYW4gb25seSBiZSBj aGFuZ2VkCiAgICB3aGVuIHRoZSByb3cgaXMgJ2FjdGl2ZScuICBJcyBpdCByZWFsaXN0aWMgdG8g dHJ5IGFuZCBjaGFuZ2UgdGhlCiAgICB0cmFuc3BvcnQtYXV0aGVudGljYXRlZCBpZGVudGl0eSBv bmNlIHRoZSBzZXNzaW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkPwoKSXQgd291bGQgc2VlbSBtb3Jl IG5hdHVyYWwgZWl0aGVyIHRvIG9ubHkgYWxsb3cgY2hhbmdpbmcgdGhlIHByaW5jaXBhbCBmb3IK aW5hY3RpdmUgcm93cyAoaS5lLiB3aGVuIHByZXBhcmluZyB0aGUgY29uZmlndXJhdGlvbiBzZXR0 aW5ncyBmb3IgZnV0dXJlCmNvbm5lY3Rpb25zKSwgb3IgdG8gZm9yYmlkIGFtZW5kaW5nIGV4aXN0 aW5nIHJvd3MgKGFwYXJ0IGZyb20gZGVsZXRpbmcKdGhlIHJvdyBhbHRvZ2V0aGVyKS4KClFuOiBT aG91bGQgZGVsZXRpbmcgYSByb3cgZnJvbSB0aGlzIHRhYmxlLCBhdXRvbWF0aWNhbGx5IGNsb3Nl IHRoZQogICAgY29ycmVzcG9uZGluZyBTU0ggc2Vzc2lvbj8KICAgIElmIHNvLCB0aGVuIGl0IHdv dWxkIGJlIHNlbnNpYmxlIHRvIGRvY3VtZW50IHRoaXMuCgoKU2VjdGlvbiA3LCBzc2h0bUdyb3Vw CiAgSXQgd291bGQgcHJvYmFibHkgYmUgbW9yZSBmbGV4aWJsZSB0byBkZWZpbmUgdGhpcyBhcyB0 d28gc2VwYXJhdGUgZ3JvdXBzLgpPbmUgY29udGFpbmluZyB0aGUgc3RhdGlzdGljcyBvYmplY3Rz LCBhbmQgb25lIGNvbnRhaW5pbmcgdGhlIExDRCB0YWJsZQphbmQgcmVsYXRlZCBzY2FsYXJzLiAg RXZlbiBpZiBib3RoIGdyb3VwcyBhcmUgZGVmaW5lZCBhcyBtYW5kYXRvcnksIHRoaXMKc2VwYXJh dGlvbiB3b3VsZCBhbGxvdyBtb3JlIGZvY3VzZWQgZGVzY3JpcHRpb25zLgoKClNlY3Rpb24gOCwg cGFyYWdyYXBoIDIKICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNlZW0gdG8gZGVmaW5lIGFueSB3 ZWxsLWtub3duIHBvcnRzCmZvciB1c2UgYnkgU05NUC1vdmVyLVNTSC4KCiAgPHByb3Bvc2FsPgog ICBwYXJhZ3JhcGggMQogICAgIHMvaW5zdGVhZCBvZi90byBzdXBwbGVtZW50LwogICBEZWxldGUg cGFyYWdyYXBoIDIKICA8L3Byb3Bvc2FsPgoKClNlY3Rpb24gOCwgcGFyYWdyYXBoIDIKICBUaGlz IGRlc2NyaXB0aW9uIGluY2x1ZGVzIGFuIHVubmVjZXNzYXJ5IGxldmVsIG9mIGRldGFpbCwgd2hp Y2gKc2VydmVzIHRvIG9ic2N1cmUgdGhlIG1haW4gcG9pbnQuCgogIDxwcm9wb3NhbD4KICAgVGhl IFNTSCBwcm90b2NvbCBoYXMgaXRzIG93biB3aW5kb3cgbWVjaGFuaXNtLCBkZWZpbmVkIGluIFJG QwogICA0MjU0LiBUaGUgU1NIIHNwZWNpZmljYXRpb25zIGxlYXZlIGl0IG9wZW4gd2hlbiB3aW5k b3cgYWRqdXN0bWVudHMKICAgbWVzc2FnZXMgc2hvdWxkIGJlIGNyZWF0ZWQsIGFuZCBzb21lIGlt cGxlbWVudGF0aW9ucyBzZW5kIHRoZXNlCiAgIHdoZW5ldmVyIHJlY2VpdmVkIGRhdGEgaGFzIGJl ZW4gcGFzc2VkIHRvIHRoZSBhcHBsaWNhdGlvbi4gIFRoZXJlCiAgIGFyZSBub3RpY2VhYmxlIGJh bmR3aWR0aCBhbmQgcHJvY2Vzc2luZyBvdmVyaGVhZHMgdG8gaGFuZGxpbmcgc3VjaAogICB3aW5k b3cgYWRqdXN0bWVudCBtZXNzYWdlcywgd2hpY2ggY2FuIGJlIGF2b2lkZWQgYnkgc2VuZGluZyB0 aGVtCiAgIGxlc3MgZnJlcXVlbnRseS4KICA8L3Byb3Bvc2FsPgoKClNlY3Rpb24gOQogIFRoZSB2 YXJpb3VzIHN1YnNlY3Rpb25zIHNlZW0gdG8gYXBwZWFyIGluIGEgc29tZXdoYXQgcmFuZG9tIG9y ZGVyLgpJdCB3b3VsZCBwcm9iYWJseSBiZSBjbGVhcmVyIHRvIGRpc2N1c3MgdGhlIHRocmVlIFNT SC1sZXZlbCBzZWN1cml0eQpjb25zaWRlcmF0aW9ucywgYmVmb3JlIG1vdmluZyBvbiB0byBTTk1Q L01JQi1yZWxhdGVkIGlzc3Vlcy4KClRoZSB0aXRsZXMgb2YgdGhlc2Ugc3Vic2VjdGlvbiBkZXNj cmliZSBTU0ggcHJvdG9jb2wtbGV2ZWwgZGV0YWlscywKd2hpY2ggYXJlIHBvc3NpYmx5IG5vdCBm YW1pbGlhciB0byBub24tU1NILWV4cGVydHMuICBNb3JlIGdlbmVyYWwKdGl0bGVzIChkZXNjcmli aW5nICJ3aGF0IiByYXRoZXIgdGhhbiAiaG93Iikgd291bGQgYmUgaGVscGZ1bC4KKHNlZSBwcm9w b3NhbHMgYmVsb3cpCgoKU2VjdGlvbiA5LjEKICBUaGUgZmlyc3QgdHdvIHBhcmFncmFwaHMgKGp1 c3RpZnlpbmcgdGhlIHVzZSBvZiB1c2VyYXV0aCAibm9uZSIpCnNlZW0gdG8gYmUgaW5jb25zaXN0 ZW50IHdpdGggdGhlIHRoaXJkIChyZWNvbW1lbmRpbmcgYWdhaW5zdCB0aGlzKS4KQSBzaW1wbGVy IGRlc2NyaXB0aW9uIHdvdWxkIHBlcmhhcHMgYmUgbGVzcyBjb25mdXNpbmcuCgogIDxwcm9wb3Nh bCBjb25maWRlbmNlPTA+CiAgICAgOS4xLiAgU2tpcHBpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9u CgogICBTU0ggaW5jbHVkZXMgdGhlICJub25lIiB1c2VyYXV0aCBtZXRob2QsIHdoaWNoIGNvdWxk IGluIHByaW5jaXBsZQogICBiZSB1c2VkIHRvIHN1cHBvcnQgYWNjZXNzIGJ5IGFub255bW91cyBj bGllbnRzLiAgVGhpcyB3b3VsZCBub3QKICAgY29tcHJvbWlzZSB0aGUgYXV0aGVudGljYXRpb24g b2YgdGhlIHNlcnZlciB0byB0aGUgY2xpZW50cywgbm9yCiAgIGRhdGEgY29uZmlkZW50aWFsaXR5 IG9yIGRhdGEgaW50ZWdyaXR5LgoKICAgSG93ZXZlciBzdWNoIGEgY29uZmlndXJhdGlvbiBlZmZl Y3RpdmVseSBwcm92aWRlcyBhIHNlY3VyaXR5TGV2ZWwKICAgb2YgIm5vQXV0aFByaXYiLCB3aGlj aCBpcyBub3QgcGVybWl0dGVkIGJ5IFJGQyAzNDExLiAgVGhlIFNTSAogICBUcmFuc3BvcnQgTW9k ZWwgU0hPVUxEIE5PVCBiZSB1c2VkIHdpdGggYW4gU1NIIGNvbm5lY3Rpb24gdXNpbmcKICAgdGhl ICJub25lIiB1c2VyYXV0aCBtZXRob2QuCiAgPC9wcm9wb3NhbD4KClFuOiBXaHkgaXMgdGhpcyBT SE9VTEQgTk9UIHJhdGhlciB0aGFuIE1VU1QgTk9UID8KClRoaXMgdGV4dCBtYXkgd2VsbCBiZSBh biBvdmVyLXNpbXBsaWZpY2F0aW9uLCBpbiB3aGljaCBjYXNlIGl0IHdvdWxkIGJlCnVzZWZ1bCB0 byBnaXZlIGEgY2xlYXJlciBkZXNjcmlwdGlvbiBvZiB3aGVuL2hvdyBhbm9ueW1vdXMgYWNjZXNz IGNhbgpwcm92aWRlIGFuIGF1dGhlbnRpY2F0ZWQgcHJpbmNpcGFsLgoKClNlY3Rpb24gOS4yCiAg VGhlIGlzc3VlcyBkaXNjdXNzZWQgaGVyZSBhcmUgbm90IHNwZWNpZmljIHRvIGNvbW11bml0eS1i YXNlZCB2ZXJzaW9ucwpvZiBTTk1QLiAgVGhlIHNhbWUgY29uc2lkZXJhdGlvbnMgd291bGQgYXBw bHkgdG8gU05NUHYzIHdpdGggVVNNLCBvciBhbnkKb3RoZXIgbm9uLXRyYW5zcG9ydC1hd2FyZSBT ZWN1cml0eSBNb2RlbC4KCiAgPHByb3Bvc2FsPgogICAgIDkuNCAgVXNlIHdpdGggbm9uLXRyYW5z cG9ydC1hd2FyZSBTZWN1cml0eSBNb2RlbHMuCgogICBUaGUgU05NUHYxIGFuZCBTTk1QdjJjIG1l c3NhZ2UgcHJvY2Vzc2luZyBkZXNjcmliZWQgaW4gW1JGQzM1ODRdCiAgIGFsd2F5cyBzZWxlY3Qg dGhlIFNOTVB2MSBvciBTTk1QdjJjIFNlY3VyaXR5IE1vZGVscyByZXNwZWN0aXZlbHkuCiAgIEJv dGggb2YgdGhlc2UsIGFuZCB0aGUgVXNlci1iYXNlZCBTZWN1cml0eSBNb2RlbCB0eXBpY2FsbHkg dXNlZCB3aXRoCiAgIFNOTVB2MywgZGVyaXZlIHRoZSBzZWN1cml0eU5hbWUgYW5kIHNlY3VyaXR5 TGV2ZWwgZnJvbSB0aGUgU05NUAogICBtZXNzYWdlIHJlY2VpdmVkLCBldmVuIHdoZW4gdGhlIG1l c3NhZ2Ugd2FzIHJlY2VpdmVkIG92ZXIgYSBzZWN1cmUKICAgdHJhbnNwb3J0LiAgQWNjZXNzIGNv bnRyb2wgZGVjaXNpb25zIGFyZSB0aGVyZWZvcmUgbWFkZSBiYXNlZCBvbiB0aGUKICAgY29udGVu dHMgb2YgdGhlIFNOTVAgbWVzc2FnZSwgcmF0aGVyIHRoYW4gdXNpbmcgdGhlIGF1dGhlbnRpY2F0 ZWQKICAgaWRlbnRpdHkgYW5kIHNlY3VyaXR5TGV2ZWwgcHJvdmlkZWQgYnkgdGhlIFNTSCBUcmFu c3BvcnQgTW9kZWwuCiAgPC9wcm9wb3NhbD4KCgpTZWN0aW9uIDkuMwoKICA8cHJvcG9zYWw+CiAg ICAgOS4yLiAgU2tpcHBpbmcgc2VydmVyIGF1dGhlbnRpY2F0aW9uCgogICBzL2lmIHRoaXMgc3Rl cCBpcyBza2lwcGVkLwogICAgIGlmIHRoaXMgc3RlcCBpcyBza2lwcGVkIChlLmcuIGJ5IGJsaW5k bHkKICAgICAgICAgICBhY2NlcHRpbmcgdGhlIG9mZmVyZWQgcHVibGljIGtleSkvCgogICBTdGFy dCBuZXcgcGFyYWdyYXBoIGJlZm9yZSAiRGF0YSBjb25maWRlbnRpYWxpdHkiCiAgPC9wcm9wb3Nh bD4KCgpTZWN0aW9uIDkuNAoKICA8cHJvcG9zYWw+CiAgICAgOS4zLiAgU2tpcHBpbmcgZGF0YSBp bnRlZ3JpdHkgdmFsaWRhdGlvbgoKICAgU1NIIHByb3ZpZGVzIHRoZSAibm9uZSIgTUFDIGFsZ29y aXRobSwgd2hpY2ggZGlzYWJsZXMgdGhlIHZhbGlkYXRpb24KICAgb2YgZGF0YSBpbnRlZ3JpdHks IHdoaWxlIG1haW50YWluaW5nIGRhdGEgY29uZmlkZW50aWFsaXR5LiAgSG93ZXZlcgogICBpZiB0 aGlzIGlzIGRvbmUsIHRoZW4gYW4gYXR0YWNrZXIgbWlnaHQgYmUgYWJsZSB0byBtb2RpZnkgdGhl IGRhdGEKICAgaW4gZmxpZ2h0LCB0aHVzIGNvbXByb21pc2luZyBib3RoIGRhdGEgaW50ZWdyaXR5 IGFuZCBhdXRoZW50aWNhdGlvbi4KCiAgIFNTSCBNVVNUIE5PVCAuLi4KICA8L3Byb3Bvc2FsPgoK UW46IFdvdWxkbid0IHRoaXMgYWxzbyBjb21wcm9taXNlIHRoZSBjb25maWRlbnRpYWxpdHkgb2Yg cmV0dXJuZWQgZGF0YT8KCgpTZWN0aW9uIDkuNQogIFRoZSBNSUIgbW9kdWxlIF9kb2VzXyBjb250 YWluIHdyaXRlYWJsZSBvYmplY3RzIChwYXJhZ3JhcGggMSksIHdoaWNoCmFmZmVjdCB0aGUgbWFw cGluZyBiZXR3ZWVuIFNTSCBwcmluY2lwYWwgYW5kIHRtU2VjdXJpdHlOYW1lIChhbmQgaGVuY2UK dGhlIFNOTVAgc2VjdXJpdHlOYW1lKS4gIFRoZXNlIGNvdWxkIGJlIHVzZWQgdG8gc3VidmVydCBT Tk1QLWxldmVsIGFjY2Vzcwpjb250cm9sIHJlc3RyaWN0aW9ucy4KCiAgVGhlIHZhbHVlcyBvZiBT U0ggcHJpbmNpcGFscyBhbmQgdG1TZWN1cml0eU5hbWUgY291bGQgdGhlbXNlbHZlcyBiZQpzZW5z aXRpdmUgKHBhcmFyYXBoIDIpLCBhcyBtaWdodCB0aGUgYWRkcmVzc2VzIG9mIGNvbW11bmljYXRp bmcgU05NUCBlbmdpbmVzLgoKClNlY3Rpb24gMTAsIGl0ZW0gMQogIElBTkEgaXMgcmVxdWVzdGVk IHRvIGFzc2lnbiBhIGRlZmF1bHQgcG9ydCBmb3IgU05NUC1vdmVyLVNTSC4gIEJ1dApub3doZXJl IGluIHRoaXMgZG9jdW1lbnQgaXMgdGhlcmUgYSBwbGFjZWhvbGRlciBsb2NhdGlvbiBmb3IgdGhp cyBwb3J0Cm51bWJlciB0byBiZSBzcGVjaWZpZWQuCg== ------=_Part_9_16883203.1218493522073 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_Part_9_16883203.1218493522073-- From isms-bounces@ietf.org Wed Aug 13 07:12:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CEC3A6ABE; Wed, 13 Aug 2008 07:12:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B89C3A6AB0 for ; Wed, 13 Aug 2008 07:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6+wkOqBnucR for ; Wed, 13 Aug 2008 07:12:03 -0700 (PDT) Received: from mxc.liv.ac.uk (mxc.liv.ac.uk [138.253.100.103]) by core3.amsl.com (Postfix) with ESMTP id DC4443A6BB2 for ; Wed, 13 Aug 2008 07:11:58 -0700 (PDT) Received: from mailhubb.liv.ac.uk ([138.253.100.37]) by mxc.liv.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1KTH4O-0001j4-Gc for isms@ietf.org; Wed, 13 Aug 2008 15:11:24 +0100 Received: from localhost ([127.0.0.1] helo=mailhubb.liv.ac.uk) by mailhubb.liv.ac.uk with esmtp (Exim 4.54) id 1KTH4O-0003ej-CJ for isms@ietf.org; Wed, 13 Aug 2008 15:11:24 +0100 Received: from mail.csc.liv.ac.uk ([138.253.184.237] helo=tethys.csc.liv.ac.uk) by mailhubb.liv.ac.uk with esmtp (Exim 4.54) id 1KTH4O-0003eg-BG for isms@ietf.org; Wed, 13 Aug 2008 15:11:24 +0100 Received: from [10.30.3.1] (daves@daves [10.30.3.1]) by tethys.csc.liv.ac.uk (8.11.1 - (Revision 1.09)/LUCS-DTS-4.0M10) with ESMTP id m7DEBNs01075 for ; Wed, 13 Aug 2008 15:11:24 +0100 (BST) Message-ID: <48A2EB89.6080801@liverpool.ac.uk> Date: Wed, 13 Aug 2008 15:11:21 +0100 From: Dave Shield User-Agent: Thunderbird 1.5.0.13 (X11/20071213) MIME-Version: 1.0 To: isms@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000208010301060508060401" Subject: Re: [Isms] Comments on ISMS drafts - general and Transport subsystem X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. --------------000208010301060508060401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've just realised that the comments on the ISMS drafts which I sent a couple of days ago, were attached as un-typed binary files, which probably wasn't very helpful! I'm therefore trying again, with the comment files explicitly marked as text. This message includes my general comments on the tmStateReference cache, and those on the Transport subsystem draft. I'll send my comments on the Security Model and SSH Transport drafts separately. Dave --------------000208010301060508060401 Content-Type: text/plain; name="General-comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="General-comments.txt" ISMS General Comments ===================== tmStateReference cache ---------------------- The main concept of the ISMS proposal seems to be for the transport subsystem to cooperate with the Security subsystem, in order to use transport-level security parameters for authentication and authorization. The mechanism used for this purpose is a 'tmStateReference cache'. As such, there needs to be a common understanding of the contents of this cache - both in terms of what information it will contain, and how that information should be used. However the three main ISMS documents contain significantly different descriptions of this cache, with the Transport Subsystem document (in particular) being very vague about what information should be included. It would seem sensible to have a consistent description shared by all three documents - probably by repeating essentially the same text each time. (Possibly augmented by any local considerations). X. Cached Information and References When performing SNMP processing, there are two levels of state information that may need to be retained: the immediate state linking a request-response pair, and potentially longer-term state relating to the processing of a stream of related requests. The RFC3411 architecture uses caches to maintain the short-term message state, and uses references in the ASIs to pass this information between subsystems. This document defines the requirements for a cache to handle the longer-term transport state information, using a tmStateReference parameter to pass this information between subsystems. To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message should also be discarded. If state information is available when a relationship between engines is severed, such as the closing of a transport session, the state information for that relationship might also be discarded. X.1. securityStateReference cache The securityStateReference parameter is defined in RFC3411. Its primary purpose is to provide a mapping between a request and the corresponding response. This cache is not accessible to Transport Models, and an entry is typically only retained for the lifetime of a request-response pair of messages. X.2. tmStateReference cache For each transport session, information about the transport security is stored in a cache. The tmStateReference parameter is used to pass model- and mechanism-specific parameters between the Transport subsystem and transport-aware Security Models. The tmStateReference cache will typically remain valid for the duration of the transport session, and hence may be used for several messages. Since this cache is only used within an implementation, and not on-the-wire, the precise contents and format are implementation- dependent. However, for interoperability between Transport Models and transport-aware Security Models, entries in this cache must include at least the following fields: - transportDomain - transportAddress - tmSecurityName - tmSecurityLevel (but see below) - tmSameSecurity - tmSessionID X.2.1. Transport information Information about the source of an incoming SNMP message is passed up from the Transport subsystem as far as the Message Processing subsystem. However these parameters are not included in the processIncomingMsg ASI defined in RFC3411, and hence this information is not directly available to the Security Model. A transport-aware Security Model might wish to take account of the transport protocol and originating address when authenticating the request, and setting up the authorization parameters. It is therefore necessary for the Transport Model to include this information in the tmStateReference cache, so that it is accessible to the Security Model. - transportDomain the transport protocol (and hence the Transport Model) used to receive the incoming message - transportAddress the source of the incoming message. Note that the ASIs used for processing an outgoing message all include explicit transportDomain and transportAddress parameters. These fields within the tmStateReference cache will typically not be used for outgoing messages. X.2.2. securityName There are actually three distinct "identities" that can be identified during the processing of an SNMP request over a secure transport: - transport principal: the transport-authenticated identity, on whose behalf the secure transport connection was (or should be) established. This value is transport-, mechanism- and implementation- specific, and is only used within a given Transport Model. - tmSecurityName: a human-readable name (in snmpAdminString format) representing this transport identity. This value is transport- and implementation-specific, and is only used (directly) by the Transport and Security Models. - securityName: a human-readable name (in snmpAdminString format) representing the SNMP principal in a model-independent manner. Note that the transport principal may or may not be the same as the tmSecurityName. Similarly, the tmSecurityName may or may not be the same as the securityName as seen by the Application and Access Control subsystems. In particular, a non-transport-aware Security Model will ignore tmSecurityName completely when determining the SNMP securityName. However it is important that the mapping between the transport principal and the SNMP securityName (for transport-aware Security Models) is consistent and predictable, to allow configuration of suitable access control and the establishment of transport connections. X.2.3. securityLevel There are two distinct issues relating to security level as applied to secure transports. For clarity, these are handled by separate fields in the tmStateReference cache: - tmTransportSecurityLevel: an indication from the Transport Model of the level of security offered by this session. The Security Model can use this to ensure that incoming messages were suitably protected before acting on them. - tmRequestedSecurityLevel: an indication from the Security Model of the level of security required to be provided by the transport protocol. The Transport Model can use this to ensure that outgoing messages will not be sent over an insufficiently secure session. X.2.4. Session information For security reasons, if a secure transport session is closed between the time a request message is received and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision whether to REQUIRE this. - tmSameSecurity: this flag is used by a transport-aware Security Model to indicate whether the Transport Model should enforce this restriction. - tmSessionID: in order to verify whether the session has changed, the Transport Model must be able to compare the session used to receive the original request with the one to be used to send the response. This typically requires some form of session identifier. This value is only ever used by the Transport Model, so the format and interpretation of this field are model- and implementation-dependent. Qn: The above text describes the tmStateReference cache as a per-session structure (following the lead of the Transport subsystem document). However the tmSameSecurity and tmRequestedSecurityLevel fields work on a per-message. Is this a problem? If so, how should it be handled? --------------000208010301060508060401 Content-Type: text/plain; name="TMSM-comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="TMSM-comments.txt" Transport Subsystem =================== Sections 1.2 & 1.3 The other two documents start with Internet-Standard Management Framework and Conventions followed by a section on Modularity. The Transport subsystem document has the modularity diagram coming *before* the section on Conventions. Switch these two sections around. 1.2. Conventions 1.3. Modularity [Note: new title] (This would also probably avoid the large blank space on p3!) (new) Section 1.4 The other two documents also include a section on Constraints, which is missing from the subsystem document. It would be sensible to include the same section here, as a guide to developers of new Transport Models, who might use this document as a template. Section 2, paragraph 2 The description of the "third approach" is very long and detailed. This tends to obscure the basic point. ... In the third approach, he could hire a security company, tell them what he wants protected, and leave the details to them. Considerations of hiring and training employees, positioning and scheduling guards, arranging for cover, etc. are then the responsibility of the security company. The individual therefore achieves the desired security, wth no significant effort... Section 2, paragraph 4 This text half-reads as a justification of whether it is possible to use USM at all. The intended key point is presumably that operators would prefer an integrated approach. ... USM therefore requires a separate principal and key management infrastructure, either configured using SNMP itself, or via some external mechanism. However operators have reported that requiring such a separate infrastructure is a deterrent to deploying SNMPv3. It would be preferable to leverage a single user base that wasn't specific to SNMP. Section 2, paragraphs 5&6 Both of these paragraphs lead with the domestic security analogy, and this tends to obscure the SNMP aspects somewhat. The emphasis should probably be on the options for SNMP authentication, etc. A USM-compliant architecture might combine the authentication mechanism with an external mechanism, such as RADIUS [RFC2865], to provide the authentication service. Similarly it might be possible to utilize an external protocol to encrypt a message, to check timeliness, to check data integrity, etc. However this corresponds to the second approach - requiring the coordination of a number of differenty subcontracted services. Building solid security between the various services is difficult, and there is a significant potential for gaps in security. An alternative approach might be to utilize one or more lower-layer security mechanisms to provide the message-oriented security services required. These would include authentication of the sender, encryption, timeliness checking, and data integrity checking. This corresponds to the third approach described above. There are a number of IETF standards .... Section 3.1 Is it necessary to reference RFC 3411 both before *and* after the list of threats? Delete " [RFC3411]" from before the list of threats Section 3.1.1, paragraph 1 s/SHOULD/should/ Section 3.1.1, paragraph 2 I'm still not entirely sure what the last sentence is trying to say. The following encapsulates what I *think* it's referring to: It is recommended that any proposed Transport Model include a description of the applicability of the relevant security protocol(s) for use in that Transport Model. If I have misunderstood the purpose of this sentence, then some fuller explanation would probably be useful. Section 3.1.1, paragraph 3, sentence 2 s/would/could/ i.e. ... in ways that could impact other existing usages. ... Section 3.2.1 The description of the existing architecture (in paragraph 2) lists the components in a seemingly random order. It would be more natural to list these in the order that they are used (as in the diagram on p4). The third sentence of the same paragraph is perhaps a little too strong. The rest of this section doesn't really seem to hang together very well. A re-ordering of the same basic material would probably provide a more coherent explanation of how the Transport subsystem fits into the basic RFC3411 architectural requirements. In particular, paragraphs 3&6 feel to be directly related, and could usefully be merged. It would also be worth emphasising the functional benefits of a Transport subsystem, rather than the implications for IETF progression. The motivation behind the Transport Subsystem (in paragraph 5), and listing particular examples, isn't really directly relevant to the idea of mandatory elements. Mentioning them here serves to obscure the main point of the paragraph. 3.2.1. Architectural Modularity Requirements SNMP version 3 (SNMPv3) is based on a modular architecture (defined in [RFC3411] section 3) to allow the evolution of the SNMP protocol standards over time, and to minimize side effects between subsystems when changes are made. The RFC3411 architecture includes a Message Processing Subsystem permitting different message versions to be handled by a single engine, a Security Subsystem for enabling different methods of providing security services, an Access Control Subsystem for allowing multiple approaches to access control, and Application(s) to support different type of application processors. The RFC3411 architecture does not include a subsystem for Transport Models, despite the fact that there are multiple transport mappings already defined for SNMP. This document proposes a Transport Subsystem that is compatible with the RFC3411 architecture. As work is being done to use secure transports such as SSH and TLS, using a sbsystem will enable consistent design and modularity of such Transport Models. The design of this Transport Subsystem accepts the goals of the RFC3411 architecture defined in section 1.5 of [RFC3411]. This Transport Subsystem uses a modular design that permits multiple transport protocols to be "plugged into" the RFC3411 architecture, supported by corresponding Transport Models (which may or may not be security-aware). Such Transport Models would be independent of other modular SNMP components as much as possible. This design also permits Transport Models to be advanced through the standards process independently of other Transport Models. To encourage a basic level of interoperability, IETF standards typically require one mandatory-to-implement solution, with the capability of adding new mechanisms in the future. Any Transport Model SHOULD define one minimum-compliance security mechanism, but should also be able to support additional existing and new mechanisms. The following diagram depicts the SNMPv3 architecture including the new Transport Subsystem defined in this document, and a new Transport Security Model defined in [I-D.ietf-isms-transport-security-model]. Qn: Is it intended to specify SSH-TM as the basic interoperability secure Transport Model? If so, it would probably be sensible to state this explicitly somewhere. The end of the penultimate paragraph above would seem an obvious place to do this. Section 3.2.1, paragraphs 4,7&8 These three paragraphs discuss *changes* to the basic RFC3411 model (over and above the simple introduction of the Transport Subsystem). It would probably be worth pulling these out into a separate subsection, to emphasise this fact. The following text also omits some unnecessary detail, which tended to obscure the basic ideas being described. 3.2.1.1. Changes to RFC3411 architecture The RFC3411 architecture and the Security Subsystem assume that a Security Model is called by a Message Processing Model and will perform multiple security functions within the Security Subsystem. A Transport Model that supports a secure transport protocol might perform similar security functions within the Transport Subsystem, including the translation of transport security parameters to/from security-model-independent parameters. To accommodate this, an implementation-specific cache of transport- specific information will be described (not shown), and the data flows between modules on this path will be extended to pass security-model-independent transport information. Note that this document amends some of the ASIs defined in RFC 3411, and these changes are covered in sections 6.2 and 6.4. New Security Models may be defined that understand how to work with these modified ASIs and the transport-information cache. One such Security Model, the Transport Security Model, is defined in [I-D.ietf-isms-transport-security-model] (current) Section 3.2.1.1 This isn't really specific to USM - it actually seems to be discussing the processing differences as compared to the current RFC3411 architecture when used with *any* (non-trivial) Security Model. Again, there is an excess of detail which serves to obscure the main point of the paragraph. This subsection would also need to be renumbered, if the new subsection proposed above is included. 3.2.1.2. Changes to RFC3411 processing The introduction of secure transports also affects the (security?) responsibilities and order of processing within the RFC3411 architecture. While the steps are the same, they may occur in a different order, and may be done by different subsystems. With the existing RFC3411 architecture, security processing starts when the Message Processing Model decodes portions of the encoded message to extract parameters that identify which Security Model should handle the security-related tasks. A secure transport performs those security functions on the message, *before* the message is decoded. Note that some of these functions might then be repeated by the selected Security Model. I believe this last sentence is true - particularly if the message specifies a non-TM-aware Security Model, such as USM. This may or may not be relevant, but it seems worth mentioning. (current) Section 3.2.1.2 3.2.1.3. Passing Information between SNMP Engines s/other SNMP engine/other/ Section 3.2.2.1, paragraph 4 The first three paragraphs of this section outline the current RFC3411 architecture. This final paragraph seems to describe the implications of adding a secure Transport Model, but this isn't immediately obvious. The introduction of a secure transport protocol means that the translation from a mechanism-specific identity to a securityName might also be done by a Transport Model. This proposed securityName might then be made available to the Security Model, together with an indication of the level of security provided by the transport layer. A Security Model might have multiple ... (in the final sentence) s/made available/proposed/ Section 3.2.3, paragraph 2-4 This text should probably concentrate on the handling of security parameters, rather than providing unnecessary details of the processing within the Security Module. The intended meaning of paragraph 4 remains somewhat unclear to me, particularly as it might relate to the passing of security parameters between subsystems. It seems to be discussing the purpose and actions of a Security Model, when used with a security-aware Transport Model. However this does not seem to be concerned with the handling of security parameters. No proposed alternative is suggested for this text, as I would question whether this paragraph should appear here at all. A Message Processing Model might unpack SNMP-specific security parameters from an incoming message before calling a specific Security Model to handle the security-related processing of the message. When using a secure Transport Model, some security parameters might be extracted from the transport layer by this model before the message is passed to the Message Processing Subsystem. This information should also be made available to the Security Model. This document describes a cache mechanism (see section 5), into which the Transport Model puts information about the transport and security parameters applied to a transport connection or incoming message, and from which a Security Model may extract this information. A tmStateReference is passed as an extra parameter in the ASIs between the Transport, Message Processing and Security Subsystems, to identify the relevant cache. This approach of passing a model- independent reference is consistent with the securityStateReference cache passed between the Security, Access Control and Applicaion subsystems in the RFC3411 ASIs. Section 3.2.4, paragraphs 2&3 The first sentence of paragraph 2 is inconsistent in its use of tense. The rest of the paragraph seems to be talking about the modular nature of the access control framework, but doesn't actually say so. It's not immediately clear how this relates to the concept of authentication vs authorization (and the separation between them). This separation was a deliberate decision of the SNMPv3 WG, to allow support for authentication protocols which do not provide data access authorization capabilities, and to support data access authorization schemes, such as VACM, that do not perform their own authentication. A Message Processing Model determines which Security Model is used, either based on the message version (e.g. SNMPv1 and SNMPv2c), or possibly by a value specified in the message (e.g. msgSecurityModel field in SNMPv3). Section 3.2.4, paragraphs 6&7 More generally, the first five paragraphs of this section seem to be summarising the overall security-related aspects of the RFC3411 architecture, with paragraphs six and seven disussing the implications for the Transport Model subsystem. However these latter concentrates on the interactions with the Message Processing and Security subsystems (which have already been covered), and does not really address interaction with the Access Control subsystem. Presumably because there isn't any, given the separation between Authentication and Authorization! The obvious thing to cover here would be a summary of the recent discussion regarding transport-independent vs transport-dependent securityName mappings, as passed from the Security subsystem up to the Access Control and Application subsystems. The proposed prefix-based mapping would more sensibly be covered in the TSM document, but this section could at least prepare the ground for that mechanism. A Transport Model does not know what Security Model will be used for an incoming message, so cannot know how the securityName and securityLevel parameters will be determined. It can propose an authenticated identity (via the tmSecurityName field), but there is no guarantee that this value will be used by the Security Model. For example, non-transport-aware Security Models will typically determine the securityName (and securityLevel) based on the contents of the SNMP message itself. Such Security Models will simply not know that the tmStateReference cache exists. Further, even if the Transport Model can influence the choice of securityName, it cannot directly determine the authorization allowed to this identity. If two different Transport Model each authenticate a transport principal, that are then both mapped to the same securityName, then these two identities will typically be afforded exactly the same authorization by the Access Control Model. The only way for the Access Control Model to differentiate between identities based on the underlying Transport Model, would be for such transport-authenticated identities to be mapped to distinct securityNames. How and if this is done is Security-Model-dependent. Section 3.3, paragraph 3 This text, discussing the session selection, covers very similar material to paragraph 1 & 5 of section 3.3.1, and paragraph 2 of section 3.3.3. It might be sensible to merge these descriptions, perhaps as a separate new subsection: 3.3.1. Session Selection The architecture defined in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and nor do the ASIs defined in this document for the Transport Subsystem. Neither does the Transport Subsystem have access to the pduType, so cannot select a given session for particular types of traffic. However certain parameters of these ASIs can be used to guide the selection of the appropriate session to use for a given request. The transportDomain and transportAddress identify the transport connection to a remote network node. Elements of the transport address (such as the port number) can be used to select different sessions for particular request types. For example, UDP ports 161 and 162 have typically been used to separate SNMP notifications from other request/response traffic. The securityName identifies which security principal to communicate with at the remote network node (e.g., different NMS applications running on the same system). The securityLevel could be used to select sessions with different sets of security properties for different purposes (e.g., encrypted SETs vs. non-encrypted GETs). Note that this remains true even if all the sessions actually provide the same level of security protection. In summary, a unique combination of transportDomain, transportAddress, securityName, and securityLevel would serve to identify a given session. Different values for any of these parameters would imply the use of a different session. An immediate consequence of this is that implementations SHOULD be able to maintain some reasonable number of concurrent sessions. Implementers, of course, might provide non-standard mechanisms to select sessions. Note(1): The paragraph starting "To reduce redundancy..." would remain as part of section 3.3. Note(2): The securityName and securityLevel are not explicitly included in the sendMessage and receiveMessage ASIs. These two values would therefore need to be included within the tmStateReference cache, in order to support session selection. The current text describing tmStateReference does not make this explicit. This is addressed by the proposed standard text for tmStateReference, common to all three documents. (current) Section 3.3.1 This would need to be renumbered (along with the following subsections), and the selection aspects removed: 3.3.2. Session Establishment Requirements As indicated above, SNMP subsystems (including SNMP applications) can specify a particular transport session by passing a unique combination of transportDomain, transportAddress, securityName, and securityLevel. If this combination does not match an existing transport session, this will request the Transport Subsystem to establish a new session. If the Transport Model cannot provide at least the requested level of security, the Transport Model SHOULD discard the message and notify the dispatcher that establishing a session and sending the message failed. Similarly, if the session cannot be established, then the message should be discarded and the dispatcher notified. Transport session establishment might require provisioning authentication credentials at an engine, either statically or dynamically. How this is done is dependent on the transport model and the implementation. (current) Section 3.3.3 The order in which material is covered in the second half of the first paragraph is somewhat random. It would be clearer if each concept was handled individually. The second paragraph of Section 5.2 also discusses cross-session security considerations, and would probably fit better as part of this description. The second and third paragraphs are effectively covered in the (new) subsection 3.3.1, and don't need to be repeated here. The justification of why multiple levels of security are available (in paragraphs 4&5) is not really relevant to a discussion of message vs session security, and serves to obscure the main point being made. ... SHOULD ensure that fresh new session keys are generated for each session. This would ensure that a cross-session replay attack would be unsuccessful; that is, an attacker could not take a message observed on one session, and sucessfully replay this on another session. A good security protocol would also protect against replay attacks _within_ a session; that is, an attacker could not take a message observed on a session, and successfully replay this later in the same session. One approach would be to use sequence information within the protocol, allowing the participants to detect if messages were replayed or reordered within a session. Note that if a secure transport session is closed between the time a request message is received, and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision whether to REQUIRE this. SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application. Some Transport Models might support ... s/requested security level/ security level requested by a transport-aware Security Model/ (final sentence) Section 4, paragraph 2 s/ regardless of pduType,// (first time only) Section 5 This whole description should probably be replaced by the standard text proposed for the Cached Information and References section. The text starting "This document does not specify an implementation strategy..." (paragraph 4 of the current text), could probably be appended to the third paragraph of the standard description. Section 6 This section feels as if it would benefit from a brief description of how it relates to the ASIs defined in RFC3411. This document introduces a couple of new ASIs to define the interface between the Transport and Dispatcher Subsystems, and extends some of the ASIs defined in RFC3411 to include transport-related information. Section 6, paragraph 4 The description of what is included in an errorIndication is not entirely consistent with the usage in other SNMPv3 documents. An error indication in statusInformation will typically include the OID and value for an incremented error counter. This may be accompanied by values for contextEngineID and contextName for this counter, a value for securityLevel, and the appropriate state reference if the information is available at the point where the error is detected. Note that which state reference is returned will depend on the ASI concerned. securityStateReference is only relevant to the Security subsystem ASIs. Section 6.2 It would be useful to tweak the title of this subsection, to emphasise that this involves changes to the ASIs as defined in RFC3411. It would probably also be useful to reflect the section structure of the RFC3411 descriptions (to indicate which subsystems are affected), and to cover all of the amended ASIs: 6.2. Changes to RFC3411 Outgoing ASIs Additional parameters have been added to the ASIs defined in RFC3411, concerned with communication between the Dispatcher and Message Processing subsystems, and between the Message Processing and Security Subsystems. 6.2.1. Message Processing Subsystem Primatives A tmStateReference parameter has been added as an OUT parameter to the prepareOutgoingMessage and prepareResponseMessage ASIs. This is passed from Message Processing Subsystem to the dispatcher, and from there to the Transport Subsystem. statusInformation = prepareOutgoingMessage( : OUT tmStateReference -- (NEW) reference to transport state ) statusInformation = prepareResponseMessage( : OUT tmStateReference -- (NEW) reference to transport state ) How or if the Message Processing Subsystem modifies or utilitizes the contents of this cache is message-processing-model specific. 6.2.2. Security Subsystem Primatives transportDomain and transportAddress parameters have been added as IN parameters to the generateOutgoingMessage and generateResponseMessage ASIs, and a tmStateReference parameter has been added as an OUT parameter. The transportDomain and transportAddress parameters will have been passed into the Message Processing Subsystem from the dispatcher, and are passed on to the Security Subsystem. The tmStateReference parameter will be passed from the Security Subsystem back to the Message Processing Subsystem, and on to the dispatcher and Transport subsystems. statusInformation = generateOutgoingMessage( : IN transportDomain -- (NEW) transport Domain of request destination IN transportAddress -- (NEW) transport Address of request destination : OUT tmStateReference -- (NEW) reference to transport state ) statusInformation = generateResponseMessage( : IN transportDomain -- (NEW) transport Domain of request destination IN transportAddress -- (NEW) transport Address of request destination : OUT tmStateReference -- (NEW) reference to transport state ) If a cache exists for a session identifiable from the transportDomain, transportAddress, tmSecurityName and requested securityLevel, then a transport-aware Security Model might create a tmStateReference parameter to this cache, and pass that as an OUT parameter. Note that securityModel has been omitted from this final paragraph, in line with the (common) description of the tmStateReference cache, and the elements of procedure in other ISMS documents. Section 6.3, paragraph 1 When a message is received on a given transport session, if a cache does not already exist for that session, the Transport Model might create one, referenced by tmStateReference. The contents of this cache are discussed in section 5.2. How this information is determined is implementation- and transport-model-specific. Section 6.4 As with section 6.4, it would be useful to tweak the title of this subsection, and to reflect the structure of RFC3411: 6.4. Changes to RFC3411 Incoming ASIs The tmStateReference parameter has also been added to some of the incoming ASIs defined in RFC3411. How or if a Message Processing Model or Security Model uses tmStateReference is message-processing- and security-model-specific. 6.4.1. Message Processing Subsystem Primative A tmStateReference parameter has been added as an IN parameter to the prepareDataElements ASI. This is received from the Transport Model by the dispatcher, and passed to the Message Processing Subsystem. statusInformation = prepareDataElements( : IN tmStateReference -- (NEW) reference to transport state : OUT stateReference -- reference to state information ) How or if the Message Processing Subsystem modifies or utilitizes the contents of this cache is message-processing-model specific. 6.4.2. Security Subsystem Primative A tmStateReference parameter has been added as an IN parameter to the processIncomingMsg ASI, and is passed from the Message Processing Subsystem to the Security Subsytem. Model by the dispatcher, and passed to the Message Processing Subsystem. statusInformation = processIncomingMsg( : IN tmStateReference -- (NEW) reference to transport state : OUT securityStateReference -- reference to security state information ) If tmStateReference is present and valid, an appropriate Security Model might utilize the information in the cache. How or if the Security Subsystem utilizes the information in the cache is security- model-specific. This may sound underspecified, .... --------------000208010301060508060401 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --------------000208010301060508060401-- From isms-bounces@ietf.org Wed Aug 13 09:08:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6383D3A6B0C; Wed, 13 Aug 2008 09:08:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DE33A6B01 for ; Wed, 13 Aug 2008 09:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g0wSzH3ocJl for ; Wed, 13 Aug 2008 09:08:07 -0700 (PDT) Received: from mxc.liv.ac.uk (mxc.liv.ac.uk [138.253.100.103]) by core3.amsl.com (Postfix) with ESMTP id BFD0B3A6B0C for ; Wed, 13 Aug 2008 09:08:06 -0700 (PDT) Received: from mailhuba.liv.ac.uk ([138.253.100.36]) by mxc.liv.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1KTH6s-0001xG-Mo for isms@ietf.org; Wed, 13 Aug 2008 15:13:58 +0100 Received: from localhost ([127.0.0.1] helo=mailhuba.liv.ac.uk) by mailhuba.liv.ac.uk with esmtp (Exim 4.54) id 1KTH6s-00051C-HJ for isms@ietf.org; Wed, 13 Aug 2008 15:13:58 +0100 Received: from mail.csc.liv.ac.uk ([138.253.184.237] helo=tethys.csc.liv.ac.uk) by mailhuba.liv.ac.uk with esmtp (Exim 4.54) id 1KTH6s-000519-G3 for isms@ietf.org; Wed, 13 Aug 2008 15:13:58 +0100 Received: from [10.30.3.1] (daves@daves [10.30.3.1]) by tethys.csc.liv.ac.uk (8.11.1 - (Revision 1.09)/LUCS-DTS-4.0M10) with ESMTP id m7DEDws01094 for ; Wed, 13 Aug 2008 15:13:58 +0100 (BST) Message-ID: <48A2EC24.5010404@liverpool.ac.uk> Date: Wed, 13 Aug 2008 15:13:56 +0100 From: Dave Shield User-Agent: Thunderbird 1.5.0.13 (X11/20071213) MIME-Version: 1.0 To: isms@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010405080301050209010107" Subject: Re: [Isms] Comments on ISMS drafts - Security Model and SSH X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. --------------010405080301050209010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've just realised that the comments on the ISMS drafts which I sent a couple of days ago, were attached as un-typed binary files, which probably wasn't very helpful! I'm therefore trying again, with the comment files explicitly marked as text. This message includes my comments on the Security Model and SSH Transport drafts. I've already sent my comments on the tmStateReference cache and the Transport subsystem separately. Dave --------------010405080301050209010107 Content-Type: text/plain; name="TSM-comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="TSM-comments.txt" Transport Security Model ======================== Section 2 The first half of paragraphs 2&3 refer to the handling of incoming requests. It would probably be useful to merge these two descriptions into one. Similarly with paragraph 5 and the second half of paragraph 2. It's not immediately clear what the last couple of sentences of paragraph 3 are trying to explain, and particularly how this might relate to the topic of this section. Paragraph 4 assumes the creation of a new tmStateReference cache, and should acknowledge the possibility of re-using an existing one. For incoming requests, a secure Transport Model will create a tmStateReference cache (or use an existing one), including transportDomain, transportAddress, tmSecurityName and tmTransportSecurityLevel values, possibly together with other transport- specific information. A non-secure Transport Model will typically not create or populate this cache. The Transport Security Model will determine the security-model-independent securityName and securityLevel, and verify that the transport security provision is sufficient for the requested level of security. If the cache does not exist, is incompletely populated, or the tmTransportSecurityLevel provided is weaker than the requested securityLevel, the Transport Security Model will return an error (see section 5.2). For outgoing requests, the Transport Security Model will create a tmStateReference cache (or use an existing one), containing the transportDomain, transportAddress, tmSecurityName and tmRequestedSecurityLevel values, and passes the tmStateReference to the specified Transport Model. To maintain the RFC3411 modularity, the Transport Model does not know which Security Model will be used for an incoming message; this will be determined by the Message Processing Model. Hence even if the Transport Model populates the tmStateReference cache, it is possible that the selected Security Model will ignore its contents. For example, both the USM and community-based Security Models will derive the securityName from the SNMP message itself, rather than the tmSecurityName provided by a secure transport. Section 2.1.1. At first sight, there is an apparent inconsistency between the first two paragraphs - first the TSM claims to provide protection, and then it doesn't. A closer reading explains the difference, but a restructuring of the text might provide a clearer explanation: The Transport Security Model is called a Security Model to be compatible with the RFC3411 architecture. However it does not provide security mechanisms itself, so SHOULD always be used with a Transport Model that provides appropriate security. If used with a suitable Transport Model, then the Transport Security Model will provide protection against the threats identified by RFC3411. However the responsibility for providing this protection is delegated to the secure Transport Model. The Transport Security Model does not address any threats itself. If used with a non-secure Transport Model, then the Transport Security Model will *not* provide protection against such threats. Section 2.2 2.2. Transport Sessions The Transport Security Model does not work with transport sessions directly. Instead the transport-related state is associated with a unique combination of transportDomain, transportAddress, securityName and securityLevel, and referenced via the tmStateReference parameter. How and if this is mapped to a particular transport or channel is the responsibility of the Transport Subsystem. Section 2.3 The contents of this section seem to describe not only the coexistence of the Transport Security Model with other Security Models, but how the Transport Security Model can coexist (and/or interface with) other models within the RFC3411 architecture. It might be useful to subdivide this description into separate subsections for each of the RFC3411 Subsystems. Section 2.3, paragraph 3 Move this paragraph (and the two that follow) into a new subsection. 2.3.1. Coexistence with Message Processing Models The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 74) always select the SNMPv1(1) and SNMPv2(2) Security Models respectively. Since there is no mechanism defined in RFC3584 to select an alternative Security Model, SNMPv1 and SNMPv2c messages cannot use the Transport Security Model. Such messages can still be conveyed over a secure transport protocol, but the transport security information will not be used as part of the SNMP-level authentication or authorization. The SNMPv2u/SNMPv2* Message Processing Model is a historical artifact for which there is no existing IETF specification. The SNMPv3 message processing defined in [RFC3412], extracts the securityModel from the msgSecurityModel field of an incoming SNMPv3Message. When this value is transportSecurityModel(YY), security processing is directed to the Transport Security Model. For an outgoing message to be secured using the Transport Security Model, the application should specify a securityModel parameter value of transportSecurityModel in the sendPdu ASI. Section 2.3, paragraph 6 Move this paragraph into a new subsection. 2.3.2. Coexistence with other Security Models [[ text as currently ]] Section 2.3, paragraph 8 Move this paragraph into a new subsection, and expand slightly 2.3.3. Coexistence with Transport Models The whole purpose of the Transport Security Model is to work with appropriate secure Transport Models to use the transport- level security information for authenticating and authorizing an SNMP request. An indication of which Transport Model was or should be used is included as part of the tmStateReference cache. The MIB module defined in this document allows an administrator to configure the Transport Security Model to disable support for specific transport models. Section 2.3, paragraph 7 Move this paragraph into a new subsection, and expand to discuss transport-visible securityNames. 2.3.4. Coexistence with Access Control Models An SNMP engine will typically implement only one Access Control Model, and there is no mechanism defined in RFC3411 for selecting between alternative ACMs. There are therefore no issues relating to the coexistence of the Transport Security Model with multiple Access Control Models. Conversely, the isAccessAllowed primitive includes a parameter to indicate the Security Model used to authenticate a request, so the Access Control Model should be able to handle multiple Security Models (including the Transport Security Model). However the isAccessAllowed does not provide any information about the Transport Model used or transport-level security parameters. As a result, it is not possible to have different access control rules for different Transport Models. Or at least, not directly - the only way to influence access control based on transport considerations would be to use different securityName values for different transports. Section 2.4 Referring to the MIB is unnecessary at this point. It would be clearer (and consistent with the Transport subsystem document) to discuss processing is terms of the tmStateReference cache. Details of the precise processing required belong in the Elements of Procedure. It's probably not useful to go into quite so much detail here. For outgoing messages, the Transport Security Model uses parameters provided by the SNMP application to lookup or create an entry in the tmStateReference cache. The wholeMsg and tmStateReference parameter are passed to the appropriate Transport Model as described in [ID.ietf-isms-tmsm]. For incoming messages, a Transport Model accepts the message from the lower layer transport, and records the transport- and security- related information in the tmStateReference cache. The wholeMsg and tmStateReference parameter are passed to the appropriate Security Model as described in [ID.ietf-isms-tmsm]. The contents of this cache are discussed in Section 3.2. Section 3 This whole description should probably be replaced by the standard text proposed for the Cached Information and References section. Note that this effectively switches the order of subsections 3.1 and 3.2, to match the order used in the other ISMS documents. Add the following to the end of section 3.1 (securityStateReference) The tmStateReference parameter is used to ensure that the security parameters used for a response match those for the original request. The Transport Security Model should add the tmStateReference received from the processIncomingMsg ASI to the securityStateReference. This tmStateReference can then be retrieved during the generateResponseMsg ASI, so that it can be passed back to the Transport Model. This seems to be the intention of the second paragraph of the (current) Section 3.2, although talking about the Transport Model having access to the securityStateReference cache is confusing. Section 4.2, step 1 Whether the Security Model is processing a response message (as opposed to a request) can be determined by which ASI is used, rather than the presence or absence of a given parameters. 1) When generateResponseMsg is used to handle an SNMP response, the securityStateReference cache will contain information from the corresponding request, including securityName, securityLevel, and the tmStateReference. The Transport Security Model should extract these values, and can then discard the cached security data and the securityStateReference. The tmRequestedSecurityLevel in the tmStateReference cache should be set to the value of the extracted securityLevel, and the tmSameSecurity parameter should be set to true. Qn: How do the securityName and securityLevel IN parameters relate to the equivalent securityStateReference cache fields? Are these parameters used at all? Qn: Should the snmpTsmLCDTransformTable be referenced to check whether the specified transport is still enabled? Qn: Should the securityName (from the securityStateReference) be mapped back to a tmSecurityName, or will the existing tmSecurityName from the tmStateReference be used? Section 4.2, steps 2&3 These two steps both apply to the generateRequestMsg ASI. It would probably be clearer to combine them into a single step. 2) When generateRequestMsg is called to handle an SNMP request, the parameters won't include a securityStateReference cache. Instead, the transport and security requirements will be supplied by the application via the IN parameters. Firstly, the requested transportDomain should be looked up in the snmpTsmLCDTransformTable. If there is no entry for this domain, or the snmpTsmLCDPolicy value is set to disable(3), then ... ... processing stops for this message. [[ If the value of snmpTsmLCDTransformPolicy is private(1), then ]] the values supplied for transportDomain, transportAddress, securityName and securityLevel are used to lookup or create an entry in the snmpTsmLCDTable, and the snmpTsmLCDTmSecurityName column value used for tmSecurityName. [[ Otherwise, tmSecurityName should be set to be the same as the supplied securityName. ]] Create a tmStateReference cache with tmSecurityName set to the value determined above, tmRequestedSecurityLevel to the supplied securityLevel value, and tmSameSecurity to false. Qn: How should the securityName -> tmSecurityName mapping be done if there is an inconsistency between snmpTsmLCDTransformPolicy and snmpTsmLCDTmSecurityName? (i.e. a policy of 'default' and a value of tmSecurityName that doesn't match securityName) The full description above (including [[text]]) only references the snmpTsmLCDTable for non-default securityName mapping, and applies the identity mapping automatically (without requiring a snmpTsmLCDTable row at all). The previous text would apply a configured non-identity mapping even with the default policy for that transport domain. If this is the intended behaviour, it would be sensible to state this explicitly. Section 5.2 It would seem more natural to perform all of the validation steps first, before starting to populate the OUT parameter values. The specified procedure for determining the securityName (using a non-identity mapping) is wrong, since it actually sets the MIB table tmSecurityName column. This value is already provided in the tmStateReference cache. The following text proposes an alternative approach, that does map tmSecurityName to securityName. Note that as with the proposal for 4.2 above, this mapping only references the snmpTsmLCDTable for the non-default transform policy. 1) If tmStateReference does not refer to a valid cache, containing values for transportDomain, transportAddress, tmSecurityName and tmTransportSecurityLevel, then the snmpTsmInvalidCache ... 2) If there is no entry in snmpTsmLCDTransformTable corresponding to the specified transportDomain, or the corresponding value ... s/together with the OID and value of the incremented counter// s/Transport Security Model/Security Model/ 3) Compare the level of security provided by the transport (tmTransportSecurityLevel in the tmStateReference) with that required by the SNMP message (the securityLevel parameter passed in the processIncomingMsg ASI). If the transort security is weaker than that required, then the snmpTsmInadequateSecurityLevels counter is incremented, an error indication is returned to the calling module, and Security Model processing stops for this message. 4) Set securityEngineID to the local snmpEngineID. 5) If the snmpTsmLCDTransformPolicy value for the specified transportDomain is default(1), then set securityName to the value of tmSecurityName from the tmStateReference cache. If the snmpTsmLCDTransformPolicy value is private, then search the snmpTsmLCDTable for an entry with the specified transportDomain, transportAddress and securityLevel [[ XXX - or tmTransportSecurityLevel ?? ]] indexes, and a snmpTsmLCDTmSecurityName value that matches the value of tmSecurityName from the tmStateReference cache. If such a row is present, then set securityName to the corresponding snmpTsmLCDSecurityName index value. If no such row exists, calculate securityName from the specified tmSecurityName using the appropriate private algorithm. Create a row in the snmpTsmLCDTable indexed by the specified transportDomain, transportAddress, securityLevel [[ XXX - or tmTransportSecurityLevel ]] values and this calculated securityName. Set the snmpTsmLCDTmSecurityName column to the tmSecurityName from the tmStateReference cache. 6) Extract the scopedPDU from the wholeMsg. 7) Calculate the maxSizeResponseScopedPDU. [[ HOW ?? ]] This is the maximum size allowed for a scopedPDU for a possible Response message. 8) Create a cache containing the security data for this message, referenced by securityStateReference, so that a possible response can use the same security parameters. For the Transport Security Model, this security cache should include the tmStateReference. 9) Return a success indication to the calling module, passing the OUT parameters determined above. Qn: Should the tmSecurityName -> securityName mapping lookup be done using the securityLevel from the SNMP request (analogous with the outgoing case), or with the level provided by the transport layer (potentially flattening multiple parallel sessions into one)? Section 6 The summary of the MIB contents is slightly inaccurate. This MIB module provides management of the Transport Security Model. It contains three statistics objects, and two tables for managing the behaviour of the Transport Security Model. Section 6.3 A little more detail about the contents of the snmpTcmLCD subtree would probably be useful. 6.3.1 snmpTsmLCDTransformTable This table lists the [[ secure? ]] transports implemented by the SNMP entity, and indicates the securityName mapping policy used for traffic via each transport. This table should be populated automatically by the SNMP engine, with one row for each supported transport. 6.3.1 snmpTsmLCDTable This table provides details of the precise mapping between SNMP securityNames and transport-specific tmSecurityNames, for both existing and pre-configured user names. Qn: Is it necessary for the snmpTsmLCDTable to contain entries for fixed (identity (?)and prefix) mappings? Qn: Should the transform table list non-secure transports (e.g. traditional SNMP-over-UDP, SNMP-over-TCP, etc)? Section 6.4 The other relevant MIB to mention here would be the that belonging to the appropriate Access Control Model (typically the VACM MIB). a/ and the the appropriate Access Control Model MIB (for example, the SNMP-VIEW-BASED-ACM-MIB [RFC3415])/ Section 6.4.1 The Elements of Procedure don't actually make any mention of the snmpInASNParseErrs. s/'system' group/'snmp' group/g s/duplicate these objects/duplicate this object/ Delete sentences 3&4 (or possibly this whole section?). Section 6.4.2 s/definitions for the concepts of snmpEngineID,// s/object definitions/an object definition/ The securityLevel enumeration values will be used to implement the SNMP-TSM MIB. (new) Section 6.4.3 The Transport Security Model also maps between transport- provided identities and the SNMP securityName for use in the Access Control processing. It is therefore expected that an entity implementing the Transport Security Model will also implement the appropriate ACM MIB (such as the SNMP-VIEW-BASED-ACM-MIB [RFC3415]). Section 7, snmpTsmInadequateSecurityLevels s/by the application/by the application or SNMP PDU/ Section 7, snmpTsmLCDDomainTable The name of the table doesn't match that used in the definition of the snmpTsmLCDTransformEntry object. s/snmpTsmLCDDomainTable/snmpTsmLCDTransferTable/ Section 7, snmpTsmLCDTransformPolicy Qn: Should this object include a separate enumeration for the prefix mapping? Section 7, snmpTsmLCDTable The index objects are defined as "not-accessible", so should not be included in the example SET command. The distinction between internal operation and externally configured rows could be slightly clearer. s/may be instantiated/can be instantiated automatically/ s/, and they can be/. They may be explicitly/ s/snmpTsmLCDTransportDomain=(desired value),// s/snmpTsmLCDTransportAddress=(desired value),// s/snmpTsmLCDSecurityName=(desired value),// s/snmpTsmLCDSecurityLevel=(desired value),// Qn: Should this table list all known (existing and/or pre-configured) users, or just the non-default mappings? Section 7, snmpTsmLCDTransportDomain s/transport type/transport domain/ a/This indicates the Transport Model that will be used./ Section 7, sshTsmLCDTmSecurityName A human readable string representing the transport- authenticated identity to both the Transport and Security Models. It is passed between them in tmSecurityName. This may or may not be the same as sshTsmLCDSecurityName. Qn: Can this value be changed once a transport connection has been established? If so, what are the security implications of doing this? Qn: Can this value be set/changed to indicate a non-identity mapping, if the transform policy is set to default? Section 8 There is a certain amount of repetition in this description, particularly between the first two paragraphs. This document describes a Security Model, compatible with the RFC3411 architecture, that permits SNMP to utilise security services provided through an SNMP Transport Model. The Transport Security Model provides no security itself, but relies on a secure Transport Model to provide an authenticated principal for use in Access Control decisions, and an assertion of transport securityLevel to ensure confidentiality and integrity. It SHOULD always be used with a Transport Model that provides security, but this is a run-time decision of the operator or management application, or a configuration decision of the operator. The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Model and the underlying secure transport. Section 9, DISCUSS The choice of default ports is surely an issue for the Transport subsystem (i.e. individual Transport Model definition documents), rather than the Transport Security System. --------------010405080301050209010107 Content-Type: text/plain; name="SSH-comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="SSH-comments.txt" Secure Shell Transport ====================== Section 1.4 Much of the motivation description (paragraphs 1,2,5 & 6) feels too detailed for this particular document. Most of the justification is fairly generic, and would apply to the use of any secure transport. As such, this detailed description really belongs in the Transport subsystem document, rather than here. A much simpler description would be sufficient, with a reference to the fuller description in the Transport subsystem document. Widespread use of version 3 of the Simple Network Management Protocol (SNMPv3) with the User-based Security Model (USM) has been hampered by the need to deploy a separate user and key management infrastructure. Operators have reported a desire to unity the administrative security used for SNMP, with that used for Command Line Interfaces (CLI) and other management interfaces. [I-D.ietf-isms-tmsm] defines a Transport subsystem, designed to allow SNMP to take account of transport-layer security information. CLIs commonly use the security services provided by the Secure Shell, and this is also the approach being adopted for use with NETCONF [RFC4742]. This memo describes a method for invoking and running the SNP protocol within a Secure Shell (SSH) session. This provides for mutual authentication between client and server, data validation and confidentiality, and allows SNMP to make use of the SSH-authenticated identity in authorization policies for MIB data access. There are a number of challenges to be addressed .. detail below. Section 2, paragraph 2 The description of SSH post-connection processing (following the list of SSH components) is somewhat vague. A less general summary, more closely aligned to typical usage, might be more helpful. Once a secure transport layer connection has been established, [and the server identity verified?], the client sends a service request to initiate client-side user authentication. This is then typically followed by a second service request to establish an SSH Session. Section 3 s/Fits into the Transport Subsystem/ Fits into the SNMP Architecture/ Section 3.1.1 The threats are discussed in a different order to the list in the Transport subsystem document (which matches that in RFC3411). For consistency, it would probably be useful to always cover these threats in the same order. The descriptions for the main four threats feel somewhat short and unconvincing. There is typically a statement that the SSH Transport Model addresses this threat, with no justification or explanation of how this is achieved. The other three numbered points (4, 5 & 7) seem to be particular cases of the four main threats, and would be better presented as such. This would also address the lack of justification above. 1. Modification of Information - SSH provides for verification that the contents of each message has not been modified during its transmission through the network, by digitally signing each SSH packet. 2. Masquerade - SSH provides for verification of the identity of the SSH server through the SSH Transport Protocol server authentication ([RFC4253]). This allows an operator or management station to ensure the authenticity of the SNMP engine that provides MIB data. SSH also provides a number of mechanisms for verification of the identify of the SSH client-side principal, using the Secure Shell Authentication Protocol ([RFC4252]). These include public key, password and host-based mechanism. This allows the SNMP access control subsystem to ensure that only authorized principals have access to potentially sensitive data. 3. Message Stream Modification - SSH protects against malicious re-ordering or replaying of messages within a single SSH session by using sequence numbers and integrity checks. SSH protects against replay of messages across SSH sessions by ensuring that the cryptographic keys used for encryption and integrity checks are generated afresh for each session. 4. Disclosure - SSH protects against the disclosure of information to unauthorized recipients or eavesdroppers by encrypting all traffic between SNMP engines. Section 3.1.2, paragraphs 2/3 The distinction between the topics of the second and third paragraphs is not at all clear, even after multiple readings. The absolute prohibition on anything other than authPriv in paragraph 3 conflicts with the (weaker) recommendations elsewhere in the document (section 1.4, the first paragraph of this section, section 9). paragraph 2 s/type and address/address/ s/the SSH Transport Model provides/provides/ (new paragraph) The transport layer algorithms used to provide authentication, data integrity and encryption SHOULD NOT be exposed to the SSH Transport Model layer. The Transport Model must simply trust that the underlying SSH connection has been properly configured to support authPriv security characteristics. Outgoing messages specified with a securityLevel of noAuthNoPriv or authNoPriv, are actually sent by the SSH Transport Model with authPriv-level protection. Section 3.1.3, paragraph 2 The description of integration with other authentication mechanisms feels too detailed. A simpler description would probably be better: The password authentication mechanism allows for integration with deployed password-based infrastructure, such as RADIUS [RFC2865] or Diameter [RFC3588], either directly or using password validation protocols such as CHAP [RFC1994] or digest authentication [RFC5090]. Section 3.1.5 This material is effectively covered by the description of threats in section 3.1.1. It's probably not necessary to cover it again here. Drop this section altogether (and renumber the following section). Section 3.1.6, paragraph 4 s/transportAddressType/transportDomain/ Section 3.3, paragraph 2 This section is entitled "Notifications and Proxy", but the text concentrates on discussing notification handling. s/notifications/notifications or proxy requests/ Section 4 The introduction to this section should probably be replaced by the standard text proposed for the Cached Information and References section (X, X.1 and X.2), with a couple of minor tweaks: (common) Section X.2 paragraph 3: s/Transport Models/the SSH Transport Model/ append after the summary of tmStateReference cache fields: See the Elements of Procedures for detailed processing instructions on the use of these fields by the SSH Transport Model. The remainder of this standard text can be significantly simplified to concentrate on the particular requirements of the SSH Transport Model. 4.2.1. Transport information The tmStateReference cache for a given SSH connection should include information about the source of incoming SNMP messsages, so that this is accessible to transport-aware Security Models - transportDomain snmpSSHDomain (defined in the SSHTM-MIB, see section 7) - transportAddress the remote end of the SSH connection, represented as an snmpSSHAddress (defined in the SSHTM-MIB, see section 7) 4.2.2. securityName How the SSH transport principal is extracted from the SSH layer is implementation-dependent. By default, this will typically be taken from the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS has been received. The SSH protocol is not always clear on whether this user name field must be filled in, so for some implementations, it may be neccessary to retrieve the transport principal in some other way. How the SSH transport principal is mapped to/from a tmSecurityName should be administratively configurable, including whether this is a straight identity mapping, or some alternative transformation. The SSHTM-MIB (see section 7) includes a sshtLCDTransformPolicy object and sshtmLCDTable, which are used during the Elements of Procedure to determine this mapping. Transport Model transforms SHOULD generate predictable tmSecurityNames to represent transport principals. 4.2.3. securityLevel SSH transport connections are both verified and encrypted, so inherently offer the strongest securityLevel protection. - tmTransportSecurityLevel authPriv - tmRequestedSecurityLevel this value will be ignored for outgoing messages (since all SSH connections automatically provide an adequate level of security) 4.2.4. Session information The tmStateReference cache for an SSH connection SHOULD include a tmSessionID to indicate which SSH session it refers to. If the Transport Model receives an outgoing message with the tmSameSecurity parameter set, but the session identified in the tmStateReference does not match the current established SSH session for the specified transportDomain, transportAddress, tmSecurityName and tmRequestedSecurityLevel, then the message MUST be discarded, and the dispatcher notified that the sending of the message failed. Section 5 The ASIs relevant to the SSH Transport Model are the two defined in the Transport susbsystem document (receiveMessage and sendMessage), rather than those from RFC3411. The release of state information is included as part of the common description of Cached Information and References, and can therefore safely be omitted here. The description of error handling (which only applies to sendMessage) could usefully be simplified to concentrate on the primary error indication (the error counter OID and value) Abstract service interfaces for the Transport subsystem have been defined by [ID.ietf-isms-tmsm]. The SSH Transport Model uses these conceptual data flows when communicating with the Dispatcher. An error indication in statusInformation will typically include the OID and value for an incremented error counter. This may be accompanied by the requested securityLevel, and the tmStateReference. Per-message context information is not accessible to Transport Models, so contextEngine would be set to the local value of snmpEngineID, and contextName to the default context for error counters. It is unclear whether it's useful to discuss context here at all. Section 5.1 Most of this description is concerned with what should be done when accepting a new incoming SSH connection. Once such a connection has been established, it's probably not necessary to repeat all this processing for every subsequent message received on the same connection. It would be useful to separate the description of the processing required for accepting an incoming connection, from that for handling an incoming message. 5.1. Procedure for accepting an incoming SSH session The SSH Transport Model provides the following abstract service interface (ASI) to describe the data passed between the SSH service and the SSH Transport Model. It is an implementation decision how such data is passed. acceptSession( IN sourceTransportAddress IN sshPrincipal IN sshSessionID OUT tmStateReference ) The following describes the procedure to follow when establishing an incoming session to run SNMP over SSH. This will be done automatically for an SNMP application that receives an unsolicited transaction, such as a Command Responder, or a Notification Receiver. 1) Query the SSH engine, in an implementation-dependent manner, to determine the transportAddress that initiated the connection, the principal name authenticated by SSH and a session identifier. By default, the principal name will be the value of the user name field of the SSH_MSG_USERAUTH_REQUEST, for which a SSH_MSG_USERAUTH_SUCCESS was sent. How this name is extracted from the SSH environment is implementation-dependent. 2) Determine the tmSecurityName corresponding to the sshPrincipal parameter. If the SSH Transport Model is using the identity mapping (as indicated by the sshtmLCDTransformPolicy object), this will be the same as the sshPrincipal parameter. Otherwise, the tmSecurityName should be determined by an implementation- specific mapping algorithm. [[[ XXX - How - via a reverse-lookup in ssmtmLCDTable? ]]] 3) Create a tmStateReference cache containing the following values: transportDomain = snmpSSHDomain (defined in SSH-TM, see section 7) transportAddress = sourceTransportAddress parameter tmSecurityName = the value determined in step 2) above tmTransportSecurityLevel = authPriv tmSessionID = sshSessionID parameter 4) Create an entry in the sshtmLCDTable containing the values: sshtmTransportAddress = sourceTransportAddress parameter sshtmLCDTmSecurityName = tmSecurityName (from step 2) above) sshtmLCDPrincipal = sshPrincipal parameter sshtmLCDSessionID = sshSessionID parameter sshtmStorageType = volatile(2) sshtmRowStatus = createAndGo(4) Return the tmStateReference cache for this session. 5.2. Procedure for an incoming message Retrieve the tmStateReference for the SSH session used to receive the incoming message. Pass the message to the Dispatcher using the following ASI: statusInformation = receiveMessage( IN transportDomain -- snmpSSHDomain IN transportAddress -- from tmStateReference cache IN wholeMessage IN wholeMessageLength IN tmStateReference ) Qn: Could a row exist in the sshtmLCDTable before the corresponding SSH session was established (e.g. to pre-configure a suitable mapping between SSH principal and tmSecurityName). Or would creating such a row automatically establish the connection? In either case, presumably establishing the session should set the value for tmSessionID (and perhaps make the row active) Qn: Would it be sensible to have a separate sshtmSessionAccepts counter? Or should incoming sessions be included in sshtmSessionOpens? Section 5.3 The description is somewhat confusing in places, and would benefit from a slight simplification and clarification. Some of the processing specified is actually related to sending an outgoing message, rather than opening a new SSH session. The maxMessageSize IN parameter is never actually used. There is no mechanism for returning the SSH session paragraph 1 s/application service interface/abstract service interface/ ASI definition d/IN maxMessageSize/ a/OUT sshSession/ step 1) s/using the SSH transport protocol// s/used to authenticate/used to authenticate the server/ s/and an OpenSession error indication/an error indication/ 2) If sshtmLCDTransformPolicy is default, the SSH principal is set to tmSecurityName. Otherwise, the SSH principal is calculated from tmSecurityName using the implementation-specific mapping algorithm. This principal is passed to the SSH layer for authentication. The credentials and authentication service to use are determined in an implementation-dependent manner. If authentication is unsuccessful, then the transport connection is closed, the sshtmSesssionUserAuthFailures counter is incremented, an error indication is returned to the calling module, and OpenSession processing stops. 3) Once the principal has been successfully authenticated, the client should invoke the "ssh-connection" service, request a channel of type "session", [and set up an "snmp" subsystem]. If unsuccessful, then the transport connection is closed, the sshtmSesssionChannelOpenFailures counter is incremented, an error indication is returned to the calling module, and OpenSession processing stops. 4) If successful, this will result in an SSH session. Create an entry in the sshtmLCDTable, indexed by destTransportAddress and tmSecurityName, containing sshtmLCDPrincipal = the SSH principal determined in step 2) sshtmLCDSessionID = the ID of the session just established The sshtmSessionOpens counter should be incremented, and the SSH session returned to the calling module. Qn: The discussion of SSH subsystems is somewhat unclear, but feels more like implementation/configuration recommendations rather than Elements of Procedure. It might perhaps be better included elsewhere in the document. Where? Qn: Should a failure to set up an "snmp" subsystem trigger a SessionChannelOpenFailure error? Qn: This text also refers to an IANA-assigned TCP port, but this is never discussed anywhere in this document. Section 5.2 It might be more sensible to discuss the processing of outgoing messages *after* the procedures for opening a session (following the model of accepting a session/receiving a message above). There is no provision in the sshtmLCDTable for implementation-specific parameters - using the MIB table for this seems inappropriate. 5.4. Procedure for sending an Outgoing Message 1) Use the transportAddress and tmSecurityName from the tmStateReference to determine if a corresponding row exists in the sshtmLCDTable. 2) If there is such a row, extract tmSameSession and tmSessionID from the tmStateReference cache. If tmSameSession is true, and tmSessionID does not match sshtmLCDSessionID, .... 3) If there is no such row, then call OpenSession with transportAdddress and tmSecurityName as parameters. If OpenSession fails, then discard the message, release tmStateReference and pass the error indication returned by OpenSession back to the calling module. Processing stops for this message. 4) Pass the outgoingMessage to SSH for encapsulation as data in an SSH message over the specified SSH session (returned from OpenSession or identified by tmSessionID). Any necessary additional SSH-specific parameters should be provided in an implementation-dependent manner. Qn: This description uses transportAddress from the tmStateReference cache, rather than the IN parameter (destTransportAddress). Is this IN parameter ever used, or simply ignored? Qn: How should this ASI handle an incomplete/invalid tmStateReference cache? Or is such an occurrance Simply Not Possible? Section 5.4 Qn: Is 'closeSession' invoked (conceptually) for remote-initiated session termination as well? Section 6 This MIB module provides management of the Secure Shell Transport Model. It defines an OID to identify the SNMP-over-SSH transport domain, a textual convention for SSH Addresses, several statistics counters and a MIB table representing the SSH Transport Model Local Configuration Datastore (LCD). Section 6.3 The Transport susbsystem document does not define a MIB module. The second paragraph talks about what this MIB provides (rather than its relationship with other MIB modules). This has already been covered at the start of this main section. It might also be worth mentioning the Transport Security Model. s/and the SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm]// It is expected that an entity implementing this MIB will also support the Transport Security Model [I-D.ietf-isms-tsm], and therefore implement the SNMP-TSM-MIB. Section 7, SnmpSSHAddress definition paragraph 3 s/a dotted decimal/in dotted decimal/ paragraph 4 s/surrounded by brackets/surrounded by square brackets/ paragraph 5 s/may not be useable/may not necessarily be useable/ (warning, rather than prohibition) Reference s/RFC3896/RFC3986/ Qn: The purpose of paragraph 7 is not particularly clear. If the TC should not be used, then what is the point of providing this definition? Qn: This type is described purely in terms of IP addresses (or hostnames). Is it intended to support SSH-over-nonIP transports as well? If not, should the snmpSSHDomain description (?and name) be tweaked to make this restriction explicit? Section 7, sshtmLCDSpinLock The comment immediately before the ssmtmLCDSpinLock definition feels like a cut-and-paste error from the SNMP-TSM-MIB. Delete these two lines Section 7, sshtmLCDTable definition The index values (TransportAddress and TmSecurityName) are defined as "not-accessible", so should not be included in the example SET. Qn: What is the intended behaviour of creating an entry in this table? Should that attempt to open a corresponding SSH session automatically, or would SNMP-created rows be used to pre-configure a non-identity mapping between SSH principal and tmSecurityName? It's not clear how an external SNMP command could possibly know the appropriate SSH session ID to specify for a future SSH session (and the spinLock value is almost guaranteed to be wrong!). It would be more appropriate to omit this varbind, and leave the SSH transport model to supply the appropriate value. s/sshtmLCDTransportAddress=(desired value),// s/sshtmLCDTmSecurityName=(desired value),// s/sshtmLCDSessionID=sValue,// Section 7, sshtmLCDTmSecurityName A human readable string representing the transport-authenticated identity to both the Transport and Security Models. It is passed between them as tmSecurityName. This may or may not be the same as sshtmLCDPrincipal. Qn: How would the definition of this object be affected by the proposed use of transport-prefixes in the Transport Security Model tmSecurityName <-> securityName mapping? Should the size of this object be reduced, or should the prefix be added by the Transport Model itself? Section 7, sshtmLCDPrincipal A human readable string representing the transport-authenticated identity in an implementation-specific manner. It is only used within the SSH Transport Model itself, and is typically the SSH user name. This may or may not be the same as sshtmLCDTmSecurityName. Section 7, sshtmLCDSessionID The definition for this object is missing altogether! I suspect that this column should probably be defined as 'read-only' (and documented as being provided by the SSH engine). Section 7, sshtmLCDRowStatus Qn: Does the value of this object ('active' vs 'notInService') indicate whether there is a corresponding established SSH session? If so, then it would be sensible to document this. Qn: The description states that the principal value can only be changed when the row is 'active'. Is it realistic to try and change the transport-authenticated identity once the session has been established? It would seem more natural either to only allow changing the principal for inactive rows (i.e. when preparing the configuration settings for future connections), or to forbid amending existing rows (apart from deleting the row altogether). Qn: Should deleting a row from this table, automatically close the corresponding SSH session? If so, then it would be sensible to document this. Section 7, sshtmGroup It would probably be more flexible to define this as two separate groups. One containing the statistics objects, and one containing the LCD table and related scalars. Even if both groups are defined as mandatory, this separation would allow more focused descriptions. Section 8, paragraph 2 This document does not seem to define any well-known ports for use by SNMP-over-SSH. paragraph 1 s/instead of/to supplement/ Delete paragraph 2 Section 8, paragraph 2 This description includes an unnecessary level of detail, which serves to obscure the main point. The SSH protocol has its own window mechanism, defined in RFC 4254. The SSH specifications leave it open when window adjustments messages should be created, and some implementations send these whenever received data has been passed to the application. There are noticeable bandwidth and processing overheads to handling such window adjustment messages, which can be avoided by sending them less frequently. Section 9 The various subsections seem to appear in a somewhat random order. It would probably be clearer to discuss the three SSH-level security considerations, before moving on to SNMP/MIB-related issues. The titles of these subsection describe SSH protocol-level details, which are possibly not familiar to non-SSH-experts. More general titles (describing "what" rather than "how") would be helpful. (see proposals below) Section 9.1 The first two paragraphs (justifying the use of userauth "none") seem to be inconsistent with the third (recommending against this). A simpler description would perhaps be less confusing. 9.1. Skipping client authentication SSH includes the "none" userauth method, which could in principle be used to support access by anonymous clients. This would not compromise the authentication of the server to the clients, nor data confidentiality or data integrity. However such a configuration effectively provides a securityLevel of "noAuthPriv", which is not permitted by RFC 3411. The SSH Transport Model SHOULD NOT be used with an SSH connection using the "none" userauth method. Qn: Why is this SHOULD NOT rather than MUST NOT ? This text may well be an over-simplification, in which case it would be useful to give a clearer description of when/how anonymous access can provide an authenticated principal. Section 9.2 The issues discussed here are not specific to community-based versions of SNMP. The same considerations would apply to SNMPv3 with USM, or any other non-transport-aware Security Model. 9.4 Use with non-transport-aware Security Models. The SNMPv1 and SNMPv2c message processing described in [RFC3584] always select the SNMPv1 or SNMPv2c Security Models respectively. Both of these, and the User-based Security Model typically used with SNMPv3, derive the securityName and securityLevel from the SNMP message received, even when the message was received over a secure transport. Access control decisions are therefore made based on the contents of the SNMP message, rather than using the authenticated identity and securityLevel provided by the SSH Transport Model. Section 9.3 9.2. Skipping server authentication s/if this step is skipped/ if this step is skipped (e.g. by blindly accepting the offered public key)/ Start new paragraph before "Data confidentiality" Section 9.4 9.3. Skipping data integrity validation SSH provides the "none" MAC algorithm, which disables the validation of data integrity, while maintaining data confidentiality. However if this is done, then an attacker might be able to modify the data in flight, thus compromising both data integrity and authentication. SSH MUST NOT ... Qn: Wouldn't this also compromise the confidentiality of returned data? Section 9.5 The MIB module _does_ contain writeable objects (paragraph 1), which affect the mapping between SSH principal and tmSecurityName (and hence the SNMP securityName). These could be used to subvert SNMP-level access control restrictions. The values of SSH principals and tmSecurityName could themselves be sensitive (pararaph 2), as might the addresses of communicating SNMP engines. Section 10, item 1 IANA is requested to assign a default port for SNMP-over-SSH. But nowhere in this document is there a placeholder location for this port number to be specified. --------------010405080301050209010107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --------------010405080301050209010107-- From isms-bounces@ietf.org Wed Aug 20 14:56:33 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCC13A680E; Wed, 20 Aug 2008 14:56:33 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A727B3A6899 for ; Wed, 20 Aug 2008 14:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj1Yhpiij1HH for ; Wed, 20 Aug 2008 14:56:14 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 626873A6816 for ; Wed, 20 Aug 2008 14:56:14 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 15FFE985E2 for ; Wed, 20 Aug 2008 14:55:37 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id CA53039A277 for ; Wed, 20 Aug 2008 14:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=tVApdt0FkmKiE+HvoRm17vIQSgk=; b=PFTPOhYiA0iKJvmC7iXn48rd7xua PEOg7yrN9970aTTA5T/5rMJuCA9ZupHpvMI6aV22IM2AvDYOzWt/Z+JnqxXACA41 05XMuvGOIQ08/w835Wuqclc6u8Pi7zNJogOABWSI5IcO/l1zCGpe5Q/FQOKRNwoN 9s0FwLrhLc6ekGM= Received: by wes.hardakers.net (Postfix, from userid 274) id 5278A39A292; Wed, 20 Aug 2008 14:55:36 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Wed, 20 Aug 2008 14:55:35 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] Security/Protocol Naming agreement: take II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org At the last IETF and over the mailing list we discussed having securityNames handed up by TMs to be prefixed with a PROTO: name type tag, where PROTO: would be ssh: dtls: etc. I won't rehash why this was desired as that's in the list archives (and minutes). But I'm going to revamp my write up of what I thought was close to consensus (which I'll leave to the chairs to decide if it's been reached). I know David understandable wanted as concrete proposals as possible and this text is an update only to serve that purpose. David, of course, you're free to change the text at will as you think is necessary. I'm just trying to be helpful and provide as much starting ground for you as possible :-) - Adds an IANA considerations sections (which IANA assignment method is used is probably subject to debate. I'd argue flexibility should be a good thing, but willy-nilly is probably overkill. And thus "Specification Required" is specified below, but "Expert Review" would probably bee an adequate choice as well) - Adds in a few more references to the - Clarifies where I think the text needs to be added in the documents. - Clarified what steps need modification to deal with the prefix Proposed wording/changes: == In the TMSM document: =================================================== In section 3.2.2.1 at the end of the second paragraph add (or add as a new 3rd paragraph on its own): "Documents defining a new TM specification MUST define a security name prefix that will be pre-pended to all passed securityNames. Implementations MUST pre-pend this prefix to the security-model independent securityName used for subsequent processing. This prefix MUST be defined from 1-4 securityName compatible octets followed by a ':' (ASCII 0x3a) character. Prefix names are coordinated by the IANA registry XXX. This prefix is defined solely as a signaling mechanism and should not be considered part of the Elements of Procedure for securityNames, unless otherwise specified. [NOTE to RFC editor: please replace XXX with the IANA established registry reference]" In section 3.2.4 add this sentence to the end of the 6th paragraph: The transport-model specific prefix string that gets prepended to the securityName field for incoming messages, as discussed in section 3.2.2.1, can be used by architecture components like the Security Model or Access Control Model to distinguish between transport protocols that a message may have been received over. Section 6.3, first paragraph: Change "securityName" to "transport model prefixed securityName" The last paragraph of Section 7 (Security Considerations) should be appended with: A security transport model prepends a prefix string and an ascii colon to the front of a securityName to provide the security model with additional information to aid in its securityName selection process. Replace section 8 (IANA Considerations) with: This document describes a new prefix registry that has been created by IANA. This registry, discussed in section 3.2.2.1, will contain 1-4 length ASCII string prefixes to be prepended by transport modules to securityNames when incoming messages are received. Values are to be assigned via RFC2434 "Specification Required". == In the TSM document: ================================================= In section 2.3, last paragraph add: ... "and to leave or strip ASCII string transport prefixes from securityNames." In section 5.2, replace step 4 with: If the tsmStripSecurityNamePrefix object is set to false then set the securityName to the value of tmSecurityName from the cache referenced by tmStateReference. If the tsmStripSecurityNamePrefix object is set to true then set the securityName to the portion of the value of tmSecurityName beyond the first colon (':', ASCII 0x3a). 4) Set securityName to the value of tmSecurityName from the cache referenced by tmStateReference. If the tsmStripSecurityNamePrefix object indicates that the TM prefix should be removed (i.e., its value is false(2)), remove everything up to and including the first ':' (ASCII 0x3a) character in the securityName value. Section 7, add the following objects (or similar) to the MIB: snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 3 } tsmStripSecurityNamePrefix OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the transport modules string prefix will be removed before being passing the securityName to the message processing model. If set to true, the string prefix will be removed. If set to false, the string prefix will be left in place in front of the securityName passed up from the transport. In particular authorization decisions made by an Access Control Module (e.g. the VACM) will be able to use this transport prefix in it's authorization decisions if this object is set to 'false'. If set to 'true' then the TSM security model will strip the leading prefix and, for example, 'ssh:david' will become 'david' for purposes of authorization verification." DEFVAL { true } ::= { } (And add the tsmStripSecurityNamePrefix object to the snmpTsmGroup group) Section 8, update the second paragraph to read: Transport Security Model relies on a Transport Model to provide an authenticated principal that has been prefixed with the assigned Transport Model's prefix name for mapping to securityName, and an assertion of tmTransportSecurityLevel. == In the SSH document ================================================== In section 3.1.1, append to bullet 4: The securityName provided by the SSH transport model is prefixed with "ssh:" to provide consuming SNMPv3 modules (like a security model) to understand what transport a given securityName originated from. In section 4.1, for the line starting "tmSecurityName =" change to: tmSecurityName = the concatenation of the ASCII string "ssh:" with the principal name [to be] authenticated by SSH. See the section on tmSecurityName below. In section 4.2, change the second paragraph to: tmSecurityName is a human-readable name in SnmpAdminString format that is mapped from the identity that has been successfully authenticated by SSH. By default, tmSecurityName is created by concatinating the ASCII string "ssh:" with the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS has been received. In section 4.2, add in a new second sentence to the 4th paragraph (IE, after the sentence "The SSH protocol is not always clear..."): Regardless of what mapping system may be utilized, the implementation must prefix the resulting tmSecurityName with "ssh:". In section 5.1, step 2 add a second sentence: Note: The calculated value at this point should not include the "ssh:" prefix. And in step 4 of 5.1: tmSecurityName = "ssh:" | sshtmLCDTmSecurityName In section 5.2 in step 1 add a second sentence: Remove the "ssh:" prefix from the tmSecurityName found in the tmStateReference for processing purposes in these steps. In section 10 (IANA Considerations) add: 5) "ssh" as a prefix assignment in the XXX registry which will indicate the prefix string to attach to securityNames returned by the SSH Transport model -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 03:10:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D023A6B43; Mon, 25 Aug 2008 03:10:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C10C3A6B43 for ; Mon, 25 Aug 2008 03:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlIB2OLfBduo for ; Mon, 25 Aug 2008 03:10:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 08D263A6B33 for ; Mon, 25 Aug 2008 03:10:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58305C001D; Mon, 25 Aug 2008 12:10:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xdK8zkGZQFgH; Mon, 25 Aug 2008 12:10:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBDACC0021; Mon, 25 Aug 2008 12:10:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 07AAD6AE8FA; Mon, 25 Aug 2008 12:10:00 +0200 (CEST) Date: Mon, 25 Aug 2008 12:10:00 +0200 From: Juergen Schoenwaelder To: Dave Shield , Dave Harrington Message-ID: <20080825101000.GA23809@elstar.local> Mail-Followup-To: Dave Shield , Dave Harrington , isms@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Comments on ISMS drafts X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Aug 11, 2008 at 11:25:19PM +0100, Dave Shield wrote: > As part of preparing for the ISMS session at IETF 72, I read through > most of the relevant drafts shortly before the meeting. As someone > coming to this from an SNMP perspective, with no particular security > expertise, I found the proposed mechanisms to be reasonably clear > and understandable. However, in a number of places throughout the > various drafts, I sometime had to read a section two or three times > to be sure that I had grasped what was being proposed. > > In particular, there are several concepts common to the Transport > Subsystem and Transport Security Model, and hence covered in both > (or all three) documents. However the individual descriptions are > sometimes incomplete or inconsistent. It proved necessary to read > all three documents in detail, to fully understand what is required. > Similarly, the terminology used is not entirely consistent between > the three documents. > > I therefore offer the attached comments as a (somewhat verbose!) > attempt to clarify text that I found to be less than straightforward to > follow. In most cases, I don't believe that these suggestions should > affect the content of the proposals themselves - they are mostly > simply wordsmithing of the descriptive text. > > There are also a number of places where I found the current drafts > ambiguous or inconsistent. I have attempted to identify these issues > and sometime propose possible solutions. These may involve some > minor amendments to the proposed behaviour - particularly as relating > to the mapping of security names. Dave, many thanks for your reviews and the detailed comments. Since many comments are more editorial, I would like to ask David Harrington to make a first pass through your comments to identify any comments that according to his judgement are more than just editorial and require the attention of the WG. For any of those comments, we should start separate discussion threads to find a resolution. David Harrington, is that approach OK with you? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 14:12:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C943A6BCC; Mon, 25 Aug 2008 14:12:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985953A6BCC for ; Mon, 25 Aug 2008 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ke2LT-aJAs9 for ; Mon, 25 Aug 2008 14:12:46 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 77B8D3A6885 for ; Mon, 25 Aug 2008 14:12:46 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 3EBF498047 for ; Mon, 25 Aug 2008 14:12:01 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E5DD539A273 for ; Mon, 25 Aug 2008 14:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=zVlZZdDwuvGzje5XowOwM31rWlk=; b=BZ5/h5vUzR4tM4a6CYgwtwXS4Uzk /RRpjz2eLQcMx1j9wvhZgjRMoDxBsIviA/MScPURkrJLOmtaPOpjfi94AY+Zi0t/ nW0E5z2/es6vcsSfZ44aaWSrn/Ts7XxdnwrUyTM1zY3JL9TowM77d45OgTFqrn26 B5n1TYKuhpKvRuA= Received: by wes.hardakers.net (Postfix, from userid 274) id BF60139A293; Mon, 25 Aug 2008 14:11:59 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Mon, 25 Aug 2008 14:11:57 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] user@address:port proposal for secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org We discussed this in the meeting and it's unclear that consensus on it has been reached, but I wanted to spell out the details of what would need to be changed if we support what I outlined in: From: me Subject: [Isms] Proposed SSH Transport Address Changes (and a quick nit) Date: Thu, 03 Jul 2008 09:43:05 -0700 Specifically, if you'll recall, I was proposing allowing for these since SSH users are familiar with the syntax, and as Pasi pointed out in the meeting we can name both sides of the connection in an bidirectional/asymmetric authentication protocol: wes@127.0.0.1:161 wes@host.example.com:161 wes@[::1]:161 The list of document changes to the secshell draft that are need to support this (IMHO) are really only 2 small changes and a possible large deletion: * Section 5.3, bullet 1: - Change: OLD: "The parameters of the transport connection and the credentials used to authenticate are provided in an implementation-dependent manner." NEW: "The destTransportAddress field may contain a "USER@" style prefix that will indicate a specific string that should presented to the ssh server as the "user name" for authentication purposes. This may be different than the passed tmSecurityName value which should be used in the remaining steps. The parameters of the transport connection and the credentials used to authenticate are provided in an implementation-dependent manner." * Section 7 in the MIB Module - The SnmpSSHAddress should be modified to allow for the new leading prefix. Suggest a rewrite of the beginning text to the following (adding bits and pieces to make it work): "Represents either a hostname with a port number, an IP address with a port number, a username, hostname and port number or a username, IP address and port number. The beginning of the address specification may contain a username followed by an '@' (ASCII character 0x40). This portion of the address will indicate the user name that should be used when authenticating to an SSH server. If missing, the SNMP securityName should be used. After the optional user name field and '@' character comes the hostname. The hostname must be encoded in ASCII, as specified in RFC3490 (Internationalizing Domain Names in Applications) followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. The name SHOULD be fully qualified whenever possible. An IPv4 address must be a dotted decimal format followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. An IPv6 address must be a colon separated format, surrounded by brackets ('[' ASCII character 0x5B and ']' ASCII character 0x5D), followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. Values of this textual convention may not be directly useable ... continue as before ... * I THINK the sshtmLCDTable object can be removed after completion of this since the mapping is no longer needed. The authentication credentials to be used I think can be safely pulled using the user@ part of the transport address string in an implementation dependent way. This is how current ssh implementations mostly work so I think it matches common current practice better than a separate mapping table. - It's possible the whole table could be removed, but leaving it in allows for deletion of active sessions and session activity monitoring. - But if we leave it, it should be noted that the current MIB has a sshtmLCDSessionID specified in the entry sequence, but the column doesn't actually exist in the table currently! -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 14:42:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD50C3A681C; Mon, 25 Aug 2008 14:42:30 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319893A677D for ; Mon, 25 Aug 2008 14:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kybFrnAzfeQj for ; Mon, 25 Aug 2008 14:42:28 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 46C303A6983 for ; Mon, 25 Aug 2008 14:42:28 -0700 (PDT) Received: from 68-247-18-128.area3.spcsdns.net (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7PLfiVf007472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 17:41:45 -0400 (EDT) Date: Mon, 25 Aug 2008 17:41:42 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , ISMS WG Message-ID: In-Reply-To: <200808202156.m7KLumMf027871@grapenut.srv.cs.cmu.edu> References: <200808202156.m7KLumMf027871@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] Security/Protocol Naming agreement: take II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, August 20, 2008 02:55:35 PM -0700 Wes Hardaker wrote: > > At the last IETF and over the mailing list we discussed having > securityNames handed up by TMs to be prefixed with a PROTO: name type > tag, where PROTO: would be ssh: dtls: etc. I won't rehash why this was > desired as that's in the list archives (and minutes). But I'm going to > revamp my write up of what I thought was close to consensus (which I'll > leave to the chairs to decide if it's been reached). This all sounds good to me. However, it's not clear to me from your text what the default value of tsmStripSecurityNamePrefix is supposed to be. My impression from the meeting was overall happiness would be maximized by making the default value be "true". I personally don't care, but I believe that it should be specified. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 14:44:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40193A6983; Mon, 25 Aug 2008 14:44:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F163A6984 for ; Mon, 25 Aug 2008 14:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3bm2fRWCm2Y for ; Mon, 25 Aug 2008 14:44:33 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 9343A3A6983 for ; Mon, 25 Aug 2008 14:44:33 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id C4E879805A; Mon, 25 Aug 2008 14:43:51 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 9691739A273; Mon, 25 Aug 2008 14:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=Pht7oxcTvUwmqNS1JDh1XWqSLhY=; b=K3LH b1ymcJxR85Y4G+hvLMBGpN/XTGayuVR+kMA6KtyFW/Aec0amNr73oSIL4VbIOgUy qQ3OrzXJwEWsUO5j7QGRFaAIkgy1QXuLH7wbS7286uarXBGrh24vLnSJfOxXrfa6 81uGM3Zo6S4jV7PTQ5vWfd1twydePIViborPKRg= Received: by wes.hardakers.net (Postfix, from userid 274) id 71D5039A293; Mon, 25 Aug 2008 14:43:51 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200808202156.m7KLumMf027871@grapenut.srv.cs.cmu.edu> Date: Mon, 25 Aug 2008 14:43:51 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 25 Aug 2008 17:41:42 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] Security/Protocol Naming agreement: take II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 25 Aug 2008 17:41:42 -0400, Jeffrey Hutzelman said: JH> This all sounds good to me. However, it's not clear to me from your JH> text what the default value of tsmStripSecurityNamePrefix is supposed JH> to be. My impression from the meeting was overall happiness would be JH> maximized by making the default value be "true". I personally don't JH> care, but I believe that it should be specified. It was specified in the object description: DEFVAL { true } I agree, that was the consensus. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 14:50:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488163A69B1; Mon, 25 Aug 2008 14:50:21 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE35F3A69AB for ; Mon, 25 Aug 2008 14:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZqQCMA+EfVN for ; Mon, 25 Aug 2008 14:50:19 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 7E9ED3A69B1 for ; Mon, 25 Aug 2008 14:50:19 -0700 (PDT) Received: from 68-247-18-128.area3.spcsdns.net (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7PLn8GK007960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 17:49:09 -0400 (EDT) Date: Mon, 25 Aug 2008 17:49:06 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <51209389F5665D651F791474@atlantis.pc.cs.cmu.edu> In-Reply-To: <200808252144.m7PLibwZ012570@toasties.srv.cs.cmu.edu> References: <200808202156.m7KLumMf027871@grapenut.srv.cs.cmu.edu> <200808252144.m7PLibwZ012570@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: ISMS WG , jhutz@cmu.edu Subject: Re: [Isms] Security/Protocol Naming agreement: take II X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Monday, August 25, 2008 02:43:51 PM -0700 Wes Hardaker wrote: >>>>>> On Mon, 25 Aug 2008 17:41:42 -0400, Jeffrey Hutzelman >>>>>> said: > > JH> This all sounds good to me. However, it's not clear to me from your > JH> text what the default value of tsmStripSecurityNamePrefix is supposed > JH> to be. My impression from the meeting was overall happiness would be > JH> maximized by making the default value be "true". I personally don't > JH> care, but I believe that it should be specified. > > It was specified in the object description: > > DEFVAL { true } Oh, so it was. I missed that. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 14:55:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D2B28C0DF; Mon, 25 Aug 2008 14:55:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E213A69B1 for ; Mon, 25 Aug 2008 14:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm1eL5ZeVcMm for ; Mon, 25 Aug 2008 14:55:35 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 346673A6877 for ; Mon, 25 Aug 2008 14:55:35 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 7880998087; Mon, 25 Aug 2008 14:54:45 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 46F3039A273; Mon, 25 Aug 2008 14:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=3+44179i68+LELgxuF6kZaWgiPI=; b=sAnS 6ow9aHq0kblcbQy5ghEblc5/z9ubjtDo/2Q6Os7EXYxMc+nf4A5/XHYUDIoDlgW1 OVKBhU0Pv1E/5YId9zWi3mQikp4i7C38QQAOtjcR1GT4IcxTs9LimXb9CYl9ZIE/ wm7rEC/C21PTWPR1qTOvy9fNpQSo+v7A1BGKykI= Received: by wes.hardakers.net (Postfix, from userid 274) id 21DF139A293; Mon, 25 Aug 2008 14:54:45 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200808252112.m7PLCqnp022062@toasties.srv.cs.cmu.edu> Date: Mon, 25 Aug 2008 14:54:44 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 25 Aug 2008 17:48:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] user@address:port proposal for secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 25 Aug 2008 17:48:38 -0400, Jeffrey Hutzelman said: JH> "Represents either a hostname or IP address, along with a port JH> number and an optional username". that's fine with me. JH> "Represents either a hostname or IP address, along with an JH> optional port number and/or username". The port number isn't optional, so that doesn't work. JH> The latter, of course, implies a change to make the ":port" part be JH> optional. I don't recall whether we've already discussed this, but JH> I'm not sure I see a need to require specification of a port. Most of the current SNMP transport specifications include a port number so I suspect that's the reason for ensuring it's always there (then again, though, most transport address specs are binary encoded not ascii text). I thought about bringing up whether it should be optional or not, but never had a good reason why it would be beneficial to be optional... Personally, I don't care too much. The only question comes when two different implementations use two different default values for port numbers. >> * I THINK the sshtmLCDTable object can be removed after completion >> of this since the mapping is no longer needed. JH> Perhaps. I suspect you'll end up wanting some way to provide actual JH> credentials to be used, such as a public/private key pair, but it's JH> possible the mechanism for managing that can be JH> implementation-dependent. Well, last time I suggested that a zillion people screamed that's out of scope of the WG and that the best that could be done would be a lookup key/string for now ;-) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 15:03:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730383A69E3; Mon, 25 Aug 2008 15:03:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3F13A69E3 for ; Mon, 25 Aug 2008 15:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqiqkE0yGsau for ; Mon, 25 Aug 2008 15:03:08 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 1701F3A69B1 for ; Mon, 25 Aug 2008 15:03:07 -0700 (PDT) Received: from 68-247-18-128.area3.spcsdns.net (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7PM2PT9008744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 18:02:26 -0400 (EDT) Date: Mon, 25 Aug 2008 18:02:23 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <5DB0B2070285978B7C1D5C01@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <200808252112.m7PLCqnp022062@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: ISMS WG , jhutz@cmu.edu Subject: Re: [Isms] user@address:port proposal for secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Monday, August 25, 2008 02:54:44 PM -0700 Wes Hardaker wrote: > JH> The latter, of course, implies a change to make the ":port" part be > JH> optional. I don't recall whether we've already discussed this, but > JH> I'm not sure I see a need to require specification of a port. > > Most of the current SNMP transport specifications include a port number > so I suspect that's the reason for ensuring it's always there (then > again, though, most transport address specs are binary encoded not ascii > text). > > I thought about bringing up whether it should be optional or not, but > never had a good reason why it would be beneficial to be optional... Well, there is a default port for SSH. Presumably there will be a standard port for SNMP-over-SSH, though it's unclear to me whether it should be the same as the default port for SSH or something different. It seems counterproductive for users to have to know that SSH uses port 22. > Personally, I don't care too much. The only question comes when two > different implementations use two different default values for port > numbers. Well, I think we'd have to standardize the default port if we did this. >>> * I THINK the sshtmLCDTable object can be removed after completion >>> of this since the mapping is no longer needed. > > JH> Perhaps. I suspect you'll end up wanting some way to provide actual > JH> credentials to be used, such as a public/private key pair, but it's > JH> possible the mechanism for managing that can be > JH> implementation-dependent. > > Well, last time I suggested that a zillion people screamed that's out of > scope of the WG and that the best that could be done would be a lookup > key/string for now ;-) Well, that's probably true. I was probably even one of those people. :-) -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 15:13:53 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDCB3A6A1E; Mon, 25 Aug 2008 15:13:53 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC393A69E0 for ; Mon, 25 Aug 2008 15:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrI0CRipEl5B for ; Mon, 25 Aug 2008 15:13:51 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id B17873A6A1A for ; Mon, 25 Aug 2008 15:13:50 -0700 (PDT) Received: from 68-247-18-128.area3.spcsdns.net (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7PLmd9w007932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 17:48:40 -0400 (EDT) Date: Mon, 25 Aug 2008 17:48:38 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , ISMS WG Message-ID: In-Reply-To: <200808252112.m7PLCqnp022062@toasties.srv.cs.cmu.edu> References: <200808252112.m7PLCqnp022062@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] user@address:port proposal for secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Monday, August 25, 2008 02:11:57 PM -0700 Wes Hardaker wrote: > > We discussed this in the meeting and it's unclear that consensus on it > has been reached, but I wanted to spell out the details of what would > need to be changed if we support what I outlined in: > > From: me > Subject: [Isms] Proposed SSH Transport Address Changes (and a quick nit) > Date: Thu, 03 Jul 2008 09:43:05 -0700 > > Specifically, if you'll recall, I was proposing allowing for these since > SSH users are familiar with the syntax, and as Pasi pointed out in the > meeting we can name both sides of the connection in an > bidirectional/asymmetric authentication protocol: > > wes@127.0.0.1:161 > wes@host.example.com:161 > wes@[::1]:161 I support this proposal. In fact, as discussed at the meeting, I think it is essential because we must be able to specify the username to be presented to the remote ssh server, and in the case of a notification originator this is practically guaranteed not to be related to the securityName in any meaningful way. > * Section 7 in the MIB Module > > - The SnmpSSHAddress should be modified to allow for the new leading > prefix. Suggest a rewrite of the beginning text to the following > (adding bits and pieces to make it work): > > "Represents either a hostname with a port number, an IP > address with a port number, a username, hostname and port > number or a username, IP address and port number. Ugh ugh ugh. How about... "Represents either a hostname or IP address, along with a port number and an optional username". Or even "Represents either a hostname or IP address, along with an optional port number and/or username". The latter, of course, implies a change to make the ":port" part be optional. I don't recall whether we've already discussed this, but I'm not sure I see a need to require specification of a port. > * I THINK the sshtmLCDTable object can be removed after completion > of this since the mapping is no longer needed. Perhaps. I suspect you'll end up wanting some way to provide actual credentials to be used, such as a public/private key pair, but it's possible the mechanism for managing that can be implementation-dependent. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Aug 25 15:19:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE8D3A69E7; Mon, 25 Aug 2008 15:19:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F503A69E7 for ; Mon, 25 Aug 2008 15:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAMK3nrTARzG for ; Mon, 25 Aug 2008 15:19:24 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 350B73A6765 for ; Mon, 25 Aug 2008 15:19:24 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 2AC0098095; Mon, 25 Aug 2008 15:18:45 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 0A73839A273; Mon, 25 Aug 2008 15:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=6Gaf23m10IbDCI1FDW29FNb5/JE=; b=UMPJ n/L58d8An2XThyWqOROOxHXjIkOkDgBxYN6n4ldEe2UNvuvS+Gc4zUINy0LBgKDi +I+H5fhbrunPfXJY4sdpvermIxrMsiNbh8wcf2bEGyjtmp4JEtJgQZtOjWK+tKqX S2jTfZYVeFZRGKOw7wJmiHeByB2GIiZsEPH0JIA= Received: by wes.hardakers.net (Postfix, from userid 274) id CBA6639A293; Mon, 25 Aug 2008 15:18:44 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200808252112.m7PLCqnp022062@toasties.srv.cs.cmu.edu> <5DB0B2070285978B7C1D5C01@atlantis.pc.cs.cmu.edu> Date: Mon, 25 Aug 2008 15:18:44 -0700 In-Reply-To: <5DB0B2070285978B7C1D5C01@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 25 Aug 2008 18:02:23 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] user@address:port proposal for secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 25 Aug 2008 18:02:23 -0400, Jeffrey Hutzelman said: JH> It seems counterproductive for users to have to know that SSH uses JH> port 22. The current transport address definitions for UDP/TCP, for example, require a port spec. I suspect many users don't actually know, however, that it's port 161 for commands and 162 for notifications because most things hide that from the users. JH> Well, I think we'd have to standardize the default port if we did this. Currently we have two different ports for SNMP, as just mentioned. Frequently notifications are sent to a different application than an agent running on the device (for obvious reasons). Thus we need to some combination of: 1) say all address specs must include a port 2) specify default port destinations for both notifications and commands 3) specify default ssh subsystem names for both notifications and commands (right now, there is just "snmp" which is entirely possible not the best solution for trying to connect to a management station that has it's own agent running on it in addition to the notification receiver). >> Well, last time I suggested that a zillion people screamed that's out of >> scope of the WG and that the best that could be done would be a lookup >> key/string for now ;-) JH> Well, that's probably true. I was probably even one of those JH> people. :-) You were. But I wasn't going to bring it up ;-) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Aug 27 15:39:05 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4DC28C281; Wed, 27 Aug 2008 15:39:05 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46543A6933 for ; Wed, 27 Aug 2008 15:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2Ibwunqb65f for ; Wed, 27 Aug 2008 15:39:03 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2F1F03A68FE for ; Wed, 27 Aug 2008 15:39:02 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 1A493980A8 for ; Wed, 27 Aug 2008 15:38:58 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E88E339A2E6 for ; Wed, 27 Aug 2008 15:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=0xYA0UmgesC7WrldCIcm6hZFxWM=; b=J41fQ2DuTX+BbxywYV+GFqbZ/nvv 32qPdDTUEMjjLFVSU3ZluUDx5ep0L+nuRQBTolWyHC8/YRjoNgdEJiOxKBOXEo8z nI8fJz3hoh0vgUNLPU0zGvfyWXKtNpOdDd5GlzwwdJX3NEnabqEqBOVupQsLTBf3 A0TgKkWgBWk+/MU= Received: by wes.hardakers.net (Postfix, from userid 274) id CA2BB39A2E7; Wed, 27 Aug 2008 15:38:57 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Wed, 27 Aug 2008 15:38:57 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] Comments on the TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org First, let me preface this with an important point: the document is very well written. It's been a while since I last read it and the current version is very nicely polished. Thanks for doing such a good job David! It's worth noting again that I reviewed it in the context of the DTLS draft I've been working on and see no issues (aside from the ones I'll mention) with using multiple transports underneath it (like SSH and DTLS both). I do have a few minor things to point out though with edit text, and a maybe few questions which I'll bring up in separate messages. * Section 2.1.1, 3rd paragraph: - The current text says: "The Transport Security Model is called a Security Model to be compatible with the RFC3411 architecture. However, this Security Model does not provide security mechanisms such as authentication and encryption itself, so it SHOULD always be used with a Transport Model that provides appropriate security." - I disagree with this general statement (and this paragraph isn't as negative as the one in the security consideration sections which has an extra sentence). The TSM does not perform any encryption or authentication or integrity protection services, but it is very much a security model and it does provide a few critical security functions. - How about this instead (and this needs to be replace Section 8, paragraph 3 (in the Security Considerations) too): "The Transport Security Model is a Security Model that is compatible with the RFC3411 architecture. However, this Security Model does not provide some of the typical security mechanisms such as integrity protection, authentication and encryption itself since it relies on the lower level transport to perform these tasks. The Transport Security Model does, however, provide critical security related tasks (such as dropping requests that fail to meet securityLevel requirements or requests that came in over transports not authorized by configuration settings). The Transport Security Model SHOULD always be used with a Transport Model that provides appropriate security." * Section 2.3, 3rd paragraph: - drop the **s or change to ()s - (was this an editing note? it's not standard ID mark-up). * Section 2.3, last paragraph: - Add ", configure the Transport Security Model to manipulate securityName mappings, and a scalar to control securityName mapping prefix processing". - (that last bit does assume consensus in the other email thread has been reached). * General MIB: snmpTsmLCDTable: - Was there a result to the discussion about the naming of this table? - LCD is kind of generic - Personally, I'd suggest "snmpTsmConnectionTable" or something. - (I refrained from using "session") * Sections 4 and 5: - These are EOPs and if we want to be consistent with the other documents, I'd suggest having a separate EOP top-level section and putting all the EOP steps within this document into the new top-level EOP section. This is obviously a nit though. * Section 4.2, Step 5: - nit: Step 5 could be improved by describing how the message parts should be combined with a better verb? How about "The wholeMsg is now created by serializing the message parts together." - (this more closely resembles the USM wording... really the only verb I changed was "combine" to "serialize") * Section 5.2: - Step 5: - Delete the "," after "(Priv)," to avoid grouping confusion. - Step 6: - "the security data is cached..." - I'd suggest listing what security data you're talking about. It's probably important to get right and I'm not even sure, without analyzing it in detail, which ones should be cached. * Section 6: - Add "and a scalar to configure securityName mapping prefix processing" if consensus is reached on the new scalar. * Section 6.4 to 6.5: - New section needed for the potential scalar
This subtree contains a scalar that specifies whether the TSM should remove (the default) or leave the transport specific prefix string that is attached to tmSecurityNames.
* Section 6.4 (current before insertion of just discussed new section): - Should the VACM mib be added here? I'd think so. * MIB: - nit: indentation is funky after "snmpTsmMIBObjects" definition - nit: descriptions oddly indented/outdented: snmpTsmLCDDomainTable, snmpTsmLCDDomainEntry, - issue: snmpTsmLCDDomainTable vs snmpTsmLCDTransformEntry * Section 8.1: - First 'o' bullet: - change "valid domains" to "transport models" since I think most people aren't used to the "domain" terminology. - third 'o' bullet: - Add "Access to the" to the beginning - Add "objects" before "may" * Section 9: - I'd like to answer the "DISCUSS" comment by saying: I don't think this is the right document to discuss default ports. The TSM doesn't have a clue what the requirements of the transports are below it and thus this isn't the right document to discuss anything related to the transport itself. It'd be something that would need to be considered on a per-transport basis. * Appendix A: - I'm not sure :162 is a good choice for a transport address to use for an example snmpSSHDomain address. :22 would probably be a better choice (or an IANA assigned different port altogether). Certainly, however, 162 is not a good choice :-) - For the snmpTargetParamsTable row, the snmpTargetParamsSecurityModel should be "YY" (with a note to the editor) not the text string TransportSecurityModel. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Aug 27 16:00:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A97628C29D; Wed, 27 Aug 2008 16:00:57 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B7E28C2A1 for ; Wed, 27 Aug 2008 16:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.458 X-Spam-Level: X-Spam-Status: No, score=0.458 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_50=0.001, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkulFdYCC59A for ; Wed, 27 Aug 2008 16:00:55 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 65E5528C29D for ; Wed, 27 Aug 2008 16:00:55 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 49511980AC for ; Wed, 27 Aug 2008 16:00:58 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 134C139A2E6 for ; Wed, 27 Aug 2008 16:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=R7bKgsIp5ACYOZjepxejYnE7ISY=; b=OOjtAzsehnQ7RaRYhWtwrMkqIxa0 tKJGNRiOmsLUVhCj4d2ZfqGskkNx29r4OIrMG7wCwwq5X259saZVrsyqReuxfrtO V7Ium1tEJ1YdrAVyNOKnbC9ciroRw7iEz1YFnOOgFpnBmQRWwCVZGVMSCJaeqk85 abms5OFYYAOTLv4= Received: by wes.hardakers.net (Postfix, from userid 274) id D789F39A2E7; Wed, 27 Aug 2008 16:00:57 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Wed, 27 Aug 2008 16:00:57 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I know David has expressed multiple times that he thinks we have too many securityName mapping locations and the current documents have them all in place even though he's not convinced they're all needed. Here's my analysis of the current (complex) state. I'm including DTLS in the pipelines below since I think it helps show where two different transports come together and where the mapping-system merges. The "prefix" support (ssh: and dtls:) are what has been discussed recently in another thread. The following diagram depicts the *potential* sets of mapping components that exist in the various modules (it's "potential" because some are still in the air as far as a decision goes): +---------+ +------+ +-----------------+ +----------+ | SSH | | SSH | | sshtm | | add | | user | | TM | | LCDTable | | ssh: | | name | --> | | --> | map | --> | prefix | ------+ +---------+ +------+ +-----------------+ +----------+ | | | | v +---------+ +------+ +-----------------+ +----------+ +---+ | DTLS | | | | dtlstm | | add | | | | X509 | | DTLS | | CertTo | | dtls: | | * | | Subject | | TM | | SNTable | | prefix | | | | Field | --> | | --> | map | --> | | --> | | +---------+ +------+ +-----------------+ +----------+ +---+ +---------+ +------+ +-----------------+ +----------+ | | | | | snmpTsmLCD | | vacm | | | | | | DomainTable | | Security | | * | | TSM | | and | | To | | | | | | snmpTsmLCDTable | | Group | | | | | | | | Table | | | | | | | | (Size | | | --> | | --> | | --> | 1..32) | +---------+ +------+ +-----------------+ +----------+ So the steps, starting from the beginning: 1. The transport authentication system passes in "something" that the TM has to make use of. EG, the SSH user name or the X509 Certificate 2. The TM transforms this input into a local tmSecurityName. For SSH this is done through the sshtmLCDTable and for DTLS this is done throuh the snmpTsmLCDDomainTable. + Some TMs may have binary blobs to identify users by. They will definitely have to provide some sort of to-text-mapping. + Some TMs may have strings that are too long to pass to much of the SNMP infrastructure - SSH may allow longer lengths than 32 for user names? I couldn't find this anyway, but suspect it's true. It's not, however, true in real world practice and deployment at this point though (AFAIK). - X509 provides a good example for this: The Subject: field of a X509 cert is typically much longer than would be acceptable as an identifier by SNMP. 3. The TM prefixes the derived tmSecurityName with a unique identifier (eg ssh: or dtls:) to help identify exactly which protocol it came in over. This is one of the current outstanding proposals that appears to have reached consensus. 4. The TM passes the final derived and prefixed tmSecurityName to the TSM via the tmStateReference. 5. The TSM obtains the tmSecurityName and possibly strips the ssh: or dtls: prefix off (the default is to strip it). 6. The TSM transforms the security name, based on the domain it's received on (eg ssh or dtls) either: a) as a 1:1 mapping if snmpTsmLCDDomainTable points to "default" b) as a private mapping if snmpTsmLCDDomainTable points to "private" c) drop the message because the mapping is set to "disable" 7. The snmpTsmLCDTable possibly maps an individual tmSecurityName to a different securityName. By default this is populated with the results from #6, *but* it is editable so it's assumed that a management station could (I'm unclear on this): + change the value after a session is up? + change the value for future sessions? + I'm also not clear when this table is consulted, since it's usage not discussed in the EOP. If it's merely a recording table of what has taken place or is live, then why is it read-create? If it can be set up by a manager then when during the EOP is it consulted? Order matters since there are 3 multiple mapping systems within the TSM itself (one of which is the prefix string dropping). 8. Finally the VACM itself maps a securityName to a group name in it's processing, which is really where the consumer of the information gets to make a decision. So... did I go wrong anywhere in all of that writeup David? If so, where? What I propose, assuming I didn't blow my analysis somewhere, is to: A) Drop the snmpTsmLCDTable. I think the usage of the ssh: and dtls: prefixes actually removes the need for the more complex mapping (and in fact that was the purpose of the string prefixes: to meet in a middle ground for complex mapping vs no mapping). B) Drop the sshtmLCDTable mapping support. The only real reason this is needed if we do have a string: prefix would be to map long user names to short ones and I don't think it's needed based on current usage at least. We would likely need a counter for "userNameTooLong" or something just to provide failure reason detection. (note: DTLS still needs a mapping table from the longer X509 fields to the shorter securityName fields) I think dropping those tables should make the mapping-haters happier as well as still allowing simple minimal mapping via the string prefixes available. The outgoing case is pretty much a reversal of the above but doesn't really benefit as much from the mapping in the first place (aside from selecting a user name and credentials). The username@ prefix to the transport address for SSH actually solves much of the need for outgoing securityName mapping on the SSH side of things. Hopefully this may help address some of David's concerns about too much mapping being in existence as well as simplify some of the mib implementation requirements. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Aug 27 17:34:41 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752933A6BAF; Wed, 27 Aug 2008 17:34:41 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72CF3A69F7 for ; Wed, 27 Aug 2008 17:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPZO79zNNLhc for ; Wed, 27 Aug 2008 17:34:39 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id DBC713A6932 for ; Wed, 27 Aug 2008 17:34:38 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (198-144-37-134.static.vdsl.nidhog.net [198.144.37.134]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7S0YT09014372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2008 20:34:30 -0400 (EDT) Date: Wed, 27 Aug 2008 20:34:29 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , ISMS WG Message-ID: In-Reply-To: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, August 27, 2008 04:00:57 PM -0700 Wes Hardaker wrote: > A) Drop the snmpTsmLCDTable. I think the usage of the ssh: and dtls: > prefixes actually removes the need for the more complex mapping (and > in fact that was the purpose of the string prefixes: to meet in a > middle ground for complex mapping vs no mapping). +1 > B) Drop the sshtmLCDTable mapping support. The only real reason this > is needed if we do have a string: prefix would be to map long user > names to short ones and I don't think it's needed based on current > usage at least. We would likely need a counter for > "userNameTooLong" or something just to provide failure reason > detection. +1 but don't preclude implementations from providing support for a mapping here, specifically to deal with the long username problem. It may turn out that this is a problem e.g. in deployments where ssh is authenticated by GSS-krb5 using the organization's windows domain, with usernames being the user's actual full name. I'm not sure what the snmpTsmLDCDomainTable transformation you describe in step 6 is for. It seems to provide a more complex mapping which should be eliminated by the boolean strip-the-prefix-or-not behavior we seem to have settled on. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Aug 27 19:23:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B6E3A6AC2; Wed, 27 Aug 2008 19:23:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26BE3A697F for ; Wed, 27 Aug 2008 19:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DQGnCuLfxoQ for ; Wed, 27 Aug 2008 19:23:45 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 08C243A67AD for ; Wed, 27 Aug 2008 19:23:44 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 7Mlz1a00S16LCl059ePlMH; Thu, 28 Aug 2008 02:23:45 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 7ePl1a0054HwxpC3SePlBB; Thu, 28 Aug 2008 02:23:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZLCIeT3k96OsjtaUbBMA:9 a=Dj7w8oU1YjwNaFmTH4ywIhikDVIA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 27 Aug 2008 22:23:45 -0400 Message-ID: <033101c908b5$19137c60$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckItRi0OKaixMmnTvmuxxwIupncbQ== Subject: [Isms] tmsm-13 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I submitted a revised draft (-13) for the tmsm document. There were two sets of editorial change requests, so I did those. They requested some significant reorganization of the document. I deliberately did not do the technical changes yet. I will submit a revision with technical changes soon. I did this so a diff will highlight the technical changes better. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Aug 27 19:30:02 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8963A67AD; Wed, 27 Aug 2008 19:30:02 -0700 (PDT) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0004C3A67AD; Wed, 27 Aug 2008 19:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080828023002.0004C3A67AD@core3.amsl.com> Date: Wed, 27 Aug 2008 19:30:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-tmsm-13.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-13.txt Pages : 41 Date : 2008-08-27 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-27192401.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Thu Aug 28 07:12:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325FC3A6972; Thu, 28 Aug 2008 07:12:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA1F3A680E for ; Thu, 28 Aug 2008 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrY3mLceQ6Gx for ; Thu, 28 Aug 2008 07:12:55 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id C07783A6972 for ; Thu, 28 Aug 2008 07:12:54 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 7npk1a00G0Fqzac51qCxBb; Thu, 28 Aug 2008 14:12:57 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 7qCx1a00H4HwxpC3UqCxMS; Thu, 28 Aug 2008 14:12:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=uNU2Mb6HRoGSKzmzQGYA:9 a=QD58Fivql6KTC-bTaunJPS4CiuMA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Thu, 28 Aug 2008 10:12:57 -0400 Message-ID: <036101c90918$2bc3d810$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJGCstXCLTGadxRLuhvBeLhKDFvg== Subject: [Isms] tmsm-13 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, The changes I made from rev12 to rev13 of the tmsm document were driven by Dave Shield: http://www.ietf.org/mail-archive/web/isms/current/msg03017.html Wes: http://www.ietf.org/mail-archive/web/isms/current/msg02970.html I made almost every change requested, as requested. Thank you both for the thorough reviews and proposed text. I think the document has been greatly improved by your proposals. Dave requested some reorganization, so some of the changes will be hard to compare using diffs. If your favorite paragraph or sentence went missing, look around - it probably just moved. It took about three days of editing to make these changes, verify nothing was left out inadvertently, and that technical decisions were not affected (much). I will be doing the same with the other two documents. sigh. Then I will begin to insert the proposed technical changes. I ask everybody to please review the updated editorial revisions, so we can all be on the same page (iterally!) when discussing the subsequent technical changes. Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 08:00:04 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F643A6CCE; Thu, 28 Aug 2008 08:00:04 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B2D3A6CB6 for ; Thu, 28 Aug 2008 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.076 X-Spam-Level: X-Spam-Status: No, score=-0.076 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIrvuAI5aABQ for ; Thu, 28 Aug 2008 07:59:56 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id CE1DF3A6CA9 for ; Thu, 28 Aug 2008 07:59:56 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 020499817F; Thu, 28 Aug 2008 07:59:59 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C439639A274; Thu, 28 Aug 2008 07:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=aMYS4Fda4LR9NJII40sTLfqFtGY=; b=piQG CYSuY7E7fwPEFRk0S4RBDXY1/jeYc7uGbMJ5UKYMHRfI/pK9XDDS5MoWC80akfd0 Ep0oz5v30IMi6eHEqydOC5rZNaduh2EnrIA2fGsyGsaxYZcLZTf2wniig91VX/VZ /F+C8Z/79rJyxseNeufCgrZaw7uTdECJ/sG1QM8= Received: by wes.hardakers.net (Postfix, from userid 274) id 89AF039A275; Thu, 28 Aug 2008 07:59:58 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> Date: Thu, 28 Aug 2008 07:59:58 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 27 Aug 2008 20:34:29 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 27 Aug 2008 20:34:29 -0400, Jeffrey Hutzelman said: >> B) Drop the sshtmLCDTable mapping support. [...] JH> +1 but don't preclude implementations from providing support for a JH> mapping here, specifically to deal with the long username problem. Agreed. In fact the DTLS draft *has* to have a separate mapping table because of the length of x509 identifiers. JH> It may turn out that this is a problem e.g. in deployments where ssh JH> is authenticated by GSS-krb5 using the organization's windows JH> domain, with usernames being the user's actual full name. Yep. Or realm based suffixes. However, even that is most typically less than 32-strlen("ssh:") though there are definite exceptions at that point. Soapbox: Technically, I actually think we should have one long-to-short mapping table in the TSM since I think it's a likely common issue between the transports. However, many vocal opinions of the past thought we should have minimal mapping support at the TSM layer because not much needed it at the moment (SSH names are rarely longer than 8 in most common real-world deployment today). It actually turns out that for X509 cases I really needed a table within the DTLS draft anyway, though, so in the end it wouldn't have saved my anything by having common infrastructure. (the DTLS draft needed a table to specify whether to use a generic commonname field straight up by a trusted CA vs doing a individual mapping per every individual... So configuration was already needed for mapping at the DTLS TM specific level). JH> I'm not sure what the snmpTsmLDCDomainTable transformation you JH> describe in step 6 is for. It seems to provide a more complex mapping JH> which should be eliminated by the boolean strip-the-prefix-or-not JH> behavior we seem to have settled on. Right... I agree. The only real purpose it serves now is to provide configuration for completely turning off a service (the disable(3) value). Although, the scalar flip to passing the prefix and not providing authorization accomplishes the same thing it does require more overhead since it doesn't actually turn of the service (with all the crypto calculations attached). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 08:09:51 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4C028C327; Thu, 28 Aug 2008 08:09:51 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2556C28C320 for ; Thu, 28 Aug 2008 08:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj8ExQpG8ZGW for ; Thu, 28 Aug 2008 08:09:50 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 3F25D28C31B for ; Thu, 28 Aug 2008 08:09:50 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7SF9nL0005940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 11:09:50 -0400 (EDT) Date: Thu, 28 Aug 2008 11:09:49 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <87F6526E072BD7ECB25A06FA@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: ISMS WG , jhutz@cmu.edu Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, August 28, 2008 07:59:58 AM -0700 Wes Hardaker wrote: > JH> I'm not sure what the snmpTsmLDCDomainTable transformation you > JH> describe in step 6 is for. It seems to provide a more complex mapping > JH> which should be eliminated by the boolean strip-the-prefix-or-not > JH> behavior we seem to have settled on. > > Right... I agree. The only real purpose it serves now is to provide > configuration for completely turning off a service (the disable(3) > value). Although, the scalar flip to passing the prefix and not > providing authorization accomplishes the same thing it does require more > overhead since it doesn't actually turn of the service (with all the > crypto calculations attached). Neither does the table, if it is implemented by TSM as its name suggests. By the time TSM gets control, the transport connection has already been established, and the hard work is already done. The right way to disable a transport is to disable the transport, not to configure TSM to reject messages arriving via that transport. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 08:43:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAEF3A6CD5; Thu, 28 Aug 2008 08:43:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDA83A6CD5 for ; Thu, 28 Aug 2008 08:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqvRV8v7Ouqa for ; Thu, 28 Aug 2008 08:42:55 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6CBEF3A6880 for ; Thu, 28 Aug 2008 08:42:55 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 057899806D; Thu, 28 Aug 2008 08:42:48 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id CF21239A274; Thu, 28 Aug 2008 08:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=ZPPumS01YNILarupxcbf9KLP/WY=; b=V6vv Pv0dFQNJrehkehrC6T7OszTo8ZSaRS2HH4e1V7zNddH/5DXJSBtVuSbtnECjQUvq RzUR+kYtLMwu4G9UWhZRNyJlpBK/Q0O3KVXxG+Fa4sAMVHbbYqsIwkpWsVgZt7yO wVe+yONRwSTh1WBUiv3br0rCenlvq/+H6HdWFeE= Received: by wes.hardakers.net (Postfix, from userid 274) id 86D8439A275; Thu, 28 Aug 2008 08:42:47 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <87F6526E072BD7ECB25A06FA@atlantis.pc.cs.cmu.edu> Date: Thu, 28 Aug 2008 08:42:47 -0700 In-Reply-To: <87F6526E072BD7ECB25A06FA@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 28 Aug 2008 11:09:49 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 28 Aug 2008 11:09:49 -0400, Jeffrey Hutzelman said: JH> Neither does the table, if it is implemented by TSM as its name JH> suggests. By the time TSM gets control, the transport connection has JH> already been established, and the hard work is already done. JH> The right way to disable a transport is to disable the transport, not JH> to configure TSM to reject messages arriving via that transport. I agree. Though I have suspicions that people implementing it wouldn't follow the architecture quite so rigorously and thus it still provides a switch. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 08:48:53 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F52C3A6CDD; Thu, 28 Aug 2008 08:48:53 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD0A3A6CDD for ; Thu, 28 Aug 2008 08:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd81qjdtEUIS for ; Thu, 28 Aug 2008 08:48:49 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id DE1233A6CD8 for ; Thu, 28 Aug 2008 08:48:48 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 7oPu1a0030ldTLk54roFfg; Thu, 28 Aug 2008 15:48:15 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 7roE1a0024HwxpC3QroEzE; Thu, 28 Aug 2008 15:48:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=Osr4NzcHXboA:10 a=mJW28DwrdC8A:10 a=PA5Vqg1vofRLsZspaSgA:9 a=Are3_6Y1l_calNESzKYA:7 a=OxTcStvdCNWfcdoPxM2-TSzKZ60A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" , "'Jeffrey Hutzelman'" References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> Date: Thu, 28 Aug 2008 11:48:13 -0400 Message-ID: <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJHsQScf9NADj0Tx+PJ/T4r5bUzgAAxCXQ Cc: 'ISMS WG' Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > Soapbox: Technically, I actually think we should have one > long-to-short > mapping table in the TSM since I think it's a likely common issue > between the transports. However, many vocal opinions of the past > thought we should have minimal mapping support at the TSM > layer because > not much needed it at the moment (SSH names are rarely longer > than 8 in > most common real-world deployment today). Complexity is the enemy of security. We need to provide a simple-to-configure secure solution. I have no objection to having mappings tables in TSM. I object to having mandatory-to-implement tables that not everybody needs. I object to having the optional tables described as part of TSM, when they could simply be independent MIB modules that people do or do not choose to implement. I think VACM fails the simple-to-configure rule. VACM is way more complex than most operators need. The learning curve is huge because it has options up the whazzoo (did I get that spelling right?). I liken this to taking a space shuttle to the store to buy milk; you can do it, but who would want to pay for it and learn how to use it when they could just walk, bike, or drive? I do not want to see ISMS produce specs with lots of options for some small segemnts of the industry. RFC3411 was designed to allow the IETF to develop standardized models for the 80% solution, and then the small segments that want extra features can design their own models. History has shown that the segments who "require" these extra features in SNMPv3 do not find it required enough to develop alternate models. This approach is a good way to focus on the essentials and eliminate the nice-to-haves. I have concerns that we are going to change the SSHDomain to add sending to somebody other than the current user name, because a small segemnt of the industry might use it. Write another model that supports this! Do not make it a requirement of SSHTM to support a small segment of the community. I am concerned about adding mapping tables to TSM because a small segement of the population might use a technology that has longer than 32-character names. Write another model that supports longer names! Don't make it something that everybody has to deal with. Even if it has nice defaults (and I'm sure the space shuttle has lots of nice defaults too), it increases the complexity and the learning curve and the operational costs. KISS - Keep ISMS's SNMP simple! David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 09:30:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894F73A6B2A; Thu, 28 Aug 2008 09:30:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396EE3A694E for ; Thu, 28 Aug 2008 09:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ3kbPa3yBrn for ; Thu, 28 Aug 2008 09:30:08 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2ECC83A6B2A for ; Thu, 28 Aug 2008 09:30:08 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 85F3A9809A; Thu, 28 Aug 2008 09:30:11 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 560A239A274; Thu, 28 Aug 2008 09:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=CEfUhYbzLvPVAjm79zVZZ6I9Ki8=; b=LmtE PG9TAcRUtbjrnaa3ECES7UVES6H2EGCk6YDgYk2/WrlbAsJWg4vTVN9lzl2NcbvD OqSg4OYDoYhgQagGEzhFLpLNuVUiCJDMyUGlN3asBrKnanTpc9onU4s7YMPDv2cj 8vC4CTTSa2mXJjq+rMkoK1Hff6TY0E9s4vBnLco= Received: by wes.hardakers.net (Postfix, from userid 274) id EC5B639A275; Thu, 28 Aug 2008 09:30:10 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> Date: Thu, 28 Aug 2008 09:30:10 -0700 In-Reply-To: <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> (David Harrington's message of "Thu, 28 Aug 2008 11:48:13 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'Jeffrey Hutzelman' , 'ISMS WG' Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 28 Aug 2008 11:48:13 -0400, "David Harrington" said: DH> I object to having mandatory-to-implement tables that not everybody DH> needs. Sorry to bring your blood-pressure up. I added the paragraph for Jeff's benefit to document that it's been discussed and the WG has pretty much opted not to go there. Drat. I responded. I said I'd make this short and then blew it. Feel free not to read it David, because I'm not even arguing that we change past decisions. I'm merely explaining my rational behind my statements. DH> I think VACM fails the simple-to-configure rule. VACM is way more DH> complex than most operators need. The learning curve is huge because DH> it has options up the whazzoo (did I get that spelling right?). There is a rather deployed base out there that offers an interface that completely hides the complexity of the VACM for those that don't need complex configurations. All the users of the simplistic wrapper never complain it's hard to use. Many do, however, start needing more flexibility in their authorization rights and some of them certainly do start asking questions about the best way to do the in-depth not-easy-wrapped VACM configuration. This actually proves to me, however, that the need for those complex configurations is well above even 10%. In fact, I originally thought the VACM was over the top in many areas and was more complex than it needed to be. Because of my direct interactions with users that fall into both extremes of the usage model, I actually have retracted my original feelings and think it's a good middle ground solution. Thus, the VACM example doesn't work for me. DH> I am concerned about adding mapping tables to TSM because a small DH> segement of the population might use a technology that has longer than DH> 32-character names. I think that there is a huge discrepancy here between what we consider the user base to be. I actually think there is a fairly large segment of the population that will be using longer-than-32-character names over potentially multiple transports. I agree that if we have only this: SSH -> TSM -> VACM It doesn't matter where we stick the limiting agent that reduces longer names to < 32 octets. In fact, because the 95% SSH use case out there is of usernames < 8 octets it probably doesn't need to exist. But, eventually we may end up with: DTLS/K509----\ V SSH/KRB -> TSM -> VACM ^ TLS/K509-----/ / ???--------/ In which case sticking a mapping table in each of the transports no longer scales as well and requires a lot more configuration tables, not less. "KISS now" just lost when we get to that point. I don't think it's farther way. The world is moving far away from 8-character identifiers as logins become more attached to X509 cert fields or email addresses or Full names or ... -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 12:06:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A82A3A68B5; Thu, 28 Aug 2008 12:06:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559B33A68B5 for ; Thu, 28 Aug 2008 12:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M65SX4uA66rK for ; Thu, 28 Aug 2008 12:06:37 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 6A4043A67E1 for ; Thu, 28 Aug 2008 12:06:37 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7SJ6L9Z019132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 15:06:21 -0400 (EDT) Date: Thu, 28 Aug 2008 15:06:21 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" Message-ID: In-Reply-To: <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, August 28, 2008 11:48:13 AM -0400 David Harrington wrote: > I have concerns that we are going to change the SSHDomain to add > sending to somebody other than the current user name, because a small > segemnt of the industry might use it. Write another model that > supports this! Do not make it a requirement of SSHTM to support a > small segment of the community. On this point, I think you are confused. We are changing the SSHDomain to allow specifying the username to use when connecting to the remote ssh server. This is not "sending to somebody other than the current user name"; it is identifying ourselves (the notification originator) as somebody other than the current securityName, which names the notification recipient. Since it is uncommon to send a notification to oneself, this is the rule, not the exception. I'm also very concerned about what seems to be a desire to standardize as little as we can get away with and still support the single most common use case, marginalizing everyone else. History has shown that those of us who want or need strong authentication for anything from remote login to filesystems to databases to network management _JUST LOSE_ because none of us are big enough to force the vendors to implement something nonstandard. This situation is not acceptable to me, and I am not interested in being part of the problem. I agree that too much complexity in configuration creates problems, but I do not agree with the philosophy that "configuration is bad, less configuration is easier to use, so everyone should do it my way, and if you don't want to do it my way, you're SOL". If that's how we think, then why not just tell everyone to run Windows and IOS and give up on standardization entirely? -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 12:13:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4B23A681D; Thu, 28 Aug 2008 12:13:19 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B16B3A6807 for ; Thu, 28 Aug 2008 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehZKDXQ-qstu for ; Thu, 28 Aug 2008 12:13:17 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id B8E3A3A698D for ; Thu, 28 Aug 2008 12:13:17 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7SJDGk0019594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 15:13:16 -0400 (EDT) Date: Thu, 28 Aug 2008 15:13:16 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Message-ID: In-Reply-To: References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, August 28, 2008 09:30:10 AM -0700 Wes Hardaker wrote: > The world is moving far away from 8-character > identifiers as logins become more attached to X509 cert fields or email > addresses or Full names or ... No. The world was done with 8-character user names 10 years ago. Many modern UNIXes have no such limit. Windows has no such limit. No modern authentication protocol has such a limit. And most importantly, random operators know of no such limit, and so they create accounts with whatever names seem useful. Just because you and I live in environments with the 8-character username assumption embedded in decades-old code and policy doesn't mean that that assumption has any place _at all_ in defining standards for the Internet. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 14:12:22 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86ADB3A694E; Thu, 28 Aug 2008 14:12:22 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E153A6901 for ; Thu, 28 Aug 2008 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm8IqH7aNXOh for ; Thu, 28 Aug 2008 14:12:20 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 9B9213A694E for ; Thu, 28 Aug 2008 14:12:20 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id 7sHl1a0010x6nqcA8xCLzc; Thu, 28 Aug 2008 21:12:20 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 7xCJ1a0094HwxpC8YxCJCc; Thu, 28 Aug 2008 21:12:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=Osr4NzcHXboA:10 a=mJW28DwrdC8A:10 a=J1Ct1lxd2B45WHE_WNUA:9 a=bR2Q0ZAEiRqhehqgUhsA:7 a=8SBDg_jhMf6lppFlZkyhNf6MPPUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=86L1PGDMzkIA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Wes Hardaker'" References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> Date: Thu, 28 Aug 2008 17:12:25 -0400 Message-ID: <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJQiFspt1aYYSJT5qx2h0aWm50WgACxpLQ Cc: 'ISMS WG' Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, We don't have an 8-character limit either. I don't know why we are even talking about 8-character limits. VACM limits us to 32 characters: vacmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) We are not chartered to change VACM. The rest of the system does not appear to limit us: RFC3413 doesn't limit us: snmpTargetParamsSecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The securityName which identifies the Principal on whose behalf SNMP messages will be generated using this entry." ::= { snmpTargetParamsEntry 4 } RFC3411 doesn't limit us: SnmpAdminString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255t" ... SYNTAX OCTET STRING (SIZE (0..255)) and SSH user-auth (RFC4252) doesn't limit us: string user name in ISO-10646 UTF-8 encoding [RFC3629] USM has its own 32-character limit: msgUserName OCTET STRING (SIZE(0..32)), and usmUserName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) But those should not impact TSM or SSHTM. We have a 32-character limit in the current revisions of TSM and SSHTM LCDs; I am not sure we need this restriction, and I can remove it if that is WG consensus: snmpTsmLCDSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) and here ... sshtmLCDTmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) and here ... sshtmLCDPrincipal OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) Is 255 (minus the SSH: prefix) large enough to satisy? Assuming 255 is large enough, how do we define a table to map from an unpredictable 255 character identifier for an authenticated entity down to a 32 character snmpAdminString identifier for VACM that does not introduce security risks? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Thursday, August 28, 2008 3:13 PM > To: Wes Hardaker; David Harrington > Cc: 'ISMS WG'; jhutz@cmu.edu > Subject: Re: [Isms] mapping here, mapping there, mapping everywhere > > --On Thursday, August 28, 2008 09:30:10 AM -0700 Wes Hardaker > wrote: > > > The world is moving far away from 8-character > > identifiers as logins become more attached to X509 cert > fields or email > > addresses or Full names or ... > > No. The world was done with 8-character user names 10 years ago. > Many modern UNIXes have no such limit. > Windows has no such limit. > No modern authentication protocol has such a limit. > > And most importantly, random operators know of no such limit, > and so they > create accounts with whatever names seem useful. Just > because you and I > live in environments with the 8-character username assumption > embedded in > decades-old code and policy doesn't mean that that assumption > has any place > _at all_ in defining standards for the Internet. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 15:23:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D4B3A6AB0; Thu, 28 Aug 2008 15:23:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0BF3A6A24 for ; Thu, 28 Aug 2008 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCwPzxb97MTW for ; Thu, 28 Aug 2008 15:23:28 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 714DD3A694A for ; Thu, 28 Aug 2008 15:23:26 -0700 (PDT) Received: (qmail 4273 invoked from network); 28 Aug 2008 17:23:22 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Aug 2008 17:23:22 -0400 From: "David B. Nelson" To: "'ISMS WG'" References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu><036401c90925$7b5a5f90$0600a8c0@china.huawei.com> <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> Date: Thu, 28 Aug 2008 17:23:29 -0400 Organization: Elbrys Networks, Inc. Message-ID: <8D7D03D497D54AB793F3FA46807C35B0@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckJQiFspt1aYYSJT5qx2h0aWm50WgACxpLQAAGl5nA= In-Reply-To: <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > ...how do we define a table to map from an > unpredictable 255 character identifier for an authenticated > entity down to a 32 character snmpAdminString identifier for > VACM that does not introduce security risks? Um, allow the table entries to contain arbitrarily complex regular expressions? ;-) I guess what you're asking is how can the operator know that there will not be unexpected mapping "collisions" within the constraints of his/her particular deployment? That seems a less general (i.e. more tractable) problem to solve. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Aug 28 16:05:42 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C71A3A6B8D; Thu, 28 Aug 2008 16:05:42 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299FA3A6B8D for ; Thu, 28 Aug 2008 16:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6jnRedxy2ql for ; Thu, 28 Aug 2008 16:05:40 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id ED9A43A694A for ; Thu, 28 Aug 2008 16:05:39 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7SN5aW5027707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 19:05:36 -0400 (EDT) Date: Thu, 28 Aug 2008 19:05:36 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" Message-ID: In-Reply-To: <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, August 28, 2008 05:12:25 PM -0400 David Harrington wrote: > We don't have an 8-character limit either. I don't know why we are > even talking about 8-character limits. Me either; it's Wes who keeps bringing them up. > VACM limits us to 32 characters: > vacmSecurityName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(1..32)) So, VACM has this limit, but the architecture doesn't impose a limit on the length of the securityName produced by the MPM? If USM has the same limit, then I'll bet no one has ever noticed there is a problem. I suspect the best thing to do is to assume that the architecture has a 32-character limit for security names, keep that same limit in TSM, and arrange for SSHTM to never emit names longer than that. I think it is probably OK to say that... - by default, the tmSecurityName produced by sshtm consists of the string "ssh:" followed by the SSH username - if the tmSecurityName would exceed 32 characters in length, then sshtm MUST instead generate some error/drop the request/whatever The thing we perhaps leave unstated is that it is permissible to provide an implementation-specific means to configure a non-default mapping, in which sshtm produces a tmSecurityName consisting of the string "ssh:" followed by something other than the SSH username. Note that in the case of DTLS, the tmSecurityName is going to consist of the string "dtls:" followed by some string which is somehow derived from the DTLS client certificate. I don't know how much configuration Wes is providing there, but IMHO it makes sense for the mapping in each case, to the extent that it is necessary, to occur in the TM, because the input to the mapping is a transport-specific form. > Is 255 (minus the SSH: prefix) large enough to satisy? I would think so, but then, people used to think 8-character userid's were enough. My preference would be to avoid hard limits entirely, and instead support a soft limit ("implementations may limit the length of usernames, but names of up to NNN characters _must_ be supported"). However... > Assuming 255 is large enough, how do we define a table to map from an > unpredictable 255 character identifier for an authenticated entity > down to a 32 character snmpAdminString identifier for VACM that does > not introduce security risks? I'd rather not think about that, which is why I am suggesting we retain the 32-character limit. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Aug 29 06:44:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DF13A69CC; Fri, 29 Aug 2008 06:44:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14843A68C4 for ; Fri, 29 Aug 2008 06:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCp28EFxCdvu for ; Fri, 29 Aug 2008 06:44:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 82E803A6859 for ; Fri, 29 Aug 2008 06:44:23 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C783C0012 for ; Fri, 29 Aug 2008 15:44:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PZn9Fj6oD4V0; Fri, 29 Aug 2008 15:44:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA4A4C00B9; Fri, 29 Aug 2008 15:44:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A92206B4B59; Fri, 29 Aug 2008 15:44:15 +0200 (CEST) Date: Fri, 29 Aug 2008 15:44:15 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080829134415.GA1084@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am attaching the draft meeting minutes from Dublin. Please take a look and let me know if something has been recorded incorrectly. I in particular like to draw your attention to the "observations" a) - e) which try to summarize the constraints in which we work out the name mappings. For the gory details, simply listen to the audio recording (which is pretty decent and has been very helpful for producing these minutes). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-72-minutes.txt" ======================================================= Integrated Security Model for SNMP WG (isms) IETF 72 Dublin Thursday, July 31, 2008, 1510-1610 Taken by Juergen Schoenwaelder, Dave Shield ======================================================= Chair: Juergen Schoenwaelder Agenda: 1) Agenda bashing, WG status ( 5 min) 2) Discussion of transport subsystem draft ( 5 min) 3) Discussion of transport security model draft (20 min) 4) Discussion of SSH transport model draft (20 min) 5) Discussion of RADIUS draft ( 5 min) 6) Review of milestones and action points ( 5 min) Documents: - Transport Subsystem for the Simple Network Management Protocol (SNMP) - Transport Security Model for SNMP - Secure Shell Transport Model for SNMP - Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models - Simple Network Management Protocol (SNMP) Context EngineID Discovery - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management - Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) - Datagram Transport Layer Security Transport Model for SNMP Actors: JS = Juergen Schoenwaelder DH = David Harrington JH = Jeffrey Hutzelman JO = Joseph Salowey WH = Wes Hardacker PE = Pasi Eronen BW = Bert Wijnen DN = David Nelson KN = Kaushik Narayan ... Summary: The ISMS WG has four WG documents: the Transport Subsystem for SNMP , the Transport Security Model for SNMP , the Secure Shell Transport Model for SNMP , and the Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models . The open discussion points mainly concern the Transport Security Model and the Secure Shell Transport Model documents and in particular the mappings of the identity used by secure transports (e.g. SSH user names) to the SNMPv3 securityName. There has been good progress during the meeting and on the mailing list to resolve these issues and the goal is now to get revised documents into WG last call in September and to the IESG in November. Discussions: 1. Agenda and WG Status JS reviews the status of the WG documents. Most documents are in a good shape. The open issues concern the Transport Security Model (TSM) and SSH Transport Model (SSH-TM) documents. Two documents related to ISMS WG documents in the OPSAWG and the RADEXT WG have already gone to the IESG. 2. Discussion of Core ISMS Drafts DH started by reviewing the changes that were made to the documents following the last call that took place around IETF-69. See his slides for a summary of the changes. Issue: Predictability of securityName The securityName of an incoming message must be predictable for the VACM/Target/Event MIB modules to work properly. - Incoming Messages: SSH supports several user authentication protocols and it was discussed to what extend we can assume that the SSH user name is filled in and provide the authenticated identity. PE and JH explained that GSSAPI provides an empty SSH user name since the server is expected to infer the user name from the credentials. After discussion, it was concluded that we can make the assumption to get a suitable user name from SSH. Further discussion centered around the mapping of the authenticated user name to a tmSecurityName. JO asked whether the differentiation should be done based on the protocols or by the credentials provided? DH explains that we deliberately decided to not pass up in the SNMP stack details how authentication has been performed or which credentials were used. PE suggests that there might be TM specific mappings and WH confirms that for DTLS, there should be a DTLS specific way to map a certificate into a user name. Finally, the tmSecurityName must be mapped to the SMNP securityName, either by a simple identity transform or a more complex mapping through a mapping table. DN asked whether it is sufficient to point out the issue? WH and JH explained that this approach might not work because network operators likely have no control over the names used in existing authentication and PKI infrastructures. So the problem needs to be dealt with. - Outgoing Messages: For outgoing messages, the SNMP securityName must be mapped to a tmSecurityName for a selected transport model and then the transport model must map it to security model specific identities and associated credentials. KN asks (similar to DN) whether we make up a problem here, adding complexity for some corner cases. JH responds by mentioning that he has a friend named Root who has lots of fun when he asks for a user name. Ignoring the problem is likely going to backfire. PE explains that in the case of outgoing notifications, the SSH transport mapping needs an internal mapping mechanism since the security name used by SNMP for access control might not necessarily be the user name used to establish the SSH session for transporting the notification. JH explains the SSH user name for notifications is actually the notification receiver's name for us, which likely is different from the SNMP securityName. One possible solution is to have names in the SSH transport address. During the discussions, the following observations were made: a) Some transport mappings (TMs) _must_ provide TM specific mapping capabilities. For example, TLS/DTLS transports must deal with certificates and identities that do not fit into the securityName constraints. b) If we were to require mapping capabilites in all TMs, we might in theory not _need_ a mapping capability at the security model (SM) layer. c) However, even if all TMs do support a TM specific mapping capability, it might be more efficient in terms of configuration complexity to map at the SM layer instead of mapping at all TMs involved. d) We can assume that SSH provides to us a suitable user name that does not need a specific mapping. For SSH authentication mechanisms such as GSSAPI, we can assume that SSH internally maps into a user name that can be used outside of SSH. e) Ignoring naming conflicts (identical names used by different secure transports with different meanings) is not an option since operators can not be expected to have control over authentication infrastructures. The recent prefix mapping proposal posted by WH seems to be a reasonable compromise for a workable solution. The details need to be worked out on the mailing list since the ISMS meeting slot does not provide enough time for this. 3. Discussion of the RADIUS Draft JS presents some slides provided by DN, who could not attend the IETF in Dublin. The remaining open issues are editorial in nature and the next version of the document addressing these issues should be ready for WG last call. 4. Wrap Up It was agreed to have revised core ISMS documents in September resolving the open issues and going to WG last call. Any issues coming up during WG last call should be resolved in October so that the revised documents can go to the IESG in November. --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --J2SCkAp4GZ/dPZZf-- From isms-bounces@ietf.org Fri Aug 29 07:25:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4E03A69A7; Fri, 29 Aug 2008 07:25:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60293A6A28 for ; Fri, 29 Aug 2008 07:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSGxOgKHFec2 for ; Fri, 29 Aug 2008 07:25:25 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 0398C3A6909 for ; Fri, 29 Aug 2008 07:25:25 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 8Cq51a0050QkzPwA4ERHiR; Fri, 29 Aug 2008 14:25:17 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id 8ERF1a00G4HwxpC8NERGmT; Fri, 29 Aug 2008 14:25:17 +0000 X-Authority-Analysis: v=1.0 c=1 a=FsoT-qjle90A:10 a=lHTQJM2IAAAA:8 a=j3Z76cjpAAAA:8 a=-Nvge8fWiw0GjXI8ocsA:9 a=tEv-g56j_eyWe021Ooig_htjtHEA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 From: "David Harrington" To: , References: <20080829134415.GA1084@elstar.local> Date: Fri, 29 Aug 2008 10:25:15 -0400 Message-ID: <044901c909e3$0f2292c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080829134415.GA1084@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJ3WE0/3nkI/rmS1aQkgsmS04IrgABYhwQ Subject: Re: [Isms] dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I think the minutes look very good. They will also be helpful to me in guiding my edits of the drafts. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, August 29, 2008 9:44 AM > To: isms@ietf.org > Subject: [Isms] dublin isms meeting minutes > > Hi, > > I am attaching the draft meeting minutes from Dublin. Please take a > look and let me know if something has been recorded incorrectly. > > I in particular like to draw your attention to the "observations" a) - > e) which try to summarize the constraints in which we work out the > name mappings. For the gory details, simply listen to the audio > recording (which is pretty decent and has been very helpful for > producing these minutes). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Aug 29 08:52:04 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7987B3A6994; Fri, 29 Aug 2008 08:52:04 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7059D3A677C for ; Fri, 29 Aug 2008 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ATN8BX5siwC for ; Fri, 29 Aug 2008 08:52:01 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 8AE1C3A6A59 for ; Fri, 29 Aug 2008 08:52:01 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id A449698062; Fri, 29 Aug 2008 08:52:04 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 4A77E39A274; Fri, 29 Aug 2008 08:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=PGHMDppr7OzHS4ZAwrjmt7mtwdc=; b=hUZf Z5BGXOsuIkNnl35G0kzR4VjEwCbfdtaIVXhtWNn85RqyqhP8vuRUIQm1xLIP5zux L99bSiuZa1gXhGzTUrfDftgljuCcRZJ1YDKPrSXwJ3xCywr3ekqRoWNvajeW2NE2 il+vSs9Xuu6KmscWQWwvdCwZdfHmNwFPtLb6IMw= Received: by wes.hardakers.net (Postfix, from userid 274) id 039F539A275; Fri, 29 Aug 2008 08:52:04 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> Date: Fri, 29 Aug 2008 08:52:03 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Thu, 28 Aug 2008 19:05:36 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 28 Aug 2008 19:05:36 -0400, Jeffrey Hutzelman said: >> We don't have an 8-character limit either. I don't know why we are >> even talking about 8-character limits. JH> Me either; it's Wes who keeps bringing them up. It was an example of bad thinking from the past. Sorry you misinterpreted it as anything other than an example. >> VACM limits us to 32 characters: >> vacmSecurityName OBJECT-TYPE >> SYNTAX SnmpAdminString (SIZE(1..32)) JH> So, VACM has this limit, but the architecture doesn't impose a limit JH> on the length of the securityName produced by the MPM? The weakest link in the chain is the VACM, I think we agree on that. The only important point is that because of the weakest link if we do anything that produces names longer than 32 octets we've broken the chain. Regardless of what would be ideal, if we're not going to change the VACM then we simply must accommodate it's needs or our results won't be usable. I think we're *all* in agreement on that so we can restrict ourselves to just the solution space instead. >> Is 255 (minus the SSH: prefix) large enough to satisy? (So no, this won't work when you add in the full chain). JH> I think it is probably OK to say that... JH> - by default, the tmSecurityName produced by sshtm consists of the string JH> "ssh:" followed by the SSH username JH> - if the tmSecurityName would exceed 32 characters in length, then sshtm JH> MUST instead generate some error/drop the request/whatever I'm not convinced that's the most scalable long term solution (still), *but* I can live with it at least so I'm all in favor of adopting it in the interest of forward progress. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Aug 29 09:24:27 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953E928C0F5; Fri, 29 Aug 2008 09:24:27 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBEB28C0E3 for ; Fri, 29 Aug 2008 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAnaB+jN9aLl for ; Fri, 29 Aug 2008 09:24:25 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 11E6E28C0CF for ; Fri, 29 Aug 2008 09:24:25 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 0D9099808F for ; Fri, 29 Aug 2008 09:24:29 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id CD4A839A274 for ; Fri, 29 Aug 2008 09:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=X1YSPFdki8WO9N2LT6xYnp8qpVY=; b=m3jodCUWmfqQyi19pbp9nkWpMto5 ccmWbxCTCe3IqLav0ZypDNB5ap+BgkEI6iEq3k5Q9qMk/kvetVQFxvrNqqZfBjKz WdnAzJ+X/O98ECyXwo7Rkpg7FiC8hIDjecjROOUU91eu70EBnfa7XsYCWVwslTj6 QOJ7qRSthQxWiPc= Received: by wes.hardakers.net (Postfix, from userid 274) id AB20439A275; Fri, 29 Aug 2008 09:24:28 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Fri, 29 Aug 2008 09:24:28 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] Notes on an SSH Document Review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Here are some notes about the SSH document as I've reviewed it. It's divided into pieces, with the technical issues first to separate them from the simple wording edits that I thought were needed. + General Comments - This is also another extremely well written document and my hats off to the editors for doing such a good job in documenting everything that is needed. + Technical Issues - Section 3.1.2, paragraph startingc "The SSH Transport Model" * I'm not sure of the reasoning behind such strong wording to say that transport level protections offered to the packets "SHOULD NOT be exposed to the SSH Transport Model". I'm not sure how this helps interoperability and I think some implementations may benefit from exposing that detail so they could provide a configuration system at the TM level. I think MAY NOT would be more appropriate. - Section 3.1.3, DISCUSS in 2nd paragraph * The question is: is this paragraph needed. I don't think it is. I think it's beyond scope to discuss the details of how SSH needs to do it's authentication. The first paragraph nicely states that we're relying on SSH authentication and the next 2 are really just examples of stuff that may or may not be used. That being said, I don't mind if it stays either. But to answer the DISCUSS: no I don't think it's needed. - Section 3.1.4: DISCUSS * I don't think we need to go into gory detail here either. But *if* the gory detail is left in 3.1.3, then it's probably appropriate to add similar stuff here. Maybe one sentence of: + "The SSHTM expects that SSH is appropriately configured with currently acceptable encryption algorithms to support privacy levels needed to protect SNMPv3/SSHTM traffic." - Section 3.1.6: Subsystem naming * I have two concern over subsystem naming 1. I think there could very well be real world user-configuration out there today that has "snmp" as a configured subsystem. I'd suggest we pick a less likely to conflict name here. Either "snmpv3" or "isms" comes to mind as less likely to be used in the real world. 2. Re: DISCUSS: I do think we need two different subsystem names though. For management stations that are running an agent, it's highly likely that they are also running a notification receiver and the ssh subsystem destination shouldn't be the same. If we end up assigning SNMP-over-SSH specific ports for these services, then the susbsystem name really doesn't matter. If, however, we end up reusing 22 we certainly need one ssh subsystem name for an agent ("commandresponder") and another for notifications ("notificationreceiver"). I doubt either of those two are in use today! * Note: IANA considerations needs to change too * Note: Step 7 of 5.3 would need to be changed too. If nothing else, spelling out the exact subsystem name to use there would be good even if it doesn't change. - Uniquely Identifying Sessions * I don't think that the quadruple of addrType, Addr, securityName and securityLevel serve as a good unique identifier combination. At least section 3.1.6 specifies this as "unique". It's certainly the case that the architecture may require this because the architecture doesn't have session pointers to pass around. But I think that most real-world implementations may support more than one connection with identical values for these 4 variables. I've certainly seen some that (if modified to support SSH) will end up with non-unique combinations. This isn't a problem for the implementation as they're already passing around other references. So there are two things here that fall out of this: + Should the text be modified to add "implementations MAY have an alternative implementation-dependent method of identifying SSHTM sessions" * Section 5.4: the closeSession() ASI won't actually work for similar stacks and only offers two identifiers for uniqueness when pointing at a session to close. * Section 7, sshtmLCDTable + If the table is kept (see list discussion) then I don't think the indexes are sufficiently unique for real-world implementations (see above). - Section 4.2: tmSecurityName * I'm not sure how pulling the SSH identity from the SSH layer is implementation dependent. If two different implementations are expecting it to be pulled from two different portions of the packet then they won't interoperate at all! Now, in reality I think they'll likely pick the same field. But "by default, tmSecurityName is determined from the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message" isn't wise interoperable wording. I'd say it *is* determined from that or else implementations that pick otherwise won't interoperate. + Wording Edits - Section 3.1.1, steps 1 and 2 * The wording for bullets 1 and 2 and close together and somewhat confusing. I'd suggest: 1. Message Stream Modification - SSH provides for verification that messages sent have not been dropped or reordered during its transmission through the network. 2. Information Modification - SSH provides for verification that the contents of each received message has not been modified. Data within a message can not be altered without it being detected by SSH. * I'm not sure it's worth including "to an extent greater than can occur non-maliciously" since the application (the SNMPv3 stack in this case) won't see any modifications and in the worst case SSH would cause the session to terminate... It won't know if it's malicious or not. - Section 3.1.1, steps 3 and 4 * Steps 3 and 4 are also closely related and I'd either combine them or separate them into "client" and "server". (note that 3411's definiton actually lists masquerading as protecting the server from clients, but I'd argue both are very important). How about: 3. Server Masquerading - SSH provides verification of the identity of the SSH server through the SSH Transport Protocol server authentication [RFC4253]. 4. Client Masquerading - SSH provides for verification of the identity of the SSH server. Verification of principal identity is important for use with the SNMP access control subsystem, to ensure that only authorized principals have access to potentially sensitive data. The SSH user identity is provided to the transport model, so it can be used to map to an SNMP model-independent securityName for use with SNMP access control and notification configuration. (The identity may undergo various transforms before it maps to the securityName.) - Section 3.1.2, paragraph starting "The SSH Transport Model" * Add a period after "were met" about in the middle of the paragraph. - Section 3.1.3 first paragraph; minor wording suggestion: * OLD: This includes the three authentication methods described in the SSH Authentication Protocol document [RFC4252] - publickey, password, and host-based - and keyboard interactive and others. * NEW: This includes the three authentication methods described in the SSH Authentication Protocol document [RFC4252] (publickey, password, and host-based) and keyboard interactive *as well as* others. - Section 3.3, first sentence: * What's the reason for limiting what types of applications can open a connection? If SNMPv3 is extended in the future, they'll likely be able to open connections too... That being said, if you want to leave it you need to at least add "proxy forwards" to the list of SNMPv3 application types that may open an SSH connections. - Section 4.2, 4th paragraph * tran*b*sform transform - Section 4.2 5th paragraph * I think using Layer 8 is funny, but I don't think it's probably the right wording for the document. How about "intelligent being". * I'm not even sure what the benefit to this paragraph is within the document. There is almost nothing in it that is SSH specific and it reads more like generic wording for the TM document. - Section 4.3, first paragraph * OLD: "at least architecturally, ..." * NEW: "at least in the defined SNMPv3 architecture, ..." - Section 5.2 maybe renumber bullets to help the "if" statements. * I'd be tempted to renumber the bullet numbers to help the if/then statements appear in a better decision tree using 2a instead of 3, eg. It actually looks like a bit of work with rewording as well. If you think it's fine as is, then leave it. If you think I might be right, then I'll write something up (let me know). - Section 5.3, second paragraph after openSession ASI * "This will" => "This may" * add to the end of the sentence: "assuming sufficient configuration exists to set up a connection". - Section 5.4, first paragraph after closeSession ASI: * extra space after "a client and server" before the "." - Section 5.4, steps * steps are 1, 3 and 4. Renumber because 2 is MIA * Step 4: why is sshtmLCDPrincipal extracted? I'd suggest removing it from the extraction list as it's unneeded. - Section 6.3, other MIBs * Add the TARGET-MIB? - Section 7, MIB, Co-editors * Extra spacing not needed between Josephy's company and address. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Aug 29 11:09:04 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0693A6A7B; Fri, 29 Aug 2008 11:09:04 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604BC3A6A53 for ; Fri, 29 Aug 2008 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb9sLIUWThqo for ; Fri, 29 Aug 2008 11:09:01 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 2D3443A6A7B for ; Fri, 29 Aug 2008 11:09:01 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7TI8ujC001308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 14:09:00 -0400 (EDT) Date: Fri, 29 Aug 2008 13:35:08 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , ISMS WG Message-ID: <4AA78285207D926E04B40286@atlantis.pc.cs.cmu.edu> In-Reply-To: <200808291624.m7TGOZ5d028512@toasties.srv.cs.cmu.edu> References: <200808291624.m7TGOZ5d028512@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] Notes on an SSH Document Review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, August 29, 2008 09:24:28 AM -0700 Wes Hardaker wrote: \> - Section 3.1.2, paragraph startingc "The SSH Transport Model" > * I'm not sure of the reasoning behind such strong > wording to say that transport level protections > offered to the packets "SHOULD NOT be exposed to the > SSH Transport Model". I'm not sure how this helps > interoperability and I think some implementations may > benefit from exposing that detail so they could > provide a configuration system at the TM level. I > think MAY NOT would be more appropriate. I don't object to your intent, but I think the phrase MAY NOT should be avoided at all costs. It is logically equivalent to MAY, but many people will read it as meaning the same thing as MUST NOT. Let's just rewrite "SHOULD NOT be" as "are not" or even "normally are not". In any case, I think the purpose of this text is not so much to promote interoperability but to prevent people down the line from second-guessing our decision to leave the details of SSH to SSH and not get SNMP involved in them. > - Section 3.1.3, DISCUSS in 2nd paragraph > * The question is: is this paragraph needed. I don't > think it is. I think it's beyond scope to discuss the > details of how SSH needs to do it's authentication. The > first paragraph nicely states that we're relying on SSH > authentication and the next 2 are really just examples > of stuff that may or may not be used. That being said, > I don't mind if it stays either. But to answer the > DISCUSS: no I don't think it's needed. Agree. These paragraphs don't need to be here. > - Section 3.1.4: DISCUSS > * I don't think we need to go into gory detail here > either. I don't think we need this section at all. The SSH TM doesn't support or not support any particular SSH encryption or integrity methods. SSH supports what it supports, and SSHTM supports SSH. This is equivalent to an application that runs over TCP saying it supports PMTU discovery, slow start, fast recovery, and so on. Those things are transparent to anything that runs above the layer boundary. I'm almost inclined to say the same thing about section 3.1.3, but not quite. The difference is that authentication methods _are_ visible above the layer boundary, because you have to provide credentials. And so, the set of authentication methods that can be used with SSHTM is limited by the kinds of credentials it can provide. > - Section 3.1.6: Subsystem naming > 2. Re: DISCUSS: I do think we need two different > subsystem names though. For management stations that > are running an agent, it's highly likely that they > are also running a notification receiver and the ssh > subsystem destination shouldn't be the same. If we > end up assigning SNMP-over-SSH specific ports for > these services, then the susbsystem name really > doesn't matter. If, however, we end up reusing 22 we > certainly need one ssh subsystem name for an agent > ("commandresponder") and another for notifications > ("notificationreceiver"). I doubt either of those > two are in use today! I'm not convinced we need separate subsystem names, but I also don't see any harm in having them. But, let's remember that the namespace is universal and not specific to the context of SNMP. "snmp-commandresponder" or even "snmp-command" is a fine subsystem name; "commandresponder" is too vague. > - Uniquely Identifying Sessions > * I don't think that the quadruple of addrType, Addr, > securityName and securityLevel serve as a good unique > identifier combination. At least section 3.1.6 > specifies this as "unique". It's certainly the case > that the architecture may require this because the > architecture doesn't have session pointers to pass > around. But I think that most real-world > implementations may support more than one connection > with identical values for these 4 variables. I've > certainly seen some that (if modified to support SSH) > will end up with non-unique combinations. This isn't a > problem for the implementation as they're already > passing around other references. So there are two > things here that fall out of this: > + Should the text be modified to add "implementations > MAY have an alternative implementation-dependent > method of identifying SSHTM sessions" I'm pretty sure we've been over this elsewhere, and that in fact sessions are uniquely identified by being distinct sessions, and not by looking up some combination of parameters in a table. If you get two sessions, they have different handles or file descriptors or whatever, and for the purpose of directing outgoing responses (which AFAIK is the only reason we need to "identify" sessions), you need to remember which one you use. We even provided a means for this, in the form of tmStateReference. > * Section 5.4: the closeSession() ASI won't actually work > for similar stacks and only offers two identifiers for > uniqueness when pointing at a session to close. Why do we need this at all? Isn't session management the TM's job? > - Section 4.2: tmSecurityName > * I'm not sure how pulling the SSH identity from the SSH > layer is implementation dependent. If two different > implementations are expecting it to be pulled from two > different portions of the packet then they won't > interoperate at all! No, it's not about pulling things from the packet. You don't even get to _think_ about ssh packets. But the means by which an SSH server passes username information to a subsystem is not specified; it is specific to the SSH implementation. > But "by default, > tmSecurityName is determined from the value of the > user name field of the SSH_MSG_USERAUTH_REQUEST > message" isn't wise interoperable wording. To my mind, any reference in this document to SSH_MSG_* indicates a layering violation. The details of the operation of the SSH protocol are below the abstraction level at which SSHTM gets to interface with SSH. Again, this is like talking about the details of TCP packets, payload lengths, etc. > I'd say it > *is* determined from that or else implementations that > pick otherwise won't interoperate. Of course it's determined from that. SSH says so. It's not up to us. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms