From ietfdbh@comcast.net Sun Feb 2 11:20:58 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5841A010A for ; Sun, 2 Feb 2014 11:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCGkOXJl7zT1 for ; Sun, 2 Feb 2014 11:20:55 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 630CA1A0109 for ; Sun, 2 Feb 2014 11:20:55 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA11.westchester.pa.mail.comcast.net with comcast id MX7V1n0011wpRvQ5BXLqu0; Sun, 02 Feb 2014 19:20:50 +0000 Received: from [192.168.1.75] ([162.228.1.76]) by omta18.westchester.pa.mail.comcast.net with comcast id MXLd1n00H1ePg823eXLffX; Sun, 02 Feb 2014 19:20:48 +0000 From: David Harrington Content-Type: multipart/alternative; boundary="Apple-Mail=_9A218B49-E620-452C-B2B1-A43D70603860" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Sun, 2 Feb 2014 14:20:37 -0500 To: sacm@ietf.org X-Mailer: Apple Mail (2.1510) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391368850; bh=3Yx+couhofNhFQWtnTHz3jquMRcm4jdleLszmTNMeBE=; h=Received:Received:From:Content-Type:Message-Id:Mime-Version:Date: Subject:To; b=DpOx9mVvB1kIWWygo6nBbPIfgjzEJeG4MBWHFoDjt6XYULbzFvHsZOidZn/l+4b2G xW4iKxYljI0HRyH6kZCvKxO72nqUOjbZHhw0Vm2Nhg4UzZIttfj4ILIsN9pu2fhW1y uRNqWPEShTARMqgq3KKr3KNK4gY1NqWOS8VVbHwlbiAgQUf3ZXtwCa4r6mb0Jhney6 qXRbj82wmU4YxUt25mPn7MapYnHX8C0q0LHMkO/KP2VgJ/6n+vBr3C7nnjMSzOphi4 1eSm0B2IpjXcG/yV388Vr/a938MjEP9ve7aJ3u/AGI52zqm7Bhv7KBiIChJMgzsmUj jmfeCns0esvAA== Cc: David Waltermire Subject: [sacm] Consensus on QUESTIONS in use-cases-5 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 19:20:58 -0000 --Apple-Mail=_9A218B49-E620-452C-B2B1-A43D70603860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Trying to get consensus on editing instructions for the use cases draft, = so Dave and Dave can edit a final revision. This email is specifically = focused on the QUESTIONS identified in the -05- draft, most of which = were first raised in reviews of earlier revisions. Subsequent emails = will focus on other requested changes, such as clarifying "content". 1) in 2.0 1. Some type of trigger initiates the workflow. For example, an operator or an application might trigger the process with a request, or the endpoint might trigger the process using an event-driven notification. QUESTION: Since this is about security automation, can we drop the User and just use Application? Is there a better term to use here? Once the policy is selected, the rest seems like something we definitely would want to automate, so I dropped the User part. Unless there is strong objection, we will leave the text as is and = remove the question. 2) in 2.0,=20 QUESTION: It was suggested that mentioning several common acquisition methods, such as local API, WMI, Puppet, DCOM, SNMP, CMDB query, and NEA, without forcing any specific method would be good. I have concerns this could devolve into a "what about my favorite?" contest. OTOH, the charter does specifically call for use of existing standards where applicable, so the use cases document might be a good neutral location for such information, and might force us to consider what types of external interfaces we might need to support when we consider the requirements. It appears that the generic workflow sequence would be a good place to mention such common acquisition methods. Consensus seems to be that this would be rathole to be avoided. We could = recommend the use of standardized data models/information models, but = this really is a runtime/operational decision. I think we simply need to = make sure the requirements recognize that any standardized process must = be able to support either standardized or proprietary (or mixed) sets of = attributes. I recommend we change the text to the following (or put a = similar statement in the requirements draft). A. The application determines which (sets of) posture attributes need to be collected for evaluation. Implementations SHOULD = be able to support (possibly mixed) sets of standardized and proprietary = attributes. 3) In use-cases-05, section 2.0,=20 F. The evaluator compares the collected posture attributes with expected values as expressed in policies. QUESTION: Evaluator generates a report or log or notification of some type? There remains a question of whether this is part of the assessment = process, but looking at it from the old IPO (input-processing-output) = paradigm, or any data flow modeling I have dealt with, there should be = some output as the result of the assessment process. The steps through F = have no output specified, I think it important to mention that = production of some type of output is expected as part of the process, = but the type of output is not necessarily specified. Unless there is strong objection, I recommend changing the question to = bullet G: G. The evaluator reports the result of the assessment, in a standardized = or proprietary format, such as a report or a log entry or a database = entry or a notification.=20 4) in 2.1.2, Endpoint Discovery: The purpose of discovery is to determine the type of endpoint to be posture assessed. QUESTION: Is it just the type? Or is it to identify what endpoint instances to target for assessment using metadata such as the endpoint's organizationally expected type (e.g., expected function/role, etc.) If this is truly endpoint "discovery", then I think this building block = discovers the whole set of endpoints it can see in the network - i.e., = the whole set of endpoints that might be able to be assessed.=20 In the next step (targeting), that building block selects a subset of = the discovered set of endpoints, based on such things as type of = endpoint, organizationally expected function/role, version, etc. =20 --Apple-Mail=_9A218B49-E620-452C-B2B1-A43D70603860 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

1) in = 2.0
1.  Some type of trigger =
initiates the workflow.  For example, an
       operator or an application might trigger the process with a
       request, or the endpoint might trigger the process using an
       event-driven notification.

          QUESTION: Since this is about security automation, can we drop
          the User and just use Application?  Is there a better term to
          use here?  Once the policy is selected, the rest seems like
          something we definitely would want to automate, so I dropped
          the User part.

Unless there is = strong objection, we will leave the text as is and remove the = question.

2) in 2.0, 
        QUESTION: It was suggested that mentioning =
several common
              acquisition methods, such as local API, WMI, Puppet, DCOM,
              SNMP, CMDB query, and NEA, without forcing any specific
              method would be good.  I have concerns this could devolve
              into a "what about my favorite?" contest.  OTOH, the
              charter does specifically call for use of existing
              standards where applicable, so the use cases document
              might be a good neutral location for such information, and
              might force us to consider what types of external
              interfaces we might need to support when we consider the
              requirements.  It appears that the generic workflow
              sequence would be a good place to mention such common
              acquisition methods.

Consensus seems to be that this would be = rathole to be avoided. We could recommend the use of standardized data = models/information  models, but this really is a = runtime/operational decision. I think we simply need to make sure the = requirements recognize that any standardized process must be able to = support either standardized or proprietary (or mixed) sets of = attributes. I recommend we change the text to the following (or put a = similar statement in the requirements = draft).

A.  The =
application determines which (sets of) posture attributes
           need to be collected for evaluation. Implementations SHOULD =
be able to support (possibly mixed) sets of standardized and proprietary =
attributes.


3) In use-cases-05, = section 2.0, 
       F.  The =
evaluator compares the collected posture attributes with
           expected values as expressed in policies.

              QUESTION: Evaluator generates a report or log or
              notification of some =
type?

There remains a question of whether = this is part of the assessment process, but looking at it from the old = IPO (input-processing-output) paradigm, or any data flow modeling I have = dealt with, there should be some output as the result of the assessment = process. The steps through F have no output specified, I think it = important to mention that production of some type of output is expected = as part of the process, but the type of output is not necessarily = specified.

Unless there is strong objection, I = recommend changing the question to bullet G:
G. The evaluator = reports the result of the assessment, in a standardized or proprietary = format, such as  a report or a log entry or a database entry or a = notification. 

4) in 2.1.2,
Endpoint Discovery:  The purpose of discovery is to =
determine the
         type of endpoint to be posture assessed.

         QUESTION: Is it just the type?  Or is it to identify what
         endpoint instances to target for assessment using metadata such
         as the endpoint's organizationally expected type (e.g.,
         expected function/role, etc.)

If = this is truly endpoint "discovery", then I think this building block = discovers the whole set of endpoints it can see in the network - i.e., = the whole set of endpoints that might be able to be = assessed. 

In the next step (targeting), = that building block selects a subset of the discovered set of endpoints, = based on such things as type of endpoint, organizationally expected = function/role, version, = etc.


 

= --Apple-Mail=_9A218B49-E620-452C-B2B1-A43D70603860-- From ncamwing@cisco.com Sun Feb 2 20:58:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304131A013E for ; Sun, 2 Feb 2014 20:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMjul7XlYXC9 for ; Sun, 2 Feb 2014 20:58:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED7B1A00F4 for ; Sun, 2 Feb 2014 20:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22338; q=dns/txt; s=iport; t=1391403527; x=1392613127; h=from:to:subject:date:message-id:mime-version; bh=WYHr227fa9M4JI+6gTVwMuXwgLi5GviXUzQY7Re9tJE=; b=F81O3O+JibMgh3Hgn9TqEPy0g8bDihKIBcLujME8hiXyKAkfguLYtbgF 8l8x1xhRvJDC+jQTAXfrTlQ7QDNU25vIUJ638EtzPgQ3sJ17tfv0oCS3G vTOUNkNP7YPWF2edHOLsgqRqvRUk/pVbul1/RtBpFhZWFd5XvzyW+ILL+ A=; X-Files: draft-camwinget-sacm-requirements-02.txt : 14547 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFALkg71KtJV2b/2dsb2JhbABZgkhEOFeIFLYBgQMWdIIcEIELAQsBDjYwFxAEEw6Hdw2cOrAYF44nEQEHRYRDBItThGyHa4EyiRgOh0mDLYFpAQcXBhw X-IronPort-AV: E=Sophos;i="4.95,770,1384300800"; d="txt'?scan'208,217";a="301184664" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 03 Feb 2014 04:58:44 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s134wis6000537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Feb 2014 04:58:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sun, 2 Feb 2014 22:58:44 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: Requirements -02 draft attached Thread-Index: AQHPIJydNYf0LhzdUkCzXc8dWx4+4w== Date: Mon, 3 Feb 2014 04:58:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.113.160] Content-Type: multipart/mixed; boundary="_004_CF146202968B2ncamwingciscocom_" MIME-Version: 1.0 Subject: [sacm] Requirements -02 draft attached X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 04:58:54 -0000 --_004_CF146202968B2ncamwingciscocom_ Content-Type: multipart/alternative; boundary="_000_CF146202968B2ncamwingciscocom_" --_000_CF146202968B2ncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I have been trying to submit this since last Thursday but for some reason I= can not seem to get access to https://datatracker.ietf.org/submit/ Until I do, given that we have the interim call on Tuesday, I thought I'd s= end a text version to the group here in time for you to review and for us = to discuss then; hopefully I'll be able to submit it as the =9602 draft bef= ore then. Thanks, Nancy. --_000_CF146202968B2ncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <99E7311D316E1549A61508D6A1281408@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi all,

I have been trying to submit this since last Thursday but for some rea= son I can not seem to get access to https://datatracker.ietf.org/submit/

Until I do, given that we have the interim call on Tuesday, I thought = I'd send a text version to the group here in time for you to review and &nb= sp;for us to discuss then; hopefully I'll be able to submit it as the =9602= draft before then.

Thanks,
Nancy.=
--_000_CF146202968B2ncamwingciscocom_-- --_004_CF146202968B2ncamwingciscocom_ Content-Type: text/plain; name="draft-camwinget-sacm-requirements-02.txt" Content-Description: draft-camwinget-sacm-requirements-02.txt Content-Disposition: attachment; filename="draft-camwinget-sacm-requirements-02.txt"; size=14547; creation-date="Mon, 03 Feb 2014 04:58:44 GMT"; modification-date="Mon, 03 Feb 2014 04:58:44 GMT" Content-ID: Content-Transfer-Encoding: base64 CgoKClNBQ00gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTi4gQ2FtLVdpbmdldApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyLCAyMDE0CkV4cGly ZXM6IEF1Z3VzdCA2LCAyMDE0CgoKICAgIFNlY3VyZSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3Vz IE1vbml0b3JpbmcgKFNBQ00pIFJlcXVpcmVtZW50cwogICAgICAgICAgICAgICAgICBkcmFmdC1j YW13aW5nZXQtc2FjbS1yZXF1aXJlbWVudHMtMDIKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgdGhlIHNjb3BlIGFuZCBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciB0aGUKICAgU2Vj dXJlIEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyB3b3JraW5nIGdyb3VwLiAg VGhlCiAgIHJlcXVpcmVtZW50cyBhbmQgc2NvcGUgYXJlIGJhc2VkIG9uIHRoZSBhZ3JlZWQgdXBv biB1c2UgY2FzZXMgYW5kCiAgIGFyY2hpdGVjdHVyZSBkZWZpbmVkLgoKU3RhdHVzIG9mIFRoaXMg TWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJl IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBBdWd1c3QgNiwgMjAxNC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykg MjAxNCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1 bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9u cyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVz cGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9t IHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4 dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zp c2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBp biB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgoKCkNhbS1XaW5nZXQgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgRmVi cnVhcnkgMjAxNAoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIFRl cm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICAyCiAgIDMuICBSZXF1aXJlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAgIDMuMS4gIFJlZmVyZW5jZSBBcmNoaXRlY3R1cmUg TW9kZWwgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgICAzLjIuICBHZW5lcmFs IFNBQ00gcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAg ICAgMy4zLiAgUmVxdWlyZW1lbnRzIGJhc2VkIG9uIFVzZSBDYXNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgNQogICA0LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgIDYuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgNgogICA3LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgNy4yLiAgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICBB dXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDcKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRvZGF5J3MgY2hhbGxlbmdlcyBvZiBl dm9sdmluZyB0aHJlYXRzIGFuZCBpbXByb3ZlZCBhbmFseXRpY3MgdG8KICAgYWRkcmVzcyBzdWNo IHRocmVhdHMgaGlnaGxpZ2h0IGEgbmVlZCB0byBhdXRvbWF0ZSB0aGUgc2VjdXJpbmcgb2YKICAg Ym90aCBpbmZvcm1hdGlvbiBhbmQgdGhlIHN5c3RlbXMgdGhhdCBzdG9yZSwgcHJvY2VzcyBhbmQg dHJhbnNtaXQgdGhlCiAgIGluZm9ybWF0aW9uLiAgU0FDTSdzIGNoYXJ0ZXIgZm9jdXNlcyBvbiBh ZGRyZXNzaW5nIHNvbWUgb2YgdGhlc2UKICAgY2hhbGxlbmdlcyBpbiBhIG5hcnJvd2VyIHNjb3Bl IGJ5IGJvdW5kaW5nIHRoZSB0YXNrIHRvIGFkZHJlc3MgdXNlCiAgIGNhc2VzIHRoYXQgcGVydGFp biB0byB0aGUgcG9zdHVyZSBhc3Nlc3NtZW50IG9mIGVuZHBvaW50cy4KCiAgIFRoaXMgZG9jdW1l bnQgZm9jdXNlcyBvbiBkZXNjcmliaW5nIHRoZSByZXF1aXJlbWVudHMgZm9yIGZhY2lsaXRhdGlu ZwogICB0aGUgZXhjaGFuZ2Ugb2YgcG9zdHVyZSBhc3Nlc3NtZW50IGluZm9ybWF0aW9uLCBpbiBw YXJ0aWN1bGFyLCBmb3IKICAgdGhlIHVzZSBjYXNlcyBhcyBleGVtcGxpZmllZCBpbiBbSS1ELmll dGYtc2FjbS11c2UtY2FzZXNdLgoKMi4gIFRlcm1pbm9sb2d5CgogICBDdXJyZW50bHkgZGVmaW5l ZCBpbiBbSS1ELmlldGYtc2FjbS10ZXJtaW5vbG9neV0uCgozLiAgUmVxdWlyZW1lbnRzCgogICBU aGlzIGRvY3VtZW50IGRlZmluZXMgcmVxdWlyZW1lbnRzIGJhc2VkIG9uIHRoZSBTQUNNIFdHJ3Mg dXNlIGNhc2VzCiAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLXNhY20tdXNlLWNhc2VzXS4gIFRoaXMg c2VjdGlvbiBkZXNjcmliZXMgdGhlCiAgIHJlcXVpcmVtZW50cyB1c2VkIGJ5IHRoZSBTQUNNIFdH IHRvIGFzc2VzcyBhbmQgY29tcGFyZSBjYW5kaWRhdGUKICAgaW5mb3JtYXRpb24gbW9kZWxzIGFu ZCBwcm90b2NvbHMgdG8gc3VpdCB0aGUgYXJjaGl0ZWN0dXJlLiAgVGhlc2UKICAgcmVxdWlyZW1l bnRzIGV4cHJlc3MgY2hhcmFjdGVyaXN0aWNzIG9yIGZlYXR1cmVzIHRoYXQgYSBjYW5kaWRhdGUK ICAgcHJvdG9jb2wgb3IgZGF0YSBtb2RlbCBtdXN0IGJlIGNhcGFibGUgb2Ygb2ZmZXJpbmcgc28g YXMgdG8gZW5zdXJlCiAgIHNlY3VyaXR5IGFuZCBpbnRlcm9wZXJhYmlsaXR5LgoKMy4xLiAgUmVm ZXJlbmNlIEFyY2hpdGVjdHVyZSBNb2RlbAoKICAgVW50aWwgYSByaWNoZXIgYXJjaGl0ZWN0dXJl IGlzIGFncmVlZCB1cG9uLCB0aGUgcmVxdWlyZW1lbnRzIGFyZQogICBwcmVkaWNhdGVkIG9uIHRo ZSBmb2xsb3dpbmcgbW9kZWw6CgoKCgpDYW0tV2luZ2V0ICAgICAgICAgICAgICAgRXhwaXJlcyBB dWd1c3QgNiwgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgQWJicmV2aWF0ZWQgVGl0bGUgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTQK CgogICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLSsgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgIHwgRW5kcG9pbnQg IHwgPC4uLi5BLi4uLj4gfCBFdmFsdWF0b3IgfCA8Li4uLkIuLi4uPiAgfCBBc3Nlc3NtZW50IENv bnN1bWVyIHwKICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0t LS0rICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tfCAgIF4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF4KICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8IEMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgIHwgRW5kcG9pbnQgIHwgPC0t LS0tKyAgICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAg ICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVw b3NpdG9yeSAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgUG9zdHVyZSBBc3Nlc3NtZW50IHw8LS0tLS0tLS0tLS0t LS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBSZXBvc2l0 b3J5ICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLSsKCgoKCiAgICAgICAgICAgICAgICAgICAgICAgIFNpbXBsZSBBcmNoaXRlY3R1cmFs IE1vZGVsCgogICBUaGUgQXJjaGl0ZWN0dXJhbCBNb2RlbCBzaG93biBhYm92ZSBkZW1vbnN0cmF0 ZXM6CgogICBvICBBc3NldDogaXMgdGhlIGVuZHBvaW50IG9mIGludGVyZXN0IHRoYXQgaXMgcG9z dHVyZSB2YWxpZGF0ZWQuCgogICBvICBFdmFsdWF0b3I6IGlzIHRoZSBzZXJ2aWNlIHRoYXQgZXZh bHVhdGVzIHRoZSBwb3N0dXJlIGFzc2Vzc21lbnQKICAgICAgYW5kIHN0b3JlcyB0aGUgcG9zdHVy ZSByZXN1bHQgaW50byBhIHJlcG9zaXRvcnkuCgogICBvICBSZXBvc2l0b3J5OiBpcyB0aGUgc3Rv cmFnZSBjb21wb25lbnQgYm91bmQgdG8gdGhlIEV2YWx1YXRvciB0aGF0CiAgICAgIGNvbnRhaW5z IHRoZSBwb3N0dXJlIGFzc2Vzc21lbnQgaW5mb3JtYXRpb24uCgogICBvICBQb3N0dXJlIEFzc2Vz c21lbnQgUmVwb3NpdG9yeTogaXMgYW5vdGhlciB0eXBlIG9mIHJlcG9zaXRvcnkgKG9yIGEKICAg ICAgQ29sbGVjdG9yKSB0aGF0IGhvbGRzIHBvc3R1cmUgYXNzZXNzbWVudCBpbmZvcm1hdGlvbi4g IFdoaWxlIG5vdAogICAgICBib3VuZCB0byB0aGUgRXZhbHVhdG9yLCBpdCBpcyBhbm90aGVyIHNv dXJjZSBvZiBwb3N0dXJlIGFzc2Vzc21lbnQKICAgICAgaW5mb3JtYXRpb24gKGUuZy4gYSBkYXRh IGFnZ3JlZ2F0aW9uIHBvaW50IGFnZ3JlZ2F0aW5nIHBvc3R1cmUKICAgICAgYXNzZXNzbWVudCB3 aXRoIG90aGVyIGF0dHJpYnV0ZXMpIHRoYXQgY2FuIHByb3ZpZGUgaW5mb3JtYXRpb24gdG8KICAg ICAgc2VydmUgU0FDTSB1c2UgY2FzZXMuCgogICBvICBBc3Nlc3NtZW50IENvbnN1bWVyOiBpcyB0 aGUgc2VydmljZSB0aGF0IHJlcXVpcmVzIHRoZSBwb3N0dXJlCiAgICAgIGFzc2Vzc21lbnRzIGlu Zm9ybWF0aW9uIG9mIG9uZSBvciBtb3JlIGFzc2V0cy4KCiAgIFVzaW5nIHRoaXMgYXJjaGl0ZWN0 dXJhbCByZWZlcmVuY2UgbW9kZWwsIHRoZSBpbnRlcmZhY2VzLCBkYXRhIG1vZGVscwogICBhbmQg dHJhbnNwb3J0cyB1c2VkIHRvIGFmZmVjdCB0aGUgcG9zdHVyZSBhc3Nlc3NtZW50LCBlLmcuIEEg aW4gdGhlCiAgIGZpZ3VyZSBhYm92ZSBoYXZlIGFscmVhZHkgYmVlbiBkZWZpbmVkIGJ5IGRpZmZl cmVudCBtZWNoYW5pc21zLCBmb3IKICAgZXhhbXBsZSwgYW4gSUVURiBkZWZpbmVkIG9uZSB0aHJv dWdoIE5FQS4gIEFzIHRoZSBmb2N1cyBvZiBTQUNNIGlzCiAgIHRoZSBpbmZvcm1hdGlvbiBleGNo YW5nZSB0byBvYnRhaW4gdGhlIHBvc3R1cmUgYXNzZXNzbWVudAogICBpbmZvcm1hdGlvbiwgaXQg Y2FuIGJlIGFjaGlldmVkIHRocm91Z2ggdGhlIGludGVyZmFjZXMgc2hvd24gYXMgQi4KICAgVGhh dCBpcywgaXQgaXMgbm90IGNsZWFyIHRoYXQgdGhlcmUgaXMgYSByZXF1aXJlbWVudCBmb3IgdGhl CiAgIEFzc2Vzc21lbnQgQ29uc3VtZXIgdG8gdGFwIGRpcmVjdGx5IGludG8gdGhlIFJlcG9zaXRv cnkuICBTaW1pbGFybHksCgoKCkNhbS1XaW5nZXQgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCA2LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgRmVicnVhcnkgMjAxNAoKCiAg IGl0IGlzIG5vdCBjbGVhciB0aGF0IFNBQ00gaXMgY2hhcnRlcmVkIHRvIGRlZmluZSB0aGUgaW50 ZXJmYWNlcyBhbmQKICAgZGF0YSBtb2RlbCBmb3IgaG93IGFuIEV2YWx1YXRvciBzdG9yZXMgYW5k IHRyYW5zcG9ydHMgdGhlIGFzc2Vzc21lbnQKICAgcmVzdWx0cyB0byB0aGUgUmVwb3NpdG9yeS4g IFRodXMsIHRoZSBmb2N1cyBvZiB0aGUgcmVxdWlyZW1lbnRzIHdpbGwKICAgcmV2b2x2ZSBhcm91 bmQgdGhlIGRhdGEgbW9kZWxzLCBwcm90b2NvbHMgYW5kIHRyYW5zcG9ydHMgZm9yIEIsIHRoZQog ICBjb21tdW5pY2F0aW9uIG9mIHBvc3R1cmUgYXNzZXNzbWVudCBmcm9tIGFuIEV2YWx1YXRvciB0 byBhbgogICBBc3Nlc3NtZW50IENvbnN1bWVyLgoKMy4yLiAgR2VuZXJhbCBTQUNNIHJlcXVpcmVt ZW50cwoKICAgVGhlIHVzZSBjYXNlcyBkZWZpbmVkIGluIFtJLUQuaWV0Zi1zYWNtLXVzZS1jYXNl c10gYXBwbHkgdG8gbWFueQogICBkZXBsb3ltZW50IHNjZW5hcmlvcy4gIFRvIGVuc3VyZSBpbnRl cm9wZXJhYmlsaXR5LCBzY2FsYWJpbGl0eSBhbmQKICAgZmxleGliaWxpdHkgaW4gYW55IG9mIHRo ZXNlIGRlcGxveW1lbnRzLCB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cwogICBhcmUgZGVmaW5l ZCBmb3IgYWxsIHVzZSBjYXNlczoKCiAgIEctMDAxICBUaGUgZGF0YSBtb2RlbHMsIHByb3RvY29s cyBhbmQgdHJhbnNwb3J0cyBkZWZpbmVkIGJ5IHRoZSBTQUNNCiAgICBXRyBtdXN0IGJlIGV4dGVu c2libGUgdG8gYWxsb3cgc3VwcG9ydCBmb3Igbm9uLXN0YW5kYXJkIGFuZCBmdXR1cmUKICAgIGV4 dGVuc2lvbnMuCgogICBHLTAwMiAgVGhlIGRhdGEgbW9kZWxzLCBwcm90b2NvbHMgYW5kIHRyYW5z cG9ydHMgbXVzdCBiZSBzcGVjaWZpZWQKICAgIHdpdGggZW5vdWdoIGRldGFpbHMgYW5kIHN0YXRl IG1hY2hpbmUgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuCgogICBHLTAwMyAgU0FDTSBtdXN0 IHN1cHBvcnQgYSBicm9hZCBzZXQgb2YgZGVwbG95bWVudCBzY2VuYXJpb3MuICBBcwogICAgc3Vj aCwgaXQgaXMgcG9zc2libGUgdGhhdCB0aGUgc2l6ZSBvciBwb3N0dXJlIGFzc2Vzc21lbnQgaW5m b3JtYXRpb24KICAgIGNhbiB2YXJ5IGZyb20gYSBzaW5nbGUgYXNzZXNzbWVudCB0aGF0IGlzIHNt YWxsIGluIChyZWNvcmQgb3IKICAgIGRhdGFncmFtKSBzaXplIHRvIGEgdmVyeSBsYXJnZSBkYXRh Z3JhbSBvciBhIHZlcnkgbGFyZ2Ugc2V0IG9mCiAgICBhc3Nlc3NtZW50cyBhbmQgbXVzdCBiZSBh ZGRyZXNzZWQgYnkgdGhlIFNBQ00gc3BlY2lmaWNhdGlvbnMKICAgIGRlZmluZWQuICBUaHVzLCB0 aGUgZGF0YSBtb2RlbHMsIHByb3RvY29scyBhbmQgdHJhbnNwb3J0cyBtdXN0IGJlCiAgICBzY2Fs YWJsZS4KCiAgIEctMDA0ICBDb25zaWRlcmF0aW9ucyBmb3IgdGhlIGxpZ2h0d2VpZ2h0IGltcGxl bWVudGF0aW9ucyBvZiBkYXRhCiAgICBtb2RlbHMgYW5kIHRyYW5zcG9ydHMgaXMgcmVxdWlyZWQu ICBVc2UgY2FzZXMsIGVzcGVjaWFsbHkgaW4gdGhlCiAgICB2dWxuZXJhYmlsaXR5IGFzc2Vzc21l bnQgYW5kIHRocmVhdCBkZWZlbnNlIGFwcGxpY2F0aW9ucyByZXF1aXJlCiAgICB0aW1lIGNyaXRp Y2FsaXR5IGluIGJvdGggb2J0YWluaW5nIHRoZSBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFzCiAgICBj b25zdW1pbmcgKGUuZy4gcGFyc2luZykgdGhlIGRhdGEuICBUaGUgYWdpbGl0eSByZXF1aXJlbWVu dCBpcyB0bwogICAgZW5zdXJlIHRoYXQgdGhlIGRhdGEgbW9kZWwsIHByb3RvY29scywgdHJhbnNw b3J0cyBhbmQgaXRzCiAgICBpbXBsZW1lbnRhdGlvbnMgYXJlIHN1aXRhYmxlIHRvIGZpdCBpbiBk aWZmZXJlbnQgZGVwbG95bWVudCBtb2RlbHMKICAgIGFuZCBzY2VuYXJpb3MuCgogICBHLTAwNSAg RGlmZmVyZW50IHRyYW5zcG9ydHMgbXVzdCBiZSBzdXBwb3J0ZWQgdG8gYWRkcmVzcyBkaWZmZXJl bnQKICAgIGRlcGxveW1lbnQgYW5kIHRpbWUgY29uc3RyYWludHMuICBTdXBwb3J0aW5nIGxheWVy IDIsIGxheWVyIDMgYW5kCiAgICBsYXllciA3IHRyYW5zcG9ydHMgYXJlIHRvIGJlIGNvbnNpZGVy ZWQuCgogICBHLTAwNiAgRm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIHNjb3BlIGJvdW5kYXJ5LCBh biBleHBsaWNpdCBzZXQgb2YKICAgIGRhdGEgYXR0cmlidXRlcyBhcyBtYW5kYXRvcnkgdG8gaW1w bGVtZW50IHNob3VsZCBiZSBkZWZpbmVkLiAgV2hpbGUKICAgIHRoZSBTQUNNIGNoYXJ0ZXIgZGVm aW5lcyB0aGUgZm9jdXMgdG8gYmUgb24gcG9zdHVyZSBhc3Nlc3NtZW50LAogICAgYXR0cmlidXRl cyBjb3JyZXNwb25kaW5nIHRvIFBvc3R1cmUgQXNzZXNzbWVudCBzaG91bGQgYmUgZGVzY3JpYmVk LgoKCgoKCkNhbS1XaW5nZXQgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDE0ICAg ICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJy ZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgRmVicnVhcnkgMjAxNAoKCiAgIEctMDA3ICBUbyBh ZGRyZXNzIHNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zLCB0aGUgZGF0YQogICAg bW9kZWwsIHByb3RvY29scyBhbmQgdHJhbnNwb3J0IG11c3QgY29uc2lkZXIgYXV0aG9yaXphdGlv biBiYXNlZCBvbgogICAgcm9sZXMgdG8gb25seSBhbGxvdyBhdXRob3JpemVkIHJlcXVlc3RvcnMg YW5kIHB1Ymxpc2hlcnMgdG8gYWNjZXNzCiAgICB0aGUgaW5mb3JtYXRpb24gYmVpbmcgcmVxdWVz dGVkIG9yIHB1Ymxpc2hlZC4KCjMuMy4gIFJlcXVpcmVtZW50cyBiYXNlZCBvbiBVc2UgQ2FzZXMK CiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHJlcXVpcmVtZW50cyB0aGF0IG1heSBhcHBs eSB0byBpbmZvcm1hdGlvbgogICBtb2RlbHMsIGRhdGEgbW9kZWxzLCBwcm90b2NvbHMgb3IgdHJh bnNwb3J0cyBhcyBpZGVudGlmaWVkIGJ5IHRoZSB1c2UKICAgY2FzZXMgaW4gW0ktRC5pZXRmLXNh Y20tdXNlLWNhc2VzXSBhbmQgcmVmZXJlbmNlZCBieSB0aGUgc2VjdGlvbgogICBudW1iZXJzIGZy b20gdGhhdCBkcmFmdC4KCiAgIFJFUS0wMDEgIFVzZSBDYXNlcyBpbiB0aGUgd2hvbGUgb2YgU2Vj dGlvbiAyIGRlc2NyaWJlIHRoZSBuZWVkIGZvciBhbgogICAgQXR0cmlidXRlIERpY3Rpb25hcnku ICBXaXRoIFNBQ00ncyBzY29wZSBmb2N1c2VkIG9uIFBvc3R1cmUKICAgIEFzc2Vzc21lbnQsIHRo ZSBhdHRyaWJ1dGUgY29sbGVjdGlvbiBhbmQgYWdncmVnYXRpb24gbXVzdCBoYXZlIGEKICAgIHdl bGwgdW5kZXJzdG9vZCBzZXQgb2YgYXR0cmlidXRlcyBpbmNsdXNpdmUgb2YgdGhlaXIgbWVhbmlu ZyBvcgogICAgdXNhZ2UgaW50ZW50LgoKICAgUkVRLTAwMiAgVXNlIENhc2UgMi4xLjEgZGVzY3Jp YmVzIHRoZSBuZWVkIGZvciBhbiBJbmZvcm1hdGlvbiBNb2RlbAogICAgdG8gZHJpdmUgY29udGVu dCBkZWZpbml0aW9uLiAgQXMgdGhlIFNBQ00gV0cgd2lsbCBlbmRlYXZvciB0byByZXVzZQogICAg YWxyZWFkeSBleGlzdGluZyBzdGFuZGFyZHMgd2hpY2ggbWF5IGhhdmUgdGhlaXIgb3duIGRhdGEg bW9kZWxzCiAgICBkZWZpbmVkIGJ5IGluc3RhbnRpYXRpbmcgYW4gaW5mb3JtYXRpb24gbW9kZWws IHRoZSBkYXRhIG1vZGVscyBjYW4KICAgIGJlIG1hcHBlZCB0byBTQUNNJ3MgaW5mb3JtYXRpb24g bW9kZWwuICBTZWUgW1JGQzM0NDRdIGZvciBhCiAgICBkZXNjcmlwdGlvbiBhbmQgZGlzdGluY3Rp b25zIGJldHdlZW4gYW4gaW5mb3JtYXRpb24gYW5kIGRhdGEgbW9kZWwuCgogICBSRVEtMDAzICBV c2UgQ2FzZSAyLjEuMSBkZXNjcmliZXMgdGhlIG5lZWQgdG8gaW5zdGFudGlhdGUgYSBkYXRhCiAg ICBtb2RlbCB0aGF0IGNhbiBtYXAgdG8gdGhlIFNBQ00gcHJvdG9jb2xzIGZvciBwb3N0dXJlIGNv bnRlbnQKICAgIG9wZXJhdGlvbnMgc3VjaCBhcyBwdWJsaWNhdGlvbiwgcXVlcnksIGNoYW5nZSBk ZXRlY3Rpb24gYW5kCiAgICBhc3luY2hyb25vdXMgbm90aWZpY2F0aW9ucy4KCiAgIFJFUS0wMDQg IFVzZSBDYXNlIDIuMS4yIGRlc2NyaWJlcyB0aGUgbmVlZCB0byBkaXNjb3ZlciBlbmRwb2ludHMg YW5kCiAgICB0aGVpciBjb21wb3NpdGlvbi4KCiAgIFJFUS0wMDUgIFVzZSBDYXNlIDIuMS4yIGRl c2NyaWJlcyB0aGUgbmVlZCBmb3IgdGhlIGRhdGEgbW9kZWwgdG8KICAgIHN1cHBvcnQgYSBxdWVy eSBvcGVyYXRpb24gYmFzZWQgb24gYSBzZXQgb2YgYXR0cmlidXRlcyB0byBmYWNpbGl0YXRlCiAg ICBjb2xsZWN0aW9uIG9mIGluZm9ybWF0aW9uIHN1Y2ggYXMgcG9zdHVyZSBhc3Nlc3NtZW50LCBp bnZlbnRvcnkgKG9mCiAgICBlbmRwb2ludHMgb3IgZW5kcG9pbnQgY29tcG9uZW50cykgYW5kIGNv bmZpZ3VyYXRpb24gY2hlY2tsaXN0LgoKICAgUkVRLTAwNiAgVXNlIENhc2UgMi4xLjMgZGVzY3Jp YmVzIHRoZSBuZWVkIGZvciB0aGUgZGF0YSBtb2RlbCB0bwogICAgc3VwcG9ydCB0aGUgbWVhbnMg Zm9yIHRoZSBpbmZvcm1hdGlvbiB0byBiZSBjb2xsZWN0ZWQgdGhyb3VnaCBhCiAgICBxdWVyeSBt ZWNoYW5pc20uCgogICBSRVEtMDA3ICBVc2UgQ2FzZXMgMi4xLjQgYW5kIDIuMS41IGRlc2NyaWJl IHRoZSBuZWVkIGZvciB0aGUgZGF0YQogICAgbW9kZWwgdG8gc3VwcG9ydCB0aGUgbWVhbnMgZm9y IHRoZSBpbmZvcm1hdGlvbiB0byBiZSBwdWJsaXNoZWQKICAgIGFzeW5jaHJvbm91c2x5LiAgU2lt aWxhcmx5LCB0aGUgZGF0YSBtb2RlbCBtdXN0IHN1cHBvcnQgdGhlIG1lYW5zCiAgICBmb3IgYSBy ZXF1ZXN0b3IgdG8gb2J0YWluIHVwZGF0ZXMgb3IgY2hhbmdlIG1vZGlmaWNhdGlvbnMKICAgIGFz eW5jaHJvbm91c2x5LgoKCgoKQ2FtLVdpbmdldCAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDYsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIEFiYnJldmlhdGVkIFRpdGxlICAgICAgICAgICAgICBGZWJydWFyeSAyMDE0CgoKICAg UkVRLTAwOCAgVXNlIENhc2VzIDIuMS40IGFuZCAyLjEuNSBkZXNjcmliZXMgdGhlIG5lZWQgZm9y IHRoZSBkYXRhCiAgICBtb2RlbCB0byBzdXBwb3J0IHNjYWxhYmlsaXR5LiAgRm9yIGV4YW1wbGUs IHRoZSBxdWVyeSBvcGVyYXRpb24gbWF5CiAgICByZXN1bHQgaW4gYSB2ZXJ5IGxhcmdlIHNldCBv ZiBhdHRyaWJ1dGVzIGFzIHdlbGwgYXMgYSBsYXJnZSBzZXQgb2YKICAgIHRhcmdldHMuCgo0LiAg QWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBCYXJi YXJhIEZyYXNlciwgSmltIEJpZWRhIGFuZCBBZGFtCiAgIE1vbnR2aWxsZSBmb3IgcmV2aWV3aW5n IGFuZCBjb250cmlidXRpbmcgdG8gdGhpcyBkcmFmdC4KCjUuICBJQU5BIENvbnNpZGVyYXRpb25z CgogICBUaGlzIG1lbW8gaW5jbHVkZXMgbm8gcmVxdWVzdCB0byBJQU5BLgoKNi4gIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50 cyBmb3IgdGhlIFNBQ00gV0cuICBBcyBzdWNoLCBpdAogICBpcyBleHBlY3RlZCB0aGF0IHNldmVy YWwgZGF0YSBtb2RlbHMsIHByb3RvY29scyBhbmQgdHJhbnNwb3J0cyBtYXkgYmUKICAgZGVmaW5l ZCBvciByZXVzZWQgZnJvbSBhbHJlYWR5IGV4aXN0aW5nIHN0YW5kYXJkcy4gIFRoaXMgc2VjdGlv biB3aWxsCiAgIGhpZ2hsaWdodCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IG1heSBhcHBs eSB0byBTQUNNIGJhc2VkIG9uIHRoZQogICBhcmNoaXRlY3R1cmUgYW5kIHN0YW5kYXJkcyBhcHBs aWVkIGluIFNBQ00uCgo3LiAgUmVmZXJlbmNlcwoKNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMK CiAgIFtJLUQuaWV0Zi1zYWNtLXRlcm1pbm9sb2d5XQogICAgICAgICAgICAgIFdhbHRlcm1pcmUs IEQuLCBNb250dmlsbGUsIEEuLCBhbmQgRC4gSGFycmluZ3RvbiwKICAgICAgICAgICAgICAiVGVy bWlub2xvZ3kgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQiLCBkcmFmdC1pZXRmLXNhY20tCiAgICAg ICAgICAgICAgdGVybWlub2xvZ3ktMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBPY3RvYmVyIDIwMTMu CgogICBbSS1ELmlldGYtc2FjbS11c2UtY2FzZXNdCiAgICAgICAgICAgICAgV2FsdGVybWlyZSwg RC4gYW5kIEQuIEhhcnJpbmd0b24sICJFbmRwb2ludCBTZWN1cml0eQogICAgICAgICAgICAgIFBv c3R1cmUgQXNzZXNzbWVudCAtIEVudGVycHJpc2UgVXNlIENhc2VzIiwgZHJhZnQtaWV0Zi0KICAg ICAgICAgICAgICBzYWNtLXVzZS1jYXNlcy0wNSAod29yayBpbiBwcm9ncmVzcyksIE5vdmVtYmVy IDIwMTMuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgo3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgog ICBbUkZDMzQ0NF0gIFByYXMsIEEuIGFuZCBKLiBTY2hvZW53YWVsZGVyLCAiT24gdGhlIERpZmZl cmVuY2UgYmV0d2VlbgogICAgICAgICAgICAgIEluZm9ybWF0aW9uIE1vZGVscyBhbmQgRGF0YSBN b2RlbHMiLCBSRkMgMzQ0NCwgSmFudWFyeQogICAgICAgICAgICAgIDIwMDMuCgogICBbUkZDNTIw OV0gIFNhbmdzdGVyLCBQLiwgS2hvc3JhdmksIEguLCBNYW5pLCBNLiwgTmFyYXlhbiwgSy4sIGFu ZCBKLgogICAgICAgICAgICAgIFRhcmRvLCAiTmV0d29yayBFbmRwb2ludCBBc3Nlc3NtZW50IChO RUEpOiBPdmVydmlldyBhbmQKICAgICAgICAgICAgICBSZXF1aXJlbWVudHMiLCBSRkMgNTIwOSwg SnVuZSAyMDA4LgoKCgpDYW0tV2luZ2V0ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwg MjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgQWJicmV2aWF0ZWQgVGl0bGUgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTQKCgpBdXRob3In cyBBZGRyZXNzCgogICBOYW5jeSBDYW0tV2luZ2V0CiAgIENpc2NvIFN5c3RlbXMKICAgMzU1MCBD aXNjbyBXYXkKICAgU2FuIEpvc2UsIENBICA5NTEzNAogICBVUwoKICAgRW1haWw6IG5jYW13aW5n QGNpc2NvLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDYW0t V2luZ2V0ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxNCAgICAgICAgICAgICAg ICAgW1BhZ2UgN10K --_004_CF146202968B2ncamwingciscocom_-- From shanna@juniper.net Mon Feb 3 09:37:58 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490801A01CF for ; Mon, 3 Feb 2014 09:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sJA6p7OV7q5 for ; Mon, 3 Feb 2014 09:37:54 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id C93891A016D for ; Mon, 3 Feb 2014 09:37:53 -0800 (PST) Received: from mail47-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Feb 2014 17:37:53 +0000 Received: from mail47-va3 (localhost [127.0.0.1]) by mail47-va3-R.bigfish.com (Postfix) with ESMTP id 6BCC920146; Mon, 3 Feb 2014 17:37:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371Ic85fh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h9a9j1155h) Received-SPF: pass (mail47-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(164054003)(189002)(199002)(50986001)(47976001)(31966008)(74662001)(19580405001)(83322001)(19580395003)(81342001)(49866001)(47446002)(80976001)(47736001)(4396001)(74502001)(81542001)(74316001)(19300405004)(69226001)(74366001)(76796001)(76786001)(76576001)(15202345003)(18717965001)(63696002)(19609705001)(53806001)(54356001)(74706001)(93516002)(92566001)(2656002)(87936001)(87266001)(80022001)(15975445006)(74876001)(79102001)(33646001)(90146001)(81816001)(66066001)(83072002)(56816005)(81686001)(16236675002)(51856001)(93136001)(46102001)(59766001)(77982001)(65816001)(85306002)(85852003)(56776001)(86362001)(94946001)(94316002)(54316002)(76482001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB738; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:ECECF218.ACF23758.D1FF3E7B.4AE5E941.204D5; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail47-va3 (localhost.localdomain [127.0.0.1]) by mail47-va3 (MessageSwitch) id 139144907115301_22617; Mon, 3 Feb 2014 17:37:51 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.231]) by mail47-va3.bigfish.com (Postfix) with ESMTP id F1A1A10004C; Mon, 3 Feb 2014 17:37:50 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Feb 2014 17:37:50 +0000 Received: from BLUPR05MB738.namprd05.prod.outlook.com (10.141.208.21) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 3 Feb 2014 17:37:48 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB738.namprd05.prod.outlook.com (10.141.208.21) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 17:37:46 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0868.013; Mon, 3 Feb 2014 17:37:46 +0000 From: Stephen Hanna To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Consensus on QUESTIONS in use-cases-5 Thread-Index: AQHPIEvuLrYqfm13JUKJgHm3ZQQmWZqiczzQ Date: Mon, 3 Feb 2014 17:37:45 +0000 Message-ID: <0c9854bdd4b54e42a76b1a05a46e36e8@BLUPR05MB737.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 01110342A5 Content-Type: multipart/alternative; boundary="_000_0c9854bdd4b54e42a76b1a05a46e36e8BLUPR05MB737namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: David Waltermire Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:37:58 -0000 --_000_0c9854bdd4b54e42a76b1a05a46e36e8BLUPR05MB737namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, I'm happy with the resolutions that you suggested for these questions. Thanks, Steve From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington Sent: Sunday, February 02, 2014 2:21 PM To: sacm@ietf.org Cc: David Waltermire Subject: [sacm] Consensus on QUESTIONS in use-cases-5 Hi, Trying to get consensus on editing instructions for the use cases draft, so= Dave and Dave can edit a final revision. This email is specifically focuse= d on the QUESTIONS identified in the -05- draft, most of which were first r= aised in reviews of earlier revisions. Subsequent emails will focus on othe= r requested changes, such as clarifying "content". 1) in 2.0 1. Some type of trigger initiates the workflow. For example, an operator or an application might trigger the process with a request, or the endpoint might trigger the process using an event-driven notification. QUESTION: Since this is about security automation, can we drop the User and just use Application? Is there a better term to use here? Once the policy is selected, the rest seems like something we definitely would want to automate, so I dropped the User part. Unless there is strong objection, we will leave the text as is and remove t= he question. 2) in 2.0, QUESTION: It was suggested that mentioning several common acquisition methods, such as local API, WMI, Puppet, DCOM, SNMP, CMDB query, and NEA, without forcing any specific method would be good. I have concerns this could devolve into a "what about my favorite?" contest. OTOH, the charter does specifically call for use of existing standards where applicable, so the use cases document might be a good neutral location for such information, and might force us to consider what types of external interfaces we might need to support when we consider the requirements. It appears that the generic workflow sequence would be a good place to mention such common acquisition methods. Consensus seems to be that this would be rathole to be avoided. We could re= commend the use of standardized data models/information models, but this r= eally is a runtime/operational decision. I think we simply need to make sur= e the requirements recognize that any standardized process must be able to = support either standardized or proprietary (or mixed) sets of attributes. I= recommend we change the text to the following (or put a similar statement = in the requirements draft). A. The application determines which (sets of) posture attributes need to be collected for evaluation. Implementations SHOULD be a= ble to support (possibly mixed) sets of standardized and proprietary attrib= utes. 3) In use-cases-05, section 2.0, F. The evaluator compares the collected posture attributes with expected values as expressed in policies. QUESTION: Evaluator generates a report or log or notification of some type? There remains a question of whether this is part of the assessment process,= but looking at it from the old IPO (input-processing-output) paradigm, or = any data flow modeling I have dealt with, there should be some output as th= e result of the assessment process. The steps through F have no output spec= ified, I think it important to mention that production of some type of outp= ut is expected as part of the process, but the type of output is not necess= arily specified. Unless there is strong objection, I recommend changing the question to bull= et G: G. The evaluator reports the result of the assessment, in a standardized or= proprietary format, such as a report or a log entry or a database entry o= r a notification. 4) in 2.1.2, Endpoint Discovery: The purpose of discovery is to determine the type of endpoint to be posture assessed. QUESTION: Is it just the type? Or is it to identify what endpoint instances to target for assessment using metadata such as the endpoint's organizationally expected type (e.g., expected function/role, etc.) If this is truly endpoint "discovery", then I think this building block dis= covers the whole set of endpoints it can see in the network - i.e., the who= le set of endpoints that might be able to be assessed. In the next step (targeting), that building block selects a subset of the d= iscovered set of endpoints, based on such things as type of endpoint, organ= izationally expected function/role, version, etc. --_000_0c9854bdd4b54e42a76b1a05a46e36e8BLUPR05MB737namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 <= /p>

I’m happy with the = resolutions that you suggested for these questions.

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Sunday, February 02, 2014 2:21 PM
To: sacm@ietf.org
Cc: David Waltermire
Subject: [sacm] Consensus on QUESTIONS in use-cases-5

 

Hi,

 

Trying to get consensus on editing instructions for = the use cases draft, so Dave and Dave can edit a final revision. This email= is specifically focused on the QUESTIONS identified in the -05- draft, mos= t of which were first raised in reviews of earlier revisions. Subsequent emails will focus on other requested chan= ges, such as clarifying "content".

 

1) in 2.0

1.  Some type of trigger initiates t=
he workflow.  For example, an
       oper=
ator or an application might trigger the process with a
       requ=
est, or the endpoint might trigger the process using an
       even=
t-driven notification.
 
       =
;   QUESTION: Since this is about security automation, can we dro=
p
       =
;   the User and just use Application?  Is there a better te=
rm to
       =
;   use here?  Once the policy is selected, the rest seems l=
ike
       =
;   something we definitely would want to automate, so I dropped<=
o:p>
       =
;   the User part.

 

Unless there is strong objection, we will leave the = text as is and remove the question.

 

2) in 2.0, 

       =
; QUESTION: It was suggested that mentioning several common

       =
;       acquisition methods, such as local AP=
I, WMI, Puppet, DCOM,


       =
;       SNMP, CMDB query, and NEA, without fo=
rcing any specific


       =
;       method would be good.  I have co=
ncerns this could devolve


       =
;       into a "what about my favorite?&=
quot; contest.  OTOH, the


       =
;       charter does specifically call for us=
e of existing


       =
;       standards where applicable, so the us=
e cases document


       =
;       might be a good neutral location for =
such information, and


       =
;       might force us to consider what types=
 of external


       =
;       interfaces we might need to support w=
hen we consider the


       =
;       requirements.  It appears that t=
he generic workflow


       =
;       sequence would be a good place to men=
tion such common


       =
;       acquisition methods.

 

Consensus seems to be that this would be rathole to = be avoided. We could recommend the use of standardized data models/informat= ion  models, but this really is a runtime/operational decision. I thin= k we simply need to make sure the requirements recognize that any standardized process must be able to support either sta= ndardized or proprietary (or mixed) sets of attributes. I recommend we chan= ge the text to the following (or put a similar statement in the requirement= s draft).

 

A.  The application determines which=
 (sets of) posture attributes
       =
;    need to be collected for evaluation. Implementations SH=
OULD be able to support (possibly mixed) sets of standardized and proprieta=
ry attributes.

 

 

3) In use-cases-05, section 2.0,  

       F.&n=
bsp; The evaluator compares the collected posture attributes with
       =
;    expected values as expressed in policies.

 


       =
;       QUESTION: Evaluator generates a repor=
t or log or


       &nbs=
p;      notification of some type?=





 

There remains a question of whether this is part of = the assessment process, but looking at it from the old IPO (input-processin= g-output) paradigm, or any data flow modeling I have dealt with, there shou= ld be some output as the result of the assessment process. The steps through F have no output specified, I th= ink it important to mention that production of some type of output is expec= ted as part of the process, but the type of output is not necessarily speci= fied.

 

Unless there is strong objection, I recommend changi= ng the question to bullet G:

G. The evaluator reports the result of the assessmen= t, in a standardized or proprietary format, such as  a report or a log= entry or a database entry or a notification. 

 

4) in 2.1.2,

Endpoint Discovery:  The purpose of =
discovery is to determine the
       =
;  type of endpoint to be posture assessed.
 
       =
;  QUESTION: Is it just the type?  Or is it to identify what=

       =
;  endpoint instances to target for assessment using metadata such
       =
;  as the endpoint's organizationally expected type (e.g.,<=
/pre>

       =
;  expected function/role, etc.)




 

If this is truly endpoint "discovery", the= n I think this building block discovers the whole set of endpoints it can s= ee in the network - i.e., the whole set of endpoints that might be able to = be assessed. 

 

In the next step (targeting), that building block se= lects a subset of the discovered set of endpoints, based on such things as = type of endpoint, organizationally expected function/role, version, et= c.

 

 

 

 

--_000_0c9854bdd4b54e42a76b1a05a46e36e8BLUPR05MB737namprd05pro_-- From david.waltermire@nist.gov Mon Feb 3 13:42:35 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EF31A0232 for ; Mon, 3 Feb 2014 13:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyQpIxKHuPjy for ; Mon, 3 Feb 2014 13:42:33 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id B99B71A01EE for ; Mon, 3 Feb 2014 13:42:32 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 21:42:30 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) with mapi id 15.00.0868.013; Mon, 3 Feb 2014 21:42:30 +0000 From: "Waltermire, David A." To: "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: Requirements -02 draft attached Thread-Index: AQHPIJydNYf0LhzdUkCzXc8dWx4+45qj0cYQ Date: Mon, 3 Feb 2014 21:42:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(53754006)(377454003)(164054003)(189002)(199002)(92566001)(53806001)(74706001)(93516002)(63696002)(54356001)(80022001)(81816001)(59766001)(65816001)(51856001)(93136001)(46102001)(86362001)(76482001)(56776001)(54316002)(94946001)(94316002)(77982001)(85852003)(85306002)(74876001)(87936001)(79102001)(80976001)(47446002)(15975445006)(56816005)(83072002)(87266001)(66066001)(2656002)(33646001)(90146001)(81686001)(47736001)(4396001)(81342001)(81542001)(74502001)(31966008)(19580405001)(74662001)(83322001)(19580395003)(47976001)(50986001)(76576001)(77096001)(76786001)(76796001)(49866001)(74366001)(74316001)(69226001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EE2CF27C.ADEA97D1.F0F7BD8B.8AF5E941.2054C; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Requirements -02 draft attached X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:42:35 -0000 Nancy, Thanks for your work on this. A few comments/questions on your latest draft= : In section 3.1, I like having a general model that helps to provide some co= ntext to the requirements discussion. I know this has been a point of conte= ntion in past discussions. I believe that including something abstract here= begins to establish some conceptual relationships between the components t= hat are discussed in the charter and use cases (e.g., endpoints, evaluators= , collectors, repositories of collection and evaluation data). It helps ide= ntify where there are separation of concerns for which we need to have requ= irements (and eventually data models and protocols). The difficulty here is= that we do not want to be too prescriptive too soon. This is a hard balanc= e to create and maintain. The Simple Architectural Model: - Asset should be changed to endpoint in the descriptive text to be in sync= with the diagram. You may want to change "Asset: is the endpoint of intere= st that is posture validated." to "Endpoint: The computing device for which= posture will be collected for evaluation as part of a posture assessment." - It is not clear in this model that the concepts of collection and evaluat= ion are separated. In fact, the notion of collection is mostly absent in th= e model. Without getting into implementation details, we should be able to = illustrate this by having separate logical entities for endpoint (posture s= tate), collector (point of posture state observation), and evaluator (point= of posture state evaluation). - Just to clarify, the statement "A in the figure above have already been d= efined by different mechanisms" and others in the paragraph makes it sound = like work around these methods is out of scope for the requirements documen= t. I believe we will have work to do to profile and/or extend existing prot= ocols to carry standardized software inventory and configuration informatio= n. We need to be sure to capture requirements that will ensure that existin= g mechanisms can be used appropriately to do this. More on this later in re= gards to section 3.3. - The statement "As the focus of SACM is the information exchange to obtain= the posture assessment information, it can be achieved through the interfa= ces shown as B." is making the assumption that the only point of interactio= n for a user or application is with an evaluator. Does this account for a s= cenario where a user or application wishes to ensure that specific posture = is collected for future evaluation without performing an immediate evaluati= on? An example would be to support retroactive analysis of historic endpoin= t posture. - In this model it is not clear what the role is of different repositories = relative to different kinds of information. We have talked about a few diff= erent kinds of data including: * Posture attribute lists and other metadata that will be used to drive c= ollection using various collection mechanisms; describing what subset of po= sture is of interest to collect * Set of contextualized posture attribute values that represent the resul= ts of posture collection for an endpoint pertaining to specific hardware, a= nd software contexts. * Evaluation rules that define expected posture attribute values, and the= logical operations (e.g., AND, OR, less than, greater than, equal to, etc)= used for evaluation. * Assessment results describing the outcome(s) of an evaluation. - The characterization of interfaces A, B, and C does seem to reflect the c= hartered item for defining "a standards-track document specifying a protoco= l and data format for retrieving configuration and policy information for d= riving data collection and analysis". Section 3.2: These seem like a good start at general requirements. Section 3.3: These requirements seem to be focused around interactions with a "content r= epository" and not an endpoint oriented collection mechanism. Is this inten= ded? I don't see any requirements here around data collection patterns related t= o UC 2.1.3 Posture Attribute Value Collection. I see two common patterns he= re: 1) querying directly for posture attribute values and 2) notification o= f changes to posture attribute values as they occur or when connectivity is= sufficient to support it. Also, there is no requirement for an information= /data model for communicating posture attribute values/actual state (e.g., = software inventory, configuration, privileges). This will drive use of exis= ting protocols in specific ways. For example, client or server originated c= ommunication patterns. REQ-008 - I'm not sure what this requirement is defining. Please let me know if you need any additional details. Thanks, Dave -- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Cam-Winget (nc= amwing) Sent: Sunday, February 02, 2014 11:59 PM To: sacm@ietf.org Subject: [sacm] Requirements -02 draft attached Hi all, I have been trying to submit this since last Thursday but for some reason I= can not seem to get access to=A0https://datatracker.ietf.org/submit/ Until I do, given that we have the interim call on Tuesday, I thought I'd s= end a text version to the group here in time for you to review and =A0for u= s to discuss then; hopefully I'll be able to submit it as the -02 draft bef= ore then. Thanks, Nancy. From dromasca@avaya.com Tue Feb 4 02:22:55 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D861A036E for ; Tue, 4 Feb 2014 02:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RNhn_HLx0Fu for ; Tue, 4 Feb 2014 02:22:54 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id F10DE1A02BC for ; Tue, 4 Feb 2014 02:22:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAGO+8FLGmAcV/2dsb2JhbABZgkgjIThXvhiBCRZ0gicBAQMSG14BDAkVViYBBBsah2MBnWmEUawIF45Eg1yBFASfGosxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,778,1384318800"; d="scan'208,217";a="48003914" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Feb 2014 05:22:53 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 04 Feb 2014 05:12:01 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 05:22:51 -0500 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Volunteers - please step up! Thread-Index: Ac8hkw7kjuJWqD+mRzyULI4em5X5RA== Date: Tue, 4 Feb 2014 10:22:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3EB9CB@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EB9CBAZFFEXMB04globa_" MIME-Version: 1.0 Subject: [sacm] Volunteers - please step up! X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 10:22:56 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EB9CBAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For the virtual interim today (11AM - 1PM EST) we still need two volunteers= for taking notes! We strongly prefer two note takers independent of the ch= airs - no need to record all details, but mostly consensus calls and action= items. Stepping up before the call so that we can save precious time in th= e meeting will be highly appreciated. Thanks and Regards, Adam and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EB9CBAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

For the virtual interim today (11AM – 1PM EST)= we still need two volunteers for taking notes! We strongly prefer two note= takers independent of the chairs – no need to record all details, bu= t mostly consensus calls and action items. Stepping up before the call so that we can save precious time in the meeting will b= e highly appreciated.

 

Thanks and Regards,

 

Adam and Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EB9CBAZFFEXMB04globa_-- From dromasca@avaya.com Wed Feb 5 02:35:21 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC13D1A00D5 for ; Wed, 5 Feb 2014 02:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4Q62aItnJ_a for ; Wed, 5 Feb 2014 02:35:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E0D971A00C6 for ; Wed, 5 Feb 2014 02:35:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAKYS8lKHCzI1/2dsb2JhbABZgkgjIThXqEKWAYELFnSCJwEBAxILEF4BDAkVViYBBBsah2MBDJ4YhFKrehMEjkQtgjoPZoEUBJ8bizGDLYIq X-IronPort-AV: E=Sophos;i="4.95,786,1384318800"; d="scan'208,217";a="48062712" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Feb 2014 05:35:19 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Feb 2014 05:22:42 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 05:35:17 -0500 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: sacm wg meeting at ietf-89 - call for agenda items Thread-Index: Ac8iXfW4OnYONXbKQZCzdAHqn1Kp4Q== Date: Wed, 5 Feb 2014 10:35:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3EC7B8@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7B8AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [sacm] sacm wg meeting at ietf-89 - call for agenda items X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 10:35:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7B8AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda at https://datatracker.ietf.org/meeting/89/agenda.tx= t shows the WG meeting scheduled for Thursday 3/6 in the 900-1130 meeting s= lot. Note that this scheduling is subject to change. If you plan to present and discuss your work at the meeting please send us = your agenda request including the topic, name of the relevant I-D or I-Ds a= nd the estimated time. Items which are part of the WG charter have higher p= riority, non-chartered items will be included if time allows. Thanks and Regards, Adam and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7B8AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda at https://datatracker.ietf.org/meeting/89/agenda.txt shows the WG meeting= scheduled for Thursday 3/6 in the 900-1130 meeting slot. Note that this sc= heduling is subject to change.

 

If you plan to present and discuss your work at the = meeting please send us your agenda request including the topic, name of the= relevant I-D or I-Ds and the estimated time. Items which are part of the W= G charter have higher priority, non-chartered items will be included if time allows.

 

Thanks and Regards,

 

Adam and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7B8AZFFEXMB04globa_-- From david.waltermire@nist.gov Wed Feb 5 09:29:16 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7001A016B for ; Wed, 5 Feb 2014 09:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eme1DfbmzMIr for ; Wed, 5 Feb 2014 09:29:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id E1E261A00F7 for ; Wed, 5 Feb 2014 09:29:11 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 17:29:09 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 17:29:09 +0000 From: "Waltermire, David A." To: David Harrington , "sacm@ietf.org" Thread-Topic: Consensus on QUESTIONS in use-cases-5 Thread-Index: AQHPIEvjKn+mejCpOEK/PexIBe7RNpqm1L7g Date: Wed, 5 Feb 2014 17:29:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(164054003)(199002)(189002)(47736001)(19580405001)(50986001)(49866001)(83322001)(33646001)(47976001)(19580395003)(31966008)(74662001)(74502001)(80976001)(81542001)(81342001)(76786001)(19300405004)(74316001)(74366001)(76796001)(69226001)(76576001)(77096001)(15202345003)(15975445006)(65816001)(94946001)(85852003)(56816005)(81816001)(83072002)(63696002)(94316002)(79102001)(86362001)(81686001)(4396001)(47446002)(90146001)(80022001)(87266001)(85306002)(87936001)(2656002)(19609705001)(59766001)(74706001)(92566001)(46102001)(66066001)(74876001)(93136001)(93516002)(76482001)(56776001)(53806001)(54316002)(16236675002)(77982001)(51856001)(54356001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EEECF228.8EF23758.51CE1E7B.CAE6E941.205A9; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f9756a56bdb24678a3773b1c77db086dBLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:29:16 -0000 --_000_f9756a56bdb24678a3773b1c77db086dBLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following questions were discussed at the SACM virtual meeting yesterda= y. The following was my recollection of the consensus on the call (marked w= ith [DAW:]). Please let us know ASAP about any strong objections or suggested modificati= ons to the changes described below. We will incorporate the current consens= us into an updated use cases draft (-06) to be posted on Friday, 2/14. Thanks, Dave From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Sunday, February 02, 2014 2:21 PM To: sacm@ietf.org Cc: Waltermire, David A. Subject: Consensus on QUESTIONS in use-cases-5 Hi, Trying to get consensus on editing instructions for the use cases draft, so= Dave and Dave can edit a final revision. This email is specifically focuse= d on the QUESTIONS identified in the -05- draft, most of which were first r= aised in reviews of earlier revisions. Subsequent emails will focus on othe= r requested changes, such as clarifying "content". 1) in 2.0 1. Some type of trigger initiates the workflow. For example, an operator or an application might trigger the process with a request, or the endpoint might trigger the process using an event-driven notification. QUESTION: Since this is about security automation, can we drop the User and just use Application? Is there a better term to use here? Once the policy is selected, the rest seems like something we definitely would want to automate, so I dropped the User part. Unless there is strong objection, we will leave the text as is and remove t= he question. [DAW: The consensus was to leave the text as is and remove the question.] 2) in 2.0, QUESTION: It was suggested that mentioning several common acquisition methods, such as local API, WMI, Puppet, DCOM, SNMP, CMDB query, and NEA, without forcing any specific method would be good. I have concerns this could devolve into a "what about my favorite?" contest. OTOH, the charter does specifically call for use of existing standards where applicable, so the use cases document might be a good neutral location for such information, and might force us to consider what types of external interfaces we might need to support when we consider the requirements. It appears that the generic workflow sequence would be a good place to mention such common acquisition methods. Consensus seems to be that this would be rathole to be avoided. We could re= commend the use of standardized data models/information models, but this r= eally is a runtime/operational decision. I think we simply need to make sur= e the requirements recognize that any standardized process must be able to = support either standardized or proprietary (or mixed) sets of attributes. I= recommend we change the text to the following (or put a similar statement = in the requirements draft). [DAW: The consensus was to update the current text (for item A) to the foll= owing and to remove the question.] A. The application determines which (sets of) posture attributes need to be collected for evaluation. Implementations SHOULD be a= ble to support (possibly mixed) sets of standardized and proprietary attrib= utes. 3) In use-cases-05, section 2.0, F. The evaluator compares the collected posture attributes with expected values as expressed in policies. QUESTION: Evaluator generates a report or log or notification of some type? There remains a question of whether this is part of the assessment process,= but looking at it from the old IPO (input-processing-output) paradigm, or = any data flow modeling I have dealt with, there should be some output as th= e result of the assessment process. The steps through F have no output spec= ified, I think it important to mention that production of some type of outp= ut is expected as part of the process, but the type of output is not necess= arily specified. Unless there is strong objection, I recommend changing the question to bull= et G: G. The evaluator reports the result of the assessment, in a standardized or= proprietary format, such as a report or a log entry or a database entry o= r a notification. [DAW: The consensus was to adopt the text below as a new item G and to remo= ve the question. G. The evaluator reports the evaluation result for the requested assessment= , in a standardized or proprietary format, such as a report, a log entry, = a database entry, or a notification. ] 4) in 2.1.2, Endpoint Discovery: The purpose of discovery is to determine the type of endpoint to be posture assessed. QUESTION: Is it just the type? Or is it to identify what endpoint instances to target for assessment using metadata such as the endpoint's organizationally expected type (e.g., expected function/role, etc.) If this is truly endpoint "discovery", then I think this building block dis= covers the whole set of endpoints it can see in the network - i.e., the who= le set of endpoints that might be able to be assessed. In the next step (targeting), that building block selects a subset of the d= iscovered set of endpoints, based on such things as type of endpoint, organ= izationally expected function/role, version, etc. [DAW: The discussion on the call resulted in the identification of two dist= inct concepts, Endpoint Discovery and Endpoint Characterization, that are n= eeded to support the identification of what endpoints should be targeted fo= r an assessment. Both of these concepts have been combined in the current "= Endpoint Discovery" building block. There was agreement that these two aspe= cts should be broken out into distinct building block items. I took the act= ion to propose some new text. Please let us know if you have any objections= or suggested changes to the following proposed change: Endpoint Discovery: To determine the current or historic presence of endpoi= nts in the environment that are available for posture assessment. Endpoint Characterization: The act of acquiring, through automated collecti= on or manual input, and organizing attributes associated with an endpoint (= e.g., type, organizationally expected function/role, hardware/software vers= ions) that can be used to evaluate organizational policies that determine w= hat endpoints should be posture assessed. Identify Endpoint Targets (slight modifications): To identify what potenti= al endpoint targets the checklist should apply to based on evaluating organ= izational policies against known endpoint attributes.] --_000_f9756a56bdb24678a3773b1c77db086dBLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following questions w= ere discussed at the SACM virtual meeting yesterday. The following was my r= ecollection of the consensus on the call (marked with [DAW:]).

 <= /p>

Please let us know ASAP a= bout any strong objections or suggested modifications to the changes descri= bed below. We will incorporate the current consensus into an updated use cases draft (-06) to be posted on Friday, 2/14.<= /span>

 <= /p>

Thanks,=

Dave

 <= /p>

From: David Ha= rrington [mailto:ietfdbh@comcast.net]
Sent: Sunday, February 02, 2014 2:21 PM
To: sacm@ietf.org
Cc: Waltermire, David A.
Subject: Consensus on QUESTIONS in use-cases-5

 

Hi,

 

Trying to get consensus on editing instructions for = the use cases draft, so Dave and Dave can edit a final revision. This email= is specifically focused on the QUESTIONS identified in the -05- draft, mos= t of which were first raised in reviews of earlier revisions. Subsequent emails will focus on other requested chan= ges, such as clarifying "content".

 

1) in 2.0

1.  Some type of trigger initiates t=
he workflow.  For example, an
       oper=
ator or an application might trigger the process with a
       requ=
est, or the endpoint might trigger the process using an
       even=
t-driven notification.
 
       =
;   QUESTION: Since this is about security automation, can we dro=
p
       =
;   the User and just use Application?  Is there a better te=
rm to
       =
;   use here?  Once the policy is selected, the rest seems l=
ike
       =
;   something we definitely would want to automate, so I dropped<=
o:p>
       =
;   the User part.

 

Unless there is strong objection, we will leave the = text as is and remove the question.

 

[DAW: The consensus was t= o leave the text as is and remove the question.]

 <= /p>

2) in 2.0, 

       =
; QUESTION: It was suggested that mentioning several common

       =
;       acquisition methods, such as local AP=
I, WMI, Puppet, DCOM,


       =
;       SNMP, CMDB query, and NEA, without fo=
rcing any specific


       =
;       method would be good.  I have co=
ncerns this could devolve


       =
;       into a "what about my favorite?&=
quot; contest.  OTOH, the


       =
;       charter does specifically call for us=
e of existing


       =
;       standards where applicable, so the us=
e cases document


       =
;       might be a good neutral location for =
such information, and


       =
;       might force us to consider what types=
 of external


       &nbs=
p;      interfaces we might need to support w=
hen we consider the


       =
;       requirements.  It appears that t=
he generic workflow


       =
;       sequence would be a good place to men=
tion such common


       =
;       acquisition methods.

 

Consensus seems to be that this would be rathole to = be avoided. We could recommend the use of standardized data models/informat= ion  models, but this really is a runtime/operational decision. I thin= k we simply need to make sure the requirements recognize that any standardized process must be able to support either sta= ndardized or proprietary (or mixed) sets of attributes. I recommend we chan= ge the text to the following (or put a similar statement in the requirement= s draft).

 

[DAW: The consensus was t= o update the current text (for item A) to the following and to remove the q= uestion.]

 

A.  The application determines which=
 (sets of) posture attributes
       =
;    need to be collected for evaluation. Implementations SH=
OULD be able to support (possibly mixed) sets of standardized and proprieta=
ry attributes.

 <= /p>

 

3) In use-cases-05, section 2.0,  

       F.&n=
bsp; The evaluator compares the collected posture attributes with
       =
;    expected values as expressed in policies.

 


       =
;       QUESTION: Evaluator generates a repor=
t or log or


       =
;       notification of some type?=





 

There remains a question of whether this is part of = the assessment process, but looking at it from the old IPO (input-processin= g-output) paradigm, or any data flow modeling I have dealt with, there shou= ld be some output as the result of the assessment process. The steps through F have no output specified, I th= ink it important to mention that production of some type of output is expec= ted as part of the process, but the type of output is not necessarily speci= fied.

 

Unless there is strong objection, I recommend changi= ng the question to bullet G:

G. The evaluator reports the result of the assessmen= t, in a standardized or proprietary format, such as  a report or a log= entry or a database entry or a notification. 

 

[DAW: The consensus was t= o adopt the text below as a new item G and to remove the question.

 <= /p>

G. The evaluator reports = the evaluation result for the requested assessment, in a standardized or pr= oprietary format, such as  a report, a log entry, a database entry, or a notification. ]

 <= /p>

4) in 2.1.2,

Endpoint Discovery:  The purpose of =
discovery is to determine the
       =
;  type of endpoint to be posture assessed.
 
       =
;  QUESTION: Is it just the type?  Or is it to identify what=

       =
;  endpoint instances to target for assessment using metadata such
       =
;  as the endpoint's organizationally expected type (e.g.,<=
/pre>

       =
;  expected function/role, etc.)




 

If this is truly endpoint "discovery", the= n I think this building block discovers the whole set of endpoints it can s= ee in the network - i.e., the whole set of endpoints that might be able to = be assessed. 

 

In the next step (targeting), that building block se= lects a subset of the discovered set of endpoints, based on such things as = type of endpoint, organizationally expected function/role, version, et= c.

 

[DAW: The discussion o= n the call resulted in the identification of two distinct concepts, Endpoin= t Discovery and Endpoint Characterization, that are needed to support the i= dentification of what endpoints should be targeted for an assessment. Both of these concepts have been combined i= n the current “Endpoint Discovery” building block. There was ag= reement that these two aspects should be broken out into distinct building = block items. I took the action to propose some new text. Please let us know if you have any objections or suggested chang= es to the following proposed change:

 

Endpoint Discovery: To= determine the current or historic presence of endpoints in the environment= that are available for posture assessment.

 

Endpoint Characterizat= ion: The act of acquiring, through automated collection or manual input, an= d organizing attributes associated with an endpoint (e.g., type, organizati= onally expected function/role, hardware/software versions) that can be used to evaluate organizational policies that determ= ine what endpoints should be posture assessed.

 

Identify Endpoint Targ= ets (slight modifications):  To identify what potential endpoint targe= ts the checklist should apply to based on evaluating organizational policie= s against known endpoint attributes.]

 <= /p>

--_000_f9756a56bdb24678a3773b1c77db086dBLUPR09MB038namprd09pro_-- From gunnar.engelbach@threatguard.com Wed Feb 5 10:41:59 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17E41A00E2 for ; Wed, 5 Feb 2014 10:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7klf-998yc3 for ; Wed, 5 Feb 2014 10:41:57 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id BAC291A001A for ; Wed, 5 Feb 2014 10:41:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=i4CC+aPXtq36jmwm6YZqMvYmChU9ya1XlaevtQkwFZYG0tk9rEXMRkS36CwwNHo0lLD84NRJxgl8eyncxDV8/6udJiJRIztDPsRqJ1oEyD+PX9n3YzpZyJEY6PX9sIbm; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 13792 invoked from network); 5 Feb 2014 10:48:22 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 10:48:22 -0800 Message-ID: <52F28602.4040001@ThreatGuard.com> Date: Wed, 05 Feb 2014 13:42:10 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Waltermire, David A." , David Harrington , "sacm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:42:00 -0000 All of this looks good to me, with one additional comment near the bottom... --gun On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > The following questions were discussed at the SACM virtual meeting > yesterday. The following was my recollection of the consensus on the > call (marked with [DAW:]). > > Please let us know ASAP about any strong objections or suggested > modifications to the changes described below. We will incorporate the > current consensus into an updated use cases draft (-06) to be posted on > Friday, 2/14. > > Thanks, > > Dave > > *From:*David Harrington [mailto:ietfdbh@comcast.net] > *Sent:* Sunday, February 02, 2014 2:21 PM > *To:* sacm@ietf.org > *Cc:* Waltermire, David A. > *Subject:* Consensus on QUESTIONS in use-cases-5 > > Hi, > > Trying to get consensus on editing instructions for the use cases draft, > so Dave and Dave can edit a final revision. This email is specifically > focused on the QUESTIONS identified in the -05- draft, most of which > were first raised in reviews of earlier revisions. Subsequent emails > will focus on other requested changes, such as clarifying "content". > > 1) in 2.0 > > 1. Some type of trigger initiates the workflow. For example, an > > operator or an application might trigger the process with a > > request, or the endpoint might trigger the process using an > > event-driven notification. > > > > QUESTION: Since this is about security automation, can we drop > > the User and just use Application? Is there a better term to > > use here? Once the policy is selected, the rest seems like > > something we definitely would want to automate, so I dropped > > the User part. > > Unless there is strong objection, we will leave the text as is and > remove the question. > > [DAW: The consensus was to leave the text as is and remove the question.] > > 2) in 2.0, > > QUESTION: It was suggested that mentioning several common > > acquisition methods, such as local API, WMI, Puppet, DCOM, > > SNMP, CMDB query, and NEA, without forcing any specific > > method would be good. I have concerns this could devolve > > into a "what about my favorite?" contest. OTOH, the > > charter does specifically call for use of existing > > standards where applicable, so the use cases document > > might be a good neutral location for such information, and > > might force us to consider what types of external > > interfaces we might need to support when we consider the > > requirements. It appears that the generic workflow > > sequence would be a good place to mention such common > > acquisition methods. > > Consensus seems to be that this would be rathole to be avoided. We could > recommend the use of standardized data models/information models, but > this really is a runtime/operational decision. I think we simply need to > make sure the requirements recognize that any standardized process must > be able to support either standardized or proprietary (or mixed) sets of > attributes. I recommend we change the text to the following (or put a > similar statement in the requirements draft). > > [DAW: The consensus was to update the current text (for item A) to the > following and to remove the question.] > > A. The application determines which (sets of) posture attributes > > need to be collected for evaluation. Implementations SHOULD be able to support (possibly mixed) sets of standardized and proprietary attributes. > > 3) In use-cases-05, section 2.0, > > F. The evaluator compares the collected posture attributes with > > expected values as expressed in policies. > > > > QUESTION: Evaluator generates a report or log or > > notification of some type? > > There remains a question of whether this is part of the assessment > process, but looking at it from the old IPO (input-processing-output) > paradigm, or any data flow modeling I have dealt with, there should be > some output as the result of the assessment process. The steps through F > have no output specified, I think it important to mention that > production of some type of output is expected as part of the process, > but the type of output is not necessarily specified. > > Unless there is strong objection, I recommend changing the question to > bullet G: > > G. The evaluator reports the result of the assessment, in a standardized > or proprietary format, such as a report or a log entry or a database > entry or a notification. > > [DAW: The consensus was to adopt the text below as a new item G and to > remove the question. > > G. The evaluator reports the evaluation result for the requested > assessment, in a standardized or proprietary format, such as a report, > a log entry, a database entry, or a notification. ] > > 4) in 2.1.2, > > Endpoint Discovery: The purpose of discovery is to determine the > > type of endpoint to be posture assessed. > > > > QUESTION: Is it just the type? Or is it to identify what > > endpoint instances to target for assessment using metadata such > > as the endpoint's organizationally expected type (e.g., > > expected function/role, etc.) > > If this is truly endpoint "discovery", then I think this building block > discovers the whole set of endpoints it can see in the network - i.e., > the whole set of endpoints that might be able to be assessed. > > In the next step (targeting), that building block selects a subset of > the discovered set of endpoints, based on such things as type of > endpoint, organizationally expected function/role, version, etc. > > [DAW: The discussion on the call resulted in the identification of two > distinct concepts, Endpoint Discovery and Endpoint Characterization, > that are needed to support the identification of what endpoints should > be targeted for an assessment. Both of these concepts have been combined > in the current “Endpoint Discovery” building block. There was agreement > that these two aspects should be broken out into distinct building block > items. I took the action to propose some new text. Please let us know if > you have any objections or suggested changes to the following proposed > change: > > Endpoint Discovery: To determine the current or historic presence of > endpoints in the environment that are available for posture assessment. > > Endpoint Characterization: The act of acquiring, through automated > collection or manual input, and organizing attributes associated with an > endpoint (e.g., type, organizationally expected function/role, > hardware/software versions) that can be used to evaluate organizational > policies that determine what endpoints should be posture assessed. Just end this definition at the end of the parenthetical expression, which also removes the need for the following "Identify Endpoint Targets" definition. Classification is for both finding the appropriate content for an endpoint and for finding which endpoints content applies to. Examples for both uses could be simply stated, if necessary. > > Identify Endpoint Targets (slight modifications): To identify what > potential endpoint targets the checklist should apply to based on > evaluating organizational policies against known endpoint attributes.] > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From david.waltermire@nist.gov Wed Feb 5 11:24:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978CF1A00EB for ; Wed, 5 Feb 2014 11:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66K0NnycM48j for ; Wed, 5 Feb 2014 11:24:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3D1A00FA for ; Wed, 5 Feb 2014 11:24:51 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 19:24:48 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 19:24:48 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , David Harrington , "sacm@ietf.org" Thread-Topic: QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting Thread-Index: Ac8ip4YavIuzj5GPS3G7cT9B5maaAQ== Date: Wed, 5 Feb 2014 19:24:47 +0000 Message-ID: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(479174003)(377454003)(51704005)(13464003)(189002)(199002)(53806001)(54356001)(85306002)(2656002)(81686001)(92566001)(76482001)(90146001)(94946001)(54316002)(46102001)(47736001)(94316002)(65816001)(74876001)(4396001)(93516002)(87266001)(77982001)(51856001)(83072002)(81816001)(85852003)(56776001)(93136001)(86362001)(59766001)(63696002)(79102001)(95416001)(80022001)(56816005)(74706001)(66066001)(87936001)(74502001)(47446002)(49866001)(80976001)(33646001)(81342001)(31966008)(74662001)(47976001)(50986001)(74316001)(19580395003)(83322001)(19580405001)(77096001)(76176001)(76576001)(81542001)(69226001)(76796001)(74366001)(76786001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EEECC228.A4F25F5A.71DFB76F.CAECD9A1.20415; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 19:24:54 -0000 Gunnar, I'm changing the subject and trimming the thread to focus on the single poi= nt of discussion. Please find my feedback on your comment below. Dave > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach > Sent: Wednesday, February 05, 2014 1:42 PM > To: Waltermire, David A.; David Harrington; sacm@ietf.org > Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 >=20 >=20 > All of this looks good to me, with one additional comment near the bottom= ... >=20 >=20 > --gun >=20 >=20 > On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > > > > 4) in 2.1.2, > > > > Endpoint Discovery: The purpose of discovery is to determine the > > type of endpoint to be posture assessed. > > > > QUESTION: Is it just the type? Or is it to identify what > > endpoint instances to target for assessment using metadata > > such > > > > as the endpoint's organizationally expected type (e.g., > > > > expected function/role, etc.) > > > > If this is truly endpoint "discovery", then I think this building > > block discovers the whole set of endpoints it can see in the network - > > i.e., the whole set of endpoints that might be able to be assessed. > > > > In the next step (targeting), that building block selects a subset of > > the discovered set of endpoints, based on such things as type of > > endpoint, organizationally expected function/role, version, etc. > > > > [DAW: The discussion on the call resulted in the identification of two > > distinct concepts, Endpoint Discovery and Endpoint Characterization, > > that are needed to support the identification of what endpoints should > > be targeted for an assessment. Both of these concepts have been > > combined in the current "Endpoint Discovery" building block. There was > > agreement that these two aspects should be broken out into distinct > > building block items. I took the action to propose some new text. > > Please let us know if you have any objections or suggested changes to > > the following proposed > > change: > > > > Endpoint Discovery: To determine the current or historic presence of > > endpoints in the environment that are available for posture assessment. > > > > Endpoint Characterization: The act of acquiring, through automated > > collection or manual input, and organizing attributes associated with > > an endpoint (e.g., type, organizationally expected function/role, > > hardware/software versions) that can be used to evaluate > > organizational policies that determine what endpoints should be posture > assessed. >=20 >=20 > Just end this definition at the end of the parenthetical expression, whic= h also > removes the need for the following "Identify Endpoint Targets" definition= . >=20 > Classification is for both finding the appropriate content for an endpoin= t and > for finding which endpoints content applies to. Examples for both uses c= ould > be simply stated, if necessary. >=20 I am fine with dropping the text "that can be used to evaluate organization= al policies that determine what endpoints should be posture assessed", sinc= e this is somewhat redundant with the modified text under "Identify Endpoin= t Targets". The existing text in (-05) includes a definition for "Identify Endpoint Tar= gets". I modified the existing text to tie together the classification and = targeting concepts. IMHO this addresses finding which endpoints content app= lies to. The text under "Collection Content Acquisition" and "Evaluation Co= ntent Acquisition" addresses finding the appropriate content for an endpoin= t for collection and evaluation. To be more clear about what the change to "Identify Endpoint Targets" entai= ls, here is the original text: Identify Endpoint Targets: To identify what potential endpoint targets the checklist should apply to based on organizational policies. The new text adds the text in brackets: Identify Endpoint Targets: To identify what potential endpoint targets the checklist should apply to based on [evaluating] organi= zational policies [against known endpoint attributes]. Based on this discussion the complete text might be modified to: Endpoint Discovery: To determine the current or historic presence of endpoints in the environment that are available for posture assess= ment. Endpoint Characterization: The act of acquiring, through automated collection or manual input, and organizing attributes associated w= ith an endpoint (e.g., type, organizationally expected function/role, hardware/software versions). Identify Endpoint Targets: To identify what potential endpoint targets the checklist should apply to based on evaluating organiza= tional policies against known endpoint attributes. How about this? From gunnar.engelbach@threatguard.com Wed Feb 5 12:02:43 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8969A1A00E2 for ; Wed, 5 Feb 2014 12:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKGfM4_-NtqA for ; Wed, 5 Feb 2014 12:02:39 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id E028E1A0197 for ; Wed, 5 Feb 2014 12:02:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=EdVmbxh+FdcwwfZJ+3DNgfxlBSEq1BugMqnPMCl39MydUcx45NJmVqQo6Pl84tN7+IaXBrqTRTsShcI6QUb8TKVXGussB174C70AjSmghBpu7HGqFio01lRks1FP+KGD; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 16269 invoked from network); 5 Feb 2014 12:09:05 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 12:09:04 -0800 Message-ID: <52F298EC.6080101@ThreatGuard.com> Date: Wed, 05 Feb 2014 15:02:52 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Waltermire, David A." , David Harrington , "sacm@ietf.org" References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:02:43 -0000 With that change to "Endpoint Characterization" I find "Identify Endpoint Targets" to be redundant. However, if "Identify Endpoint Targets" is kept, I'd suggest dropping the clause "...based on evaluating organizational policies against known endpoint attributes." That makes a restrictive assumption about how it can be used. On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > Gunnar, > > I'm changing the subject and trimming the thread to focus on the single point of discussion. > > Please find my feedback on your comment below. > > Dave > >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach >> Sent: Wednesday, February 05, 2014 1:42 PM >> To: Waltermire, David A.; David Harrington; sacm@ietf.org >> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 >> >> >> All of this looks good to me, with one additional comment near the bottom... >> >> >> --gun >> >> >> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: >>> >>> 4) in 2.1.2, >>> >>> Endpoint Discovery: The purpose of discovery is to determine the >>> type of endpoint to be posture assessed. >>> >>> QUESTION: Is it just the type? Or is it to identify what >>> endpoint instances to target for assessment using metadata >>> such >>> >>> as the endpoint's organizationally expected type (e.g., >>> >>> expected function/role, etc.) >>> >>> If this is truly endpoint "discovery", then I think this building >>> block discovers the whole set of endpoints it can see in the network - >>> i.e., the whole set of endpoints that might be able to be assessed. >>> >>> In the next step (targeting), that building block selects a subset of >>> the discovered set of endpoints, based on such things as type of >>> endpoint, organizationally expected function/role, version, etc. >>> >>> [DAW: The discussion on the call resulted in the identification of two >>> distinct concepts, Endpoint Discovery and Endpoint Characterization, >>> that are needed to support the identification of what endpoints should >>> be targeted for an assessment. Both of these concepts have been >>> combined in the current "Endpoint Discovery" building block. There was >>> agreement that these two aspects should be broken out into distinct >>> building block items. I took the action to propose some new text. >>> Please let us know if you have any objections or suggested changes to >>> the following proposed >>> change: >>> >>> Endpoint Discovery: To determine the current or historic presence of >>> endpoints in the environment that are available for posture assessment. >>> >>> Endpoint Characterization: The act of acquiring, through automated >>> collection or manual input, and organizing attributes associated with >>> an endpoint (e.g., type, organizationally expected function/role, >>> hardware/software versions) that can be used to evaluate >>> organizational policies that determine what endpoints should be posture >> assessed. >> >> >> Just end this definition at the end of the parenthetical expression, which also >> removes the need for the following "Identify Endpoint Targets" definition. >> >> Classification is for both finding the appropriate content for an endpoint and >> for finding which endpoints content applies to. Examples for both uses could >> be simply stated, if necessary. >> > > I am fine with dropping the text "that can be used to evaluate organizational policies that determine what endpoints should be posture assessed", since this is somewhat redundant with the modified text under "Identify Endpoint Targets". > > The existing text in (-05) includes a definition for "Identify Endpoint Targets". I modified the existing text to tie together the classification and targeting concepts. IMHO this addresses finding which endpoints content applies to. The text under "Collection Content Acquisition" and "Evaluation Content Acquisition" addresses finding the appropriate content for an endpoint for collection and evaluation. > > To be more clear about what the change to "Identify Endpoint Targets" entails, here is the original text: > > Identify Endpoint Targets: To identify what potential endpoint > targets the checklist should apply to based on organizational > policies. > > The new text adds the text in brackets: > > Identify Endpoint Targets: To identify what potential endpoint > targets the checklist should apply to based on [evaluating] organizational > policies [against known endpoint attributes]. > > Based on this discussion the complete text might be modified to: > > Endpoint Discovery: To determine the current or historic presence of > endpoints in the environment that are available for posture assessment. > > Endpoint Characterization: The act of acquiring, through automated > collection or manual input, and organizing attributes associated with > an endpoint (e.g., type, organizationally expected function/role, > hardware/software versions). > > Identify Endpoint Targets: To identify what potential endpoint > targets the checklist should apply to based on evaluating organizational > policies against known endpoint attributes. > > How about this? > From david.waltermire@nist.gov Wed Feb 5 12:12:07 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4191A0192 for ; Wed, 5 Feb 2014 12:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7RUXo2g4zl6 for ; Wed, 5 Feb 2014 12:12:04 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBA11A0124 for ; Wed, 5 Feb 2014 12:12:01 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 20:11:54 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 20:11:53 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , David Harrington , "sacm@ietf.org" Thread-Topic: QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting Thread-Index: Ac8ip4YavIuzj5GPS3G7cT9B5maaAQABbooAAAAq3iA= Date: Wed, 5 Feb 2014 20:11:53 +0000 Message-ID: <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> In-Reply-To: <52F298EC.6080101@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(51704005)(479174003)(377454003)(199002)(189002)(13464003)(81816001)(56816005)(85852003)(63696002)(83072002)(94946001)(65816001)(74876001)(93516002)(54356001)(93136001)(74706001)(92566001)(59766001)(66066001)(46102001)(51856001)(53806001)(54316002)(76482001)(56776001)(77982001)(81686001)(4396001)(79102001)(94316002)(86362001)(47446002)(80022001)(87266001)(2656002)(85306002)(87936001)(90146001)(80976001)(74502001)(76786001)(81542001)(81342001)(19580405001)(47736001)(19580395003)(31966008)(50986001)(49866001)(33646001)(83322001)(47976001)(69226001)(76796001)(76576001)(74662001)(77096001)(74316001)(74366001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EEACC228.A6E25F5A.71EFB76B.CAECD961.2046F; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:12:08 -0000 I don't find the text to be restrictive since any set of endpoint attribute= s can be used (including aspects of posture). If we kept the text, what wou= ld not be supported for targeting? Dave > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Wednesday, February 05, 2014 3:03 PM > To: Waltermire, David A.; David Harrington; sacm@ietf.org > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > Discovery/Characterization/Targeting >=20 >=20 >=20 > With that change to "Endpoint Characterization" I find "Identify Endpoint > Targets" to be redundant. >=20 > However, if "Identify Endpoint Targets" is kept, I'd suggest dropping the > clause >=20 > "...based on evaluating organizational policies against known endpoint > attributes." >=20 > That makes a restrictive assumption about how it can be used. >=20 >=20 >=20 >=20 > On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > > Gunnar, > > > > I'm changing the subject and trimming the thread to focus on the single > point of discussion. > > > > Please find my feedback on your comment below. > > > > Dave > > > >> -----Original Message----- > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > >> Engelbach > >> Sent: Wednesday, February 05, 2014 1:42 PM > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org > >> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 > >> > >> > >> All of this looks good to me, with one additional comment near the > bottom... > >> > >> > >> --gun > >> > >> > >> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > >>> > >>> 4) in 2.1.2, > >>> > >>> Endpoint Discovery: The purpose of discovery is to determine the > >>> type of endpoint to be posture assessed. > >>> > >>> QUESTION: Is it just the type? Or is it to identify what > >>> endpoint instances to target for assessment using > >>> metadata such > >>> > >>> as the endpoint's organizationally expected type (e.g., > >>> > >>> expected function/role, etc.) > >>> > >>> If this is truly endpoint "discovery", then I think this building > >>> block discovers the whole set of endpoints it can see in the network > >>> - i.e., the whole set of endpoints that might be able to be assessed. > >>> > >>> In the next step (targeting), that building block selects a subset > >>> of the discovered set of endpoints, based on such things as type of > >>> endpoint, organizationally expected function/role, version, etc. > >>> > >>> [DAW: The discussion on the call resulted in the identification of > >>> two distinct concepts, Endpoint Discovery and Endpoint > >>> Characterization, that are needed to support the identification of > >>> what endpoints should be targeted for an assessment. Both of these > >>> concepts have been combined in the current "Endpoint Discovery" > >>> building block. There was agreement that these two aspects should be > >>> broken out into distinct building block items. I took the action to p= ropose > some new text. > >>> Please let us know if you have any objections or suggested changes > >>> to the following proposed > >>> change: > >>> > >>> Endpoint Discovery: To determine the current or historic presence of > >>> endpoints in the environment that are available for posture assessmen= t. > >>> > >>> Endpoint Characterization: The act of acquiring, through automated > >>> collection or manual input, and organizing attributes associated > >>> with an endpoint (e.g., type, organizationally expected > >>> function/role, hardware/software versions) that can be used to > >>> evaluate organizational policies that determine what endpoints > >>> should be posture > >> assessed. > >> > >> > >> Just end this definition at the end of the parenthetical expression, > >> which also removes the need for the following "Identify Endpoint > Targets" definition. > >> > >> Classification is for both finding the appropriate content for an > >> endpoint and for finding which endpoints content applies to. > >> Examples for both uses could be simply stated, if necessary. > >> > > > > I am fine with dropping the text "that can be used to evaluate > organizational policies that determine what endpoints should be posture > assessed", since this is somewhat redundant with the modified text under > "Identify Endpoint Targets". > > > > The existing text in (-05) includes a definition for "Identify Endpoint > Targets". I modified the existing text to tie together the classification= and > targeting concepts. IMHO this addresses finding which endpoints content > applies to. The text under "Collection Content Acquisition" and "Evaluati= on > Content Acquisition" addresses finding the appropriate content for an > endpoint for collection and evaluation. > > > > To be more clear about what the change to "Identify Endpoint Targets" > entails, here is the original text: > > > > Identify Endpoint Targets: To identify what potential endpoint > > targets the checklist should apply to based on organizational > > policies. > > > > The new text adds the text in brackets: > > > > Identify Endpoint Targets: To identify what potential endpoint > > targets the checklist should apply to based on [evaluating] > organizational > > policies [against known endpoint attributes]. > > > > Based on this discussion the complete text might be modified to: > > > > Endpoint Discovery: To determine the current or historic presence of > > endpoints in the environment that are available for posture > assessment. > > > > Endpoint Characterization: The act of acquiring, through automated > > collection or manual input, and organizing attributes associa= ted with > > an endpoint (e.g., type, organizationally expected function/r= ole, > > hardware/software versions). > > > > Identify Endpoint Targets: To identify what potential endpoint > > targets the checklist should apply to based on evaluating > organizational > > policies against known endpoint attributes. > > > > How about this? > > From david.waltermire@nist.gov Wed Feb 5 12:37:41 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A511A01D1 for ; Wed, 5 Feb 2014 12:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWHrh9Bf74Md for ; Wed, 5 Feb 2014 12:37:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id CEEC21A01CC for ; Wed, 5 Feb 2014 12:37:37 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 20:37:35 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 20:37:35 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKw== Date: Wed, 5 Feb 2014 20:37:34 +0000 Message-ID: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(57704003)(164054003)(94316002)(2656002)(87936001)(93136001)(54316002)(33646001)(69226001)(74706001)(81816001)(81686001)(87266001)(74316001)(47446002)(80976001)(80022001)(31966008)(85852003)(74502001)(56776001)(81342001)(86362001)(94946001)(81542001)(19580395003)(92566001)(74662001)(83322001)(93516002)(83072002)(19300405004)(66066001)(76576001)(65816001)(74876001)(76176001)(46102001)(16236675002)(4396001)(15202345003)(51856001)(76796001)(77096001)(76786001)(59766001)(77982001)(74366001)(79102001)(85306002)(56816005)(76482001)(49866001)(90146001)(50986001)(47976001)(47736001)(19609705001)(63696002)(53806001)(15975445006)(54356001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:ACFCF6D4.8FD20351.1DC9DBB.4AE1F1F1.2030A; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_69135153be4642ad825a32c45fa3b439BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:37:41 -0000 --_000_69135153be4642ad825a32c45fa3b439BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm working through the UC draft addressing discussion items from yesterday= and the previous comments we have received on the list on -05. Related to section 2.1.1, we have had many previous discussions around the = notional idea of content. There has been general agreement that we need to = be more specific. Please find below an attempt to put some "bounds" around = different types of content. Is this hitting the mark, or do we need to say something more/different? The following is a snippet from a possible update to section 2.1.1 with som= e additional description: I'd appreciate any thoughts, concerns, objections before I include the chan= ges in the draft. Thanks, Dave 2.1.1. Define, Publish, Query and Retrieve Content This use case describes the need for content to be defined and published to a data store, as well as queried and retrieved from the data store for the explicit use of posture collection and evaluation. The term "content" is a general concept that refers to any data expression that may be used as part of the process of collecting and evaluating endpoint posture. Typical types of content include: o Dictionaries of posture attributes (e.g. software installation, configuration, privileges) that may be collected from a given endpoint type that relate to installed hardware, installed software, software configurations, accounts, privileges, and other operational state. o Expressions that provide instructions for using a specific API, management protocol, or other mechanisms to collect specific posture attributes from specific device types. o Policies that define the selected posture attributes for which values must be collected to support one or more posture assessments. This may include information that targets collection to a specific set of endpoints and instructions on the frequency and/or change events (e.g., configuration changes, software installation/uninstallation, account/privilege modifications) that will trigger collection of one or more posture attributes. o Policies that define the logical criteria to evaluate collected posture attribute values to determine if they meet organizational requirements. This may include information that targets evaluation to a specific set of endpoints. --_000_69135153be4642ad825a32c45fa3b439BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m working through the UC draft addressing discussi= on items from yesterday and the previous comments we have received on the l= ist on -05.

 

Related to section 2.1.1, we have had many previous discus= sions around the notional idea of content. There has been general agreement= that we need to be more specific. Please find below an attempt to put some “bounds” around different types o= f content.

 

Is this hitting the mark, or do we need to say something m= ore/different?

 

The following is a snippet from a possible update to secti= on 2.1.1 with some additional description:

 

I’d appreciate any thoughts, concerns, objections be= fore I include the changes in the draft.

 

Thanks,

Dave

 

2.1.1.  Define, Publish, Query and Retrieve Content

 

   This use case describes the need for content = to be defined and

   published to a data store, as well as queried= and retrieved from the

   data store for the explicit use of posture co= llection and evaluation.

 

   The term "content" is a general con= cept that refers to any data

   expression that may be used as part of the pr= ocess of collecting and

   evaluating endpoint posture.  Typical ty= pes of content include:

 

   o  Dictionaries of posture attributes (e= .g. software installation,

      configuration, privileges) = that may be collected from a given

      endpoint type that relate t= o installed hardware, installed

      software, software configur= ations, accounts, privileges, and other

      operational state.

 

   o  Expressions that provide instructions= for using a specific API,

      management protocol, or oth= er mechanisms to collect specific

      posture attributes from spe= cific device types.

 

   o  Policies that define the selected pos= ture attributes for which

      values must be collected to= support one or more posture

      assessments.  This may= include information that targets collection

      to a specific set of endpoi= nts and instructions on the frequency

      and/or change events (e.g.,= configuration changes, software

      installation/uninstallation= , account/privilege modifications) that

      will trigger collection of = one or more posture attributes.

 

   o  Policies that define the logical crit= eria to evaluate collected

      posture attribute values to= determine if they meet organizational

      requirements.  This ma= y include information that targets

      evaluation to a specific se= t of endpoints.

 

--_000_69135153be4642ad825a32c45fa3b439BLUPR09MB038namprd09pro_-- From blueroofmusic@gmail.com Wed Feb 5 14:00:26 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7FE1A0234 for ; Wed, 5 Feb 2014 14:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuBeXfl0HOl9 for ; Wed, 5 Feb 2014 14:00:23 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 47E501A012F for ; Wed, 5 Feb 2014 14:00:23 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id j1so4507493iga.2 for ; Wed, 05 Feb 2014 14:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3gW0RBI7J0qagbENQd2u1gWW9IbxpH4sVUGSj2svmdE=; b=wwhq/T0EdATcSZ03X/o79t3LK2fHCqY38NjDc7h0BKsD0t/6ebpu6j4l41SZ+IduL5 EaZt2/rlLDW+VJbDeMXeinNAmBO9odegzm6AmAiirfK02uYfviarpwDW4VsuTa1tRRfz WRqk1yQslloefHrzthL2OaZJe5mEb5R5Ub8xbtd1WRPiDSgkN2FeIwoSPlMBXMyXiaEn /Wv51xCPHqEiXTw/w5JVjwGd4PP4BcYBKjnrj/GamGciYncw+5Nc5VoLkbwlxNgYi99j MTDFwUkWSoH6bQYtEc2N2SxJTEMeX2pJPXPsBlEnliDufpjOMcxathQFpniQjpHmPfFe ophQ== X-Received: by 10.50.30.234 with SMTP id v10mr4437800igh.23.1391637622226; Wed, 05 Feb 2014 14:00:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Wed, 5 Feb 2014 13:59:06 -0800 (PST) In-Reply-To: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> From: Ira McDonald Date: Wed, 5 Feb 2014 16:59:06 -0500 Message-ID: To: "Waltermire, David A." , Ira McDonald Content-Type: multipart/alternative; boundary=047d7bdc08aa21070704f1afe22a Cc: "sacm@ietf.org" Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:00:26 -0000 --047d7bdc08aa21070704f1afe22a Content-Type: text/plain; charset=ISO-8859-1 Hi Dave, Sorry I couldn't join the SACM teleconference yesterday (stuck in an IEEE call). I would be much happier if SACM documents used a term like "SA content" for what you defined below. Using lowercase naked "content" is going to translate very poorly across other natural languages and become confusing to native English speakers (who don't happen to be SACM geeks). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Feb 5, 2014 at 3:37 PM, Waltermire, David A. < david.waltermire@nist.gov> wrote: > I'm working through the UC draft addressing discussion items from > yesterday and the previous comments we have received on the list on -05. > > > > Related to section 2.1.1, we have had many previous discussions around the > notional idea of content. There has been general agreement that we need to > be more specific. Please find below an attempt to put some "bounds" around > different types of content. > > > > Is this hitting the mark, or do we need to say something more/different? > > > > The following is a snippet from a possible update to section 2.1.1 with > some additional description: > > > > I'd appreciate any thoughts, concerns, objections before I include the > changes in the draft. > > > > Thanks, > > Dave > > > > 2.1.1. Define, Publish, Query and Retrieve Content > > > > This use case describes the need for content to be defined and > > published to a data store, as well as queried and retrieved from the > > data store for the explicit use of posture collection and evaluation. > > > > The term "content" is a general concept that refers to any data > > expression that may be used as part of the process of collecting and > > evaluating endpoint posture. Typical types of content include: > > > > o Dictionaries of posture attributes (e.g. software installation, > > configuration, privileges) that may be collected from a given > > endpoint type that relate to installed hardware, installed > > software, software configurations, accounts, privileges, and other > > operational state. > > > > o Expressions that provide instructions for using a specific API, > > management protocol, or other mechanisms to collect specific > > posture attributes from specific device types. > > > > o Policies that define the selected posture attributes for which > > values must be collected to support one or more posture > > assessments. This may include information that targets collection > > to a specific set of endpoints and instructions on the frequency > > and/or change events (e.g., configuration changes, software > > installation/uninstallation, account/privilege modifications) that > > will trigger collection of one or more posture attributes. > > > > o Policies that define the logical criteria to evaluate collected > > posture attribute values to determine if they meet organizational > > requirements. This may include information that targets > > evaluation to a specific set of endpoints. > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > --047d7bdc08aa21070704f1afe22a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Sorry = I couldn't join the SACM teleconference yesterday (stuck in an IEEE cal= l).

I would be much happier if SACM documents used a term like= "SA content"
for what you defined below. 

Using lowercase naked "= ;content" is going to translate very poorly across other
natural l= anguages and become confusing to native English speakers (who don't
happen to be SACM geeks).

Cheers,
- Ira

Ira McDonald (Musician / Software Arc= hitect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Fo= undation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094=
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434=

<= /div>


On Wed, Feb 5, 2014 at 3:37 PM, Waltermi= re, David A. <david.waltermire@nist.gov> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I’m working through the UC draft addressing discussi= on items from yesterday and the previous comments we have received on the l= ist on -05.

 

Related to section 2.1.1, we have had many previous discus= sions around the notional idea of content. There has been general agreement= that we need to be more specific. Please find below an attempt to put some “bounds” around different types o= f content.

 

Is this hitting the mark, or do we need to say something m= ore/different?

 

The following is a snippet from a possible update to secti= on 2.1.1 with some additional description:

 

I’d appreciate any thoughts, concerns, objections be= fore I include the changes in the draft.

 

Thanks,

Dave

 

2.1.1.  Define, Publish, Query and Retrieve Content

 

   This use case describes the need for content = to be defined and

   published to a data store, as well as queried= and retrieved from the

   data store for the explicit use of posture co= llection and evaluation.

 

   The term "content" is a general con= cept that refers to any data

   expression that may be used as part of the pr= ocess of collecting and

   evaluating endpoint posture.  Typical ty= pes of content include:

 

   o  Dictionaries of posture attributes (e= .g. software installation,

      configuration, privileges) = that may be collected from a given

      endpoint type that relate t= o installed hardware, installed

      software, software configur= ations, accounts, privileges, and other

      operational state.

 

   o  Expressions that provide instructions= for using a specific API,

      management protocol, or oth= er mechanisms to collect specific

      posture attributes from spe= cific device types.

 

   o  Policies that define the selected pos= ture attributes for which

      values must be collected to= support one or more posture

      assessments.  This may= include information that targets collection

      to a specific set of endpoi= nts and instructions on the frequency

      and/or change events (e.g.,= configuration changes, software

      installation/uninstallation= , account/privilege modifications) that

      will trigger collection of = one or more posture attributes.

 

   o  Policies that define the logical crit= eria to evaluate collected

      posture attribute values to= determine if they meet organizational

      requirements.  This ma= y include information that targets

      evaluation to a specific se= t of endpoints.

 


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


--047d7bdc08aa21070704f1afe22a-- From pkampana@cisco.com Wed Feb 5 14:25:01 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1494E1A0255 for ; Wed, 5 Feb 2014 14:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJlOhjDbtfv5 for ; Wed, 5 Feb 2014 14:24:58 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0254C1A0254 for ; Wed, 5 Feb 2014 14:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14530; q=dns/txt; s=iport; t=1391639097; x=1392848697; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/NsShuPPlUPCvp6Au2GwL8vV+fZCTTkxSDxCpuDvcJM=; b=P1pXVfJ4w6/PSrvzvzbC3HfeQRsV3lfsfRotB8FjerJq8Wa2WVWS8w32 AlR01aMbNtqYaXzcOCndZfxN6/8TSPwNQivLMJC76/d9Vvvcr9etoaord QYZUNJVD7TV6iv1GhQw95KpJbxFPdhl8Gna8OsSmo2s9E/GeAiPZ+VNAD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAJa58lKtJV2Z/2dsb2JhbABZgkhEOFe+W4ERFnSCJQEBAQQtXAIBCBEEAQELCxIHMhQJCAEBBAESCId9znIXjkQ3AQqDGoEUBKpMgy2CKg X-IronPort-AV: E=Sophos;i="4.95,789,1384300800"; d="scan'208,217";a="18298325" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 05 Feb 2014 22:24:56 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s15MOu5s014274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 22:24:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 16:24:56 -0600 From: "Panos Kampanakis (pkampana)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6w Date: Wed, 5 Feb 2014 22:24:55 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.3] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FAC73D9xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:25:01 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FAC73D9xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like a good summary of what "content" could mean. Panos From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, February 05, 2014 10:38 PM To: sacm@ietf.org Subject: [sacm] Types of content I'm working through the UC draft addressing discussion items from yesterday= and the previous comments we have received on the list on -05. Related to section 2.1.1, we have had many previous discussions around the = notional idea of content. There has been general agreement that we need to = be more specific. Please find below an attempt to put some "bounds" around = different types of content. Is this hitting the mark, or do we need to say something more/different? The following is a snippet from a possible update to section 2.1.1 with som= e additional description: I'd appreciate any thoughts, concerns, objections before I include the chan= ges in the draft. Thanks, Dave 2.1.1. Define, Publish, Query and Retrieve Content This use case describes the need for content to be defined and published to a data store, as well as queried and retrieved from the data store for the explicit use of posture collection and evaluation. The term "content" is a general concept that refers to any data expression that may be used as part of the process of collecting and evaluating endpoint posture. Typical types of content include: o Dictionaries of posture attributes (e.g. software installation, configuration, privileges) that may be collected from a given endpoint type that relate to installed hardware, installed software, software configurations, accounts, privileges, and other operational state. o Expressions that provide instructions for using a specific API, management protocol, or other mechanisms to collect specific posture attributes from specific device types. o Policies that define the selected posture attributes for which values must be collected to support one or more posture assessments. This may include information that targets collection to a specific set of endpoints and instructions on the frequency and/or change events (e.g., configuration changes, software installation/uninstallation, account/privilege modifications) that will trigger collection of one or more posture attributes. o Policies that define the logical criteria to evaluate collected posture attribute values to determine if they meet organizational requirements. This may include information that targets evaluation to a specific set of endpoints. --_000_1C9F17D1873AFA47A969C4DD98F98A750FAC73D9xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds like a good sum= mary of what “content” could mean.

Panos

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Wednesday, February 05, 2014 10:38 PM
To: sacm@ietf.org
Subject: [sacm] Types of content

 

I’m working through the UC draft addressing discussi= on items from yesterday and the previous comments we have received on the l= ist on -05.

 

Related to section 2.1.1, we have had many previous discus= sions around the notional idea of content. There has been general agreement= that we need to be more specific. Please find below an attempt to put some “bounds” around different types o= f content.

 

Is this hitting the mark, or do we need to say something m= ore/different?

 

The following is a snippet from a possible update to secti= on 2.1.1 with some additional description:

 

I’d appreciate any thoughts, concerns, objections be= fore I include the changes in the draft.

 

Thanks,

Dave

 

2.1.1.  Define, Publish, Query and Retrieve Content

 

   This use case describes the need for content = to be defined and

   published to a data store, as well as queried= and retrieved from the

   data store for the explicit use of posture co= llection and evaluation.

 

   The term "content" is a general con= cept that refers to any data

   expression that may be used as part of the pr= ocess of collecting and

   evaluating endpoint posture.  Typical ty= pes of content include:

 

   o  Dictionaries of posture attributes (e= .g. software installation,

      configuration, privileges) = that may be collected from a given

      endpoint type that relate t= o installed hardware, installed

      software, software configur= ations, accounts, privileges, and other

      operational state.

 

   o  Expressions that provide instructions= for using a specific API,

      management protocol, or oth= er mechanisms to collect specific

      posture attributes from spe= cific device types.

 

   o  Policies that define the selected pos= ture attributes for which

      values must be collected to= support one or more posture

      assessments.  This may= include information that targets collection

      to a specific set of endpoi= nts and instructions on the frequency

      and/or change events (e.g.,= configuration changes, software

      installation/uninstallation= , account/privilege modifications) that

      will trigger collection of = one or more posture attributes.

 

   o  Policies that define the logical crit= eria to evaluate collected

      posture attribute values to= determine if they meet organizational

      requirements.  This ma= y include information that targets

      evaluation to a specific se= t of endpoints.

 

--_000_1C9F17D1873AFA47A969C4DD98F98A750FAC73D9xmbrcdx10ciscoc_-- From gunnar.engelbach@threatguard.com Wed Feb 5 14:59:47 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1567F1A016B for ; Wed, 5 Feb 2014 14:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXG6bK6n-g3G for ; Wed, 5 Feb 2014 14:59:45 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id C3D7F1A022A for ; Wed, 5 Feb 2014 14:59:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=ThAtfsqs/ZNZBOvYeJJuERj8CINM4GrYCdx4wtSMLer1JfuRamwlyyb0Y4PErbz6ZPHnGUPw/ctMjP5J9z4uYbGSBgT6IvRUvx8rtu73yW5LZAjfECqt7eyUGscPrphX; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 20116 invoked from network); 5 Feb 2014 15:06:10 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 15:06:10 -0800 Message-ID: <52F2C26E.3040005@ThreatGuard.com> Date: Wed, 05 Feb 2014 17:59:58 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: David Harrington , sacm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Waltermire Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 - Attribute Acquisition X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:59:47 -0000 Reducing DH's original message to another single item: On 2/2/2014 2:20 PM, David Harrington wrote: > Hi, > > 2) in 2.0, > > QUESTION: It was suggested that mentioning several common > acquisition methods, such as local API, WMI, Puppet, DCOM, > SNMP, CMDB query, and NEA, without forcing any specific > method would be good. I have concerns this could devolve > into a "what about my favorite?" contest. OTOH, the > charter does specifically call for use of existing > standards where applicable, so the use cases document > might be a good neutral location for such information, and > might force us to consider what types of external > interfaces we might need to support when we consider the > requirements. It appears that the generic workflow > sequence would be a good place to mention such common > acquisition methods. > > > Consensus seems to be that this would be rathole to be avoided. We could > recommend the use of standardized data models/information models, but > this really is a runtime/operational decision. I think we simply need to > make sure the requirements recognize that any standardized process must > be able to support either standardized or proprietary (or mixed) sets of > attributes. I recommend we change the text to the following (or put a > similar statement in the requirements draft). > > A. The application determines which (sets of) posture attributes > need to be collected for evaluation. Implementations SHOULD be able to support (possibly mixed) sets of standardized and proprietary attributes. > > Apologies first if I've completely missed something. I haven't been in a position to keep up with all SACM activity, but I haven't yet seen any differentiation between acquisition methods and the communication of the request/response withing SACM data flows. If the data flows allow for the communication of a multitude of existing standards I think that would be counterproductive. If SACM dataflows are just wrappers for a wide variety of existing/emerging standards, that puts a tremendous burden on every node to be able to understand each potential payload. The payloads of SACM data flows should follow a single rigid pattern -- extensible in the sense that new data items can be requested/returned without needing software changes. But collection can still occur via any appropriate mechanism as long as there is a collector that can do the translation. And this would be self-selecting. A particular collect implementation could be, for example, a SACM front-end for SNMP and would respond as the proxy for all legacy routers on the network in the same manner that a CMDB would. From shanna@juniper.net Wed Feb 5 15:10:51 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20E11A02B9 for ; Wed, 5 Feb 2014 15:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lPfWf5JAK5p for ; Wed, 5 Feb 2014 15:10:42 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 752BC1A02BA for ; Wed, 5 Feb 2014 15:10:36 -0800 (PST) Received: from mail199-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.22; Wed, 5 Feb 2014 23:10:35 +0000 Received: from mail199-co1 (localhost [127.0.0.1]) by mail199-co1-R.bigfish.com (Postfix) with ESMTP id A9068840121; Wed, 5 Feb 2014 23:10:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic85fh4015I168aJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h9a9j1155h) Received-SPF: pass (mail199-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(377454003)(189002)(164054003)(199002)(57704003)(31966008)(76482001)(47446002)(66066001)(18717965001)(80022001)(65816001)(33646001)(76576001)(63696002)(74316001)(79102001)(56816005)(46102001)(81816001)(15975445006)(85852003)(77982001)(81686001)(56776001)(83072002)(74502001)(74662001)(74366001)(15202345003)(54316002)(19609705001)(94316002)(94946001)(93516002)(2656002)(74706001)(74876001)(87266001)(47736001)(80976001)(53806001)(50986001)(19300405004)(49866001)(90146001)(19580395003)(83322001)(19580405001)(16236675002)(81542001)(85306002)(93136001)(76796001)(69226001)(54356001)(92566001)(51856001)(76786001)(59766001)(86362001)(47976001)(81342001)(4396001)(87936001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB740; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:AC7CF6D0.8FF2C351.70D3BDBB.42D0F171.20411; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail199-co1 (localhost.localdomain [127.0.0.1]) by mail199-co1 (MessageSwitch) id 13916418334394_20567; Wed, 5 Feb 2014 23:10:33 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.234]) by mail199-co1.bigfish.com (Postfix) with ESMTP id F0C34A0004A; Wed, 5 Feb 2014 23:10:32 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 5 Feb 2014 23:10:32 +0000 Received: from BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Wed, 5 Feb 2014 23:10:31 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 23:10:29 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 23:10:29 +0000 From: Stephen Hanna To: "Panos Kampanakis (pkampana)" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTA= Date: Wed, 5 Feb 2014 23:10:28 +0000 Message-ID: <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 01136D2D90 Content-Type: multipart/alternative; boundary="_000_656401fabeb54cb1a205e9712bbe55f3BLUPR05MB737namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:10:52 -0000 --_000_656401fabeb54cb1a205e9712bbe55f3BLUPR05MB737namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would "dictionaries of posture attributes" include attribute values that ha= ve been collected from endpoints? We want to have the ability to collect attribute values from endpoints and = "persist" them, as described in section 2.1.3. So we'll need to have a repo= sitory for collected and persisted attribute values. If collected endpoint attribute values are considered content, let's say so= . If not, let's say that explicitly. My personal view is that collected endpoint attribute values should be cons= idered content. They may be a different kind of content from the others due= to larger volume and higher change rate. For that reason, people may choos= e to put them into a different repository and maybe even use a different qu= ery protocol for that repository to munge the large quantities of data. But= they're still content. Thanks, Steve From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Panos Kampanakis (pk= ampana) Sent: Wednesday, February 05, 2014 5:25 PM To: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] Types of content Sounds like a good summary of what "content" could mean. Panos From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, February 05, 2014 10:38 PM To: sacm@ietf.org Subject: [sacm] Types of content I'm working through the UC draft addressing discussion items from yesterday= and the previous comments we have received on the list on -05. Related to section 2.1.1, we have had many previous discussions around the = notional idea of content. There has been general agreement that we need to = be more specific. Please find below an attempt to put some "bounds" around = different types of content. Is this hitting the mark, or do we need to say something more/different? The following is a snippet from a possible update to section 2.1.1 with som= e additional description: I'd appreciate any thoughts, concerns, objections before I include the chan= ges in the draft. Thanks, Dave 2.1.1. Define, Publish, Query and Retrieve Content This use case describes the need for content to be defined and published to a data store, as well as queried and retrieved from the data store for the explicit use of posture collection and evaluation. The term "content" is a general concept that refers to any data expression that may be used as part of the process of collecting and evaluating endpoint posture. Typical types of content include: o Dictionaries of posture attributes (e.g. software installation, configuration, privileges) that may be collected from a given endpoint type that relate to installed hardware, installed software, software configurations, accounts, privileges, and other operational state. o Expressions that provide instructions for using a specific API, management protocol, or other mechanisms to collect specific posture attributes from specific device types. o Policies that define the selected posture attributes for which values must be collected to support one or more posture assessments. This may include information that targets collection to a specific set of endpoints and instructions on the frequency and/or change events (e.g., configuration changes, software installation/uninstallation, account/privilege modifications) that will trigger collection of one or more posture attributes. o Policies that define the logical criteria to evaluate collected posture attribute values to determine if they meet organizational requirements. This may include information that targets evaluation to a specific set of endpoints. --_000_656401fabeb54cb1a205e9712bbe55f3BLUPR05MB737namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would “dictionar= ies of posture attributes” include attribute values that have been co= llected from endpoints?

 

We want to have the ab= ility to collect attribute values from endpoints and “persist” = them, as described in section 2.1.3. So we’ll need to have a reposito= ry for collected and persisted attribute values.

 

If collected endpoint = attribute values are considered content, let’s say so. If not, let= 217;s say that explicitly.

 

My personal view is th= at collected endpoint attribute values should be considered content. They m= ay be a different kind of content from the others due to larger volume and = higher change rate. For that reason, people may choose to put them into a different repository and maybe even u= se a different query protocol for that repository to munge the large quanti= ties of data. But they’re still content.

 

Thanks,

 

Steve

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, February 05, 2014 5:25 PM
To: Waltermire, David A.; sacm@ietf.org
Subject: Re: [sacm] Types of content

 

Sounds like a good sum= mary of what “content” could mean.

Panos

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Wednesday, February 05, 2014 10:38 PM
To: sacm@ietf.org
Subject: [sacm] Types of content

 

I’m working through the UC draft addressing discussi= on items from yesterday and the previous comments we have received on the l= ist on -05.

 

Related to section 2.1.1, we have had many previous discus= sions around the notional idea of content. There has been general agreement= that we need to be more specific. Please find below an attempt to put some “bounds” around different types o= f content.

 

Is this hitting the mark, or do we need to say something m= ore/different?

 

The following is a snippet from a possible update to secti= on 2.1.1 with some additional description:

 

I’d appreciate any thoughts, concerns, objections be= fore I include the changes in the draft.

 

Thanks,

Dave

 

2.1.1.  Define, Publish, Query and Retrieve Content

 

   This use case describes the need for content = to be defined and

   published to a data store, as well as queried= and retrieved from the

   data store for the explicit use of posture co= llection and evaluation.

 

   The term "content" is a general con= cept that refers to any data

   expression that may be used as part of the pr= ocess of collecting and

   evaluating endpoint posture.  Typical ty= pes of content include:

 

   o  Dictionaries of posture attributes (e= .g. software installation,

      configuration, privileges) = that may be collected from a given

      endpoint type that relate t= o installed hardware, installed

      software, software configur= ations, accounts, privileges, and other

      operational state.

 

   o  Expressions that provide instructions= for using a specific API,

      management protocol, or oth= er mechanisms to collect specific

      posture attributes from spe= cific device types.

 

   o  Policies that define the selected pos= ture attributes for which

      values must be collected to= support one or more posture

      assessments.  This may= include information that targets collection

      to a specific set of endpoi= nts and instructions on the frequency

      and/or change events (e.g.,= configuration changes, software

      installation/uninstallation= , account/privilege modifications) that

      will trigger collection of = one or more posture attributes.

 

   o  Policies that define the logical crit= eria to evaluate collected

      posture attribute values to= determine if they meet organizational

      requirements.  This ma= y include information that targets

      evaluation to a specific se= t of endpoints.

 

--_000_656401fabeb54cb1a205e9712bbe55f3BLUPR05MB737namprd05pro_-- From david.waltermire@nist.gov Wed Feb 5 15:33:17 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E76A1A0141 for ; Wed, 5 Feb 2014 15:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w1hcwJOfWcm for ; Wed, 5 Feb 2014 15:33:12 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id B27D31A0215 for ; Wed, 5 Feb 2014 15:33:10 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 23:33:09 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 23:33:08 +0000 From: "Waltermire, David A." To: Stephen Hanna , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIA== Date: Wed, 5 Feb 2014 23:33:08 +0000 Message-ID: References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> In-Reply-To: <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(164054003)(377454003)(57704003)(189002)(199002)(74316001)(47976001)(50986001)(15202345003)(19580405001)(83322001)(19580395003)(31966008)(81342001)(74662001)(19300405004)(69226001)(76786001)(74366001)(76796001)(77096001)(1941001)(76576001)(81542001)(94316002)(47736001)(4396001)(74502001)(65816001)(74876001)(85306002)(53806001)(54356001)(94946001)(90146001)(54316002)(76482001)(81686001)(2656002)(92566001)(46102001)(87936001)(47446002)(80976001)(49866001)(33646001)(83072002)(81816001)(85852003)(56776001)(51856001)(86362001)(59766001)(93136001)(77982001)(87266001)(15975445006)(93516002)(16236675002)(56816005)(74706001)(66066001)(63696002)(79102001)(19609705001)(80022001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:AE7CF6D4.8FF2C241.78D3BDBB.42D4F971.204E8; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_ea2bd950e01a41609585082fe70876ffBLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:33:17 -0000 --_000_ea2bd950e01a41609585082fe70876ffBLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dictionaries of posture attributes was not intended to include attribute va= lues. IETF examples of this concept might include attributes in a MIB or a = NETMOD model. I agree that we need to "persist" posture attribute values. I have always b= een on the fence personally about calling collection and evaluation results= "content". I agree 100% that we need to be crystal clear about what we mea= n when we use the terms "content" and "content repository". If we choose to= lump all of this together as "content", we will need to include some discu= ssion in the use case document contrasting different types of content to dr= ive discussion of content type-specific requirements. I also personally like Ira's feedback on using a more specific term(s) inst= ead of the more general "content". I also share the same personal view around interacting with stores of colle= cted posture attribute values and evaluation results. The larger data volum= es and rate of change will likely require different approaches. I also beli= eve that the temporal nature of this data, the need to persist historic inf= ormation, will be more significant than other types of data that we may cal= l "content". Are there other opinions on this? Does anyone feel strongly that collected = posture attribute values and evaluation results SHOULD NOT be considered co= ntent? Thanks, Dave From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, February 05, 2014 6:10 PM To: Panos Kampanakis (pkampana); Waltermire, David A.; sacm@ietf.org Subject: RE: Types of content Would "dictionaries of posture attributes" include attribute values that ha= ve been collected from endpoints? We want to have the ability to collect attribute values from endpoints and = "persist" them, as described in section 2.1.3. So we'll need to have a repo= sitory for collected and persisted attribute values. If collected endpoint attribute values are considered content, let's say so= . If not, let's say that explicitly. My personal view is that collected endpoint attribute values should be cons= idered content. They may be a different kind of content from the others due= to larger volume and higher change rate. For that reason, people may choos= e to put them into a different repository and maybe even use a different qu= ery protocol for that repository to munge the large quantities of data. But= they're still content. Thanks, Steve From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Panos Kampanakis (pk= ampana) Sent: Wednesday, February 05, 2014 5:25 PM To: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] Types of content Sounds like a good summary of what "content" could mean. Panos From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, February 05, 2014 10:38 PM To: sacm@ietf.org Subject: [sacm] Types of content I'm working through the UC draft addressing discussion items from yesterday= and the previous comments we have received on the list on -05. Related to section 2.1.1, we have had many previous discussions around the = notional idea of content. There has been general agreement that we need to = be more specific. Please find below an attempt to put some "bounds" around = different types of content. Is this hitting the mark, or do we need to say something more/different? The following is a snippet from a possible update to section 2.1.1 with som= e additional description: I'd appreciate any thoughts, concerns, objections before I include the chan= ges in the draft. Thanks, Dave 2.1.1. Define, Publish, Query and Retrieve Content This use case describes the need for content to be defined and published to a data store, as well as queried and retrieved from the data store for the explicit use of posture collection and evaluation. The term "content" is a general concept that refers to any data expression that may be used as part of the process of collecting and evaluating endpoint posture. Typical types of content include: o Dictionaries of posture attributes (e.g. software installation, configuration, privileges) that may be collected from a given endpoint type that relate to installed hardware, installed software, software configurations, accounts, privileges, and other operational state. o Expressions that provide instructions for using a specific API, management protocol, or other mechanisms to collect specific posture attributes from specific device types. o Policies that define the selected posture attributes for which values must be collected to support one or more posture assessments. This may include information that targets collection to a specific set of endpoints and instructions on the frequency and/or change events (e.g., configuration changes, software installation/uninstallation, account/privilege modifications) that will trigger collection of one or more posture attributes. o Policies that define the logical criteria to evaluate collected posture attribute values to determine if they meet organizational requirements. This may include information that targets evaluation to a specific set of endpoints. --_000_ea2bd950e01a41609585082fe70876ffBLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dictionaries of postur= e attributes was not intended to include attribute values. IETF examples of= this concept might include attributes in a MIB or a NETMOD model.

 

I agree that we need t= o “persist” posture attribute values. I have always been on the= fence personally about calling collection and evaluation results “co= ntent”. I agree 100% that we need to be crystal clear about what we mean when we use the terms “content” and “= content repository”. If we choose to lump all of this together as = 220;content”, we will need to include some discussion in the use case= document contrasting different types of content to drive discussion of content type-specific requirements.

 

I also personally like= Ira’s feedback on using a more specific term(s) instead of the more = general “content”.

 

I also share the same = personal view around interacting with stores of collected posture attribute= values and evaluation results. The larger data volumes and rate of change = will likely require different approaches. I also believe that the temporal nature of this data, the need to persist = historic information, will be more significant than other types of data tha= t we may call “content”.

 

Are there other opinio= ns on this? Does anyone feel strongly that collected posture attribute valu= es and evaluation results SHOULD NOT be considered content?

 

Thanks,

Dave=

 

From: Stephen = Hanna [mailto:shanna@juniper.net]
Sent: Wednesday, February 05, 2014 6:10 PM
To: Panos Kampanakis (pkampana); Waltermire, David A.; sacm@ietf.org=
Subject: RE: Types of content

 

Would “dictionar= ies of posture attributes” include attribute values that have been co= llected from endpoints?

 

We want to have the ab= ility to collect attribute values from endpoints and “persist” = them, as described in section 2.1.3. So we’ll need to have a reposito= ry for collected and persisted attribute values.

 

If collected endpoint = attribute values are considered content, let’s say so. If not, let= 217;s say that explicitly.

 

My personal view is th= at collected endpoint attribute values should be considered content. They m= ay be a different kind of content from the others due to larger volume and = higher change rate. For that reason, people may choose to put them into a different repository and maybe even u= se a different query protocol for that repository to munge the large quanti= ties of data. But they’re still content.

 

Thanks,

 

Steve

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, February 05, 2014 5:25 PM
To: Waltermire, David A.; sacm@ietf= .org
Subject: Re: [sacm] Types of content

 

Sounds like a good sum= mary of what “content” could mean.

Panos

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Wednesday, February 05, 2014 10:38 PM
To: sacm@ietf.org
Subject: [sacm] Types of content

 

I’m working through the UC draft addressing discussi= on items from yesterday and the previous comments we have received on the l= ist on -05.

 

Related to section 2.1.1, we have had many previous discus= sions around the notional idea of content. There has been general agreement= that we need to be more specific. Please find below an attempt to put some “bounds” around different types o= f content.

 

Is this hitting the mark, or do we need to say something m= ore/different?

 

The following is a snippet from a possible update to secti= on 2.1.1 with some additional description:

 

I’d appreciate any thoughts, concerns, objections be= fore I include the changes in the draft.

 

Thanks,

Dave

 

2.1.1.  Define, Publish, Query and Retrieve Content

 

   This use case describes the need for content = to be defined and

   published to a data store, as well as queried= and retrieved from the

   data store for the explicit use of posture co= llection and evaluation.

 

   The term "content" is a general con= cept that refers to any data

   expression that may be used as part of the pr= ocess of collecting and

   evaluating endpoint posture.  Typical ty= pes of content include:

 

   o  Dictionaries of posture attributes (e= .g. software installation,

      configuration, privileges) = that may be collected from a given

      endpoint type that relate t= o installed hardware, installed

      software, software configur= ations, accounts, privileges, and other

      operational state.

 

   o  Expressions that provide instructions= for using a specific API,

      management protocol, or oth= er mechanisms to collect specific

      posture attributes from spe= cific device types.

 

   o  Policies that define the selected pos= ture attributes for which

      values must be collected to= support one or more posture

      assessments.  This may= include information that targets collection

      to a specific set of endpoi= nts and instructions on the frequency

      and/or change events (e.g.,= configuration changes, software

      installation/uninstallation= , account/privilege modifications) that

      will trigger collection of = one or more posture attributes.

 

   o  Policies that define the logical crit= eria to evaluate collected

      posture attribute values to= determine if they meet organizational

      requirements.  This ma= y include information that targets

      evaluation to a specific se= t of endpoints.

 

--_000_ea2bd950e01a41609585082fe70876ffBLUPR09MB038namprd09pro_-- From gunnar.engelbach@threatguard.com Wed Feb 5 16:10:16 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326A1A0280 for ; Wed, 5 Feb 2014 16:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu_eG18QOPjd for ; Wed, 5 Feb 2014 16:10:14 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8C91A025B for ; Wed, 5 Feb 2014 16:10:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=hQfLehUszJzoP8c8zWj5bqav5VfcuzZbaudeDZZZ26BvKkXA0uiDzb+L35wsiCwc+9d9GldViXNE2DuVBGusux2nSVtSDv26IAT23nni9ENXr9zgRQb3YCo6PIrJd5n1; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 21234 invoked from network); 5 Feb 2014 16:16:39 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 16:16:39 -0800 Message-ID: <52F2D2F3.5070009@ThreatGuard.com> Date: Wed, 05 Feb 2014 19:10:27 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Waltermire, David A." , David Harrington , "sacm@ietf.org" References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:10:16 -0000 How about: Identify Endpoint Targets: Using target attributes to determine the applicability of each to a given content item(s). On 2/5/2014 3:11 PM, Waltermire, David A. wrote: > I don't find the text to be restrictive since any set of endpoint attributes can be used (including aspects of posture). If we kept the text, what would not be supported for targeting? > > Dave > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Wednesday, February 05, 2014 3:03 PM >> To: Waltermire, David A.; David Harrington; sacm@ietf.org >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint >> Discovery/Characterization/Targeting >> >> >> >> With that change to "Endpoint Characterization" I find "Identify Endpoint >> Targets" to be redundant. >> >> However, if "Identify Endpoint Targets" is kept, I'd suggest dropping the >> clause >> >> "...based on evaluating organizational policies against known endpoint >> attributes." >> >> That makes a restrictive assumption about how it can be used. >> >> >> >> >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: >>> Gunnar, >>> >>> I'm changing the subject and trimming the thread to focus on the single >> point of discussion. >>> >>> Please find my feedback on your comment below. >>> >>> Dave >>> >>>> -----Original Message----- >>>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar >>>> Engelbach >>>> Sent: Wednesday, February 05, 2014 1:42 PM >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 >>>> >>>> >>>> All of this looks good to me, with one additional comment near the >> bottom... >>>> >>>> >>>> --gun >>>> >>>> >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: >>>>> >>>>> 4) in 2.1.2, >>>>> >>>>> Endpoint Discovery: The purpose of discovery is to determine the >>>>> type of endpoint to be posture assessed. >>>>> >>>>> QUESTION: Is it just the type? Or is it to identify what >>>>> endpoint instances to target for assessment using >>>>> metadata such >>>>> >>>>> as the endpoint's organizationally expected type (e.g., >>>>> >>>>> expected function/role, etc.) >>>>> >>>>> If this is truly endpoint "discovery", then I think this building >>>>> block discovers the whole set of endpoints it can see in the network >>>>> - i.e., the whole set of endpoints that might be able to be assessed. >>>>> >>>>> In the next step (targeting), that building block selects a subset >>>>> of the discovered set of endpoints, based on such things as type of >>>>> endpoint, organizationally expected function/role, version, etc. >>>>> >>>>> [DAW: The discussion on the call resulted in the identification of >>>>> two distinct concepts, Endpoint Discovery and Endpoint >>>>> Characterization, that are needed to support the identification of >>>>> what endpoints should be targeted for an assessment. Both of these >>>>> concepts have been combined in the current "Endpoint Discovery" >>>>> building block. There was agreement that these two aspects should be >>>>> broken out into distinct building block items. I took the action to propose >> some new text. >>>>> Please let us know if you have any objections or suggested changes >>>>> to the following proposed >>>>> change: >>>>> >>>>> Endpoint Discovery: To determine the current or historic presence of >>>>> endpoints in the environment that are available for posture assessment. >>>>> >>>>> Endpoint Characterization: The act of acquiring, through automated >>>>> collection or manual input, and organizing attributes associated >>>>> with an endpoint (e.g., type, organizationally expected >>>>> function/role, hardware/software versions) that can be used to >>>>> evaluate organizational policies that determine what endpoints >>>>> should be posture >>>> assessed. >>>> >>>> >>>> Just end this definition at the end of the parenthetical expression, >>>> which also removes the need for the following "Identify Endpoint >> Targets" definition. >>>> >>>> Classification is for both finding the appropriate content for an >>>> endpoint and for finding which endpoints content applies to. >>>> Examples for both uses could be simply stated, if necessary. >>>> >>> >>> I am fine with dropping the text "that can be used to evaluate >> organizational policies that determine what endpoints should be posture >> assessed", since this is somewhat redundant with the modified text under >> "Identify Endpoint Targets". >>> >>> The existing text in (-05) includes a definition for "Identify Endpoint >> Targets". I modified the existing text to tie together the classification and >> targeting concepts. IMHO this addresses finding which endpoints content >> applies to. The text under "Collection Content Acquisition" and "Evaluation >> Content Acquisition" addresses finding the appropriate content for an >> endpoint for collection and evaluation. >>> >>> To be more clear about what the change to "Identify Endpoint Targets" >> entails, here is the original text: >>> >>> Identify Endpoint Targets: To identify what potential endpoint >>> targets the checklist should apply to based on organizational >>> policies. >>> >>> The new text adds the text in brackets: >>> >>> Identify Endpoint Targets: To identify what potential endpoint >>> targets the checklist should apply to based on [evaluating] >> organizational >>> policies [against known endpoint attributes]. >>> >>> Based on this discussion the complete text might be modified to: >>> >>> Endpoint Discovery: To determine the current or historic presence of >>> endpoints in the environment that are available for posture >> assessment. >>> >>> Endpoint Characterization: The act of acquiring, through automated >>> collection or manual input, and organizing attributes associated with >>> an endpoint (e.g., type, organizationally expected function/role, >>> hardware/software versions). >>> >>> Identify Endpoint Targets: To identify what potential endpoint >>> targets the checklist should apply to based on evaluating >> organizational >>> policies against known endpoint attributes. >>> >>> How about this? >>> From david.waltermire@nist.gov Wed Feb 5 16:25:52 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941461A0274 for ; Wed, 5 Feb 2014 16:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYu71xe_yDsp for ; Wed, 5 Feb 2014 16:25:47 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id A780C1A0280 for ; Wed, 5 Feb 2014 16:25:47 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 00:25:45 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 00:25:45 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , David Harrington , "sacm@ietf.org" Thread-Topic: QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting Thread-Index: Ac8ip4YavIuzj5GPS3G7cT9B5maaAQABbooAAAAq3iAACHq0gAAATnnw Date: Thu, 6 Feb 2014 00:25:44 +0000 Message-ID: <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2D2F3.5070009@ThreatGuard.com> In-Reply-To: <52F2D2F3.5070009@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(479174003)(377454003)(51704005)(13464003)(189002)(199002)(53806001)(54356001)(85306002)(2656002)(81686001)(92566001)(76482001)(90146001)(94946001)(54316002)(46102001)(47736001)(94316002)(4396001)(65816001)(74876001)(74502001)(93516002)(87266001)(77982001)(51856001)(83072002)(81816001)(85852003)(56776001)(93136001)(86362001)(59766001)(63696002)(79102001)(95416001)(80022001)(56816005)(74706001)(66066001)(87936001)(47446002)(49866001)(33646001)(80976001)(81342001)(74662001)(31966008)(47976001)(50986001)(74316001)(19580395003)(83322001)(19580405001)(77096001)(81542001)(76576001)(69226001)(76796001)(74366001)(76786001)(21314002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EEACF228.A6E2575A.71DFB76B.CAECC961.204D1; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:25:52 -0000 I just noticed that I dropped some of the original text for this entry. How= about the following that adds this text back in? Identify Endpoint Targets: Determine the candidate endpoint target(s) against which to perform the assessment. Depending on the a= ssessment trigger, a single endpoint or multiple endpoints may be targeted based= on characterized endpoint attributes. Content may describe the applicable ta= rgets for assessment. In this case the Content Query and/or Content Retrieval buildi= ng blocks (see section XXX) may be used to acquire this content for processing. Dave > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Wednesday, February 05, 2014 7:10 PM > To: Waltermire, David A.; David Harrington; sacm@ietf.org > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > Discovery/Characterization/Targeting >=20 >=20 > How about: >=20 > Identify Endpoint Targets: Using target attributes to determine the > applicability of each to a given content item(s). >=20 >=20 >=20 > On 2/5/2014 3:11 PM, Waltermire, David A. wrote: > > I don't find the text to be restrictive since any set of endpoint attri= butes > can be used (including aspects of posture). If we kept the text, what wou= ld > not be supported for targeting? > > > > Dave > > > >> -----Original Message----- > >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > >> Sent: Wednesday, February 05, 2014 3:03 PM > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org > >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > >> Discovery/Characterization/Targeting > >> > >> > >> > >> With that change to "Endpoint Characterization" I find "Identify Endpo= int > >> Targets" to be redundant. > >> > >> However, if "Identify Endpoint Targets" is kept, I'd suggest dropping = the > >> clause > >> > >> "...based on evaluating organizational policies against known endp= oint > >> attributes." > >> > >> That makes a restrictive assumption about how it can be used. > >> > >> > >> > >> > >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > >>> Gunnar, > >>> > >>> I'm changing the subject and trimming the thread to focus on the sing= le > >> point of discussion. > >>> > >>> Please find my feedback on your comment below. > >>> > >>> Dave > >>> > >>>> -----Original Message----- > >>>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > >>>> Engelbach > >>>> Sent: Wednesday, February 05, 2014 1:42 PM > >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org > >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 > >>>> > >>>> > >>>> All of this looks good to me, with one additional comment near the > >> bottom... > >>>> > >>>> > >>>> --gun > >>>> > >>>> > >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > >>>>> > >>>>> 4) in 2.1.2, > >>>>> > >>>>> Endpoint Discovery: The purpose of discovery is to determine the > >>>>> type of endpoint to be posture assessed. > >>>>> > >>>>> QUESTION: Is it just the type? Or is it to identify wh= at > >>>>> endpoint instances to target for assessment using > >>>>> metadata such > >>>>> > >>>>> as the endpoint's organizationally expected type (e.g., > >>>>> > >>>>> expected function/role, etc.) > >>>>> > >>>>> If this is truly endpoint "discovery", then I think this building > >>>>> block discovers the whole set of endpoints it can see in the networ= k > >>>>> - i.e., the whole set of endpoints that might be able to be assesse= d. > >>>>> > >>>>> In the next step (targeting), that building block selects a subset > >>>>> of the discovered set of endpoints, based on such things as type of > >>>>> endpoint, organizationally expected function/role, version, etc. > >>>>> > >>>>> [DAW: The discussion on the call resulted in the identification of > >>>>> two distinct concepts, Endpoint Discovery and Endpoint > >>>>> Characterization, that are needed to support the identification of > >>>>> what endpoints should be targeted for an assessment. Both of these > >>>>> concepts have been combined in the current "Endpoint Discovery" > >>>>> building block. There was agreement that these two aspects should > be > >>>>> broken out into distinct building block items. I took the action to > propose > >> some new text. > >>>>> Please let us know if you have any objections or suggested changes > >>>>> to the following proposed > >>>>> change: > >>>>> > >>>>> Endpoint Discovery: To determine the current or historic presence o= f > >>>>> endpoints in the environment that are available for posture > assessment. > >>>>> > >>>>> Endpoint Characterization: The act of acquiring, through automated > >>>>> collection or manual input, and organizing attributes associated > >>>>> with an endpoint (e.g., type, organizationally expected > >>>>> function/role, hardware/software versions) that can be used to > >>>>> evaluate organizational policies that determine what endpoints > >>>>> should be posture > >>>> assessed. > >>>> > >>>> > >>>> Just end this definition at the end of the parenthetical expression, > >>>> which also removes the need for the following "Identify Endpoint > >> Targets" definition. > >>>> > >>>> Classification is for both finding the appropriate content for an > >>>> endpoint and for finding which endpoints content applies to. > >>>> Examples for both uses could be simply stated, if necessary. > >>>> > >>> > >>> I am fine with dropping the text "that can be used to evaluate > >> organizational policies that determine what endpoints should be postur= e > >> assessed", since this is somewhat redundant with the modified text > under > >> "Identify Endpoint Targets". > >>> > >>> The existing text in (-05) includes a definition for "Identify Endpoi= nt > >> Targets". I modified the existing text to tie together the classificat= ion and > >> targeting concepts. IMHO this addresses finding which endpoints conten= t > >> applies to. The text under "Collection Content Acquisition" and > "Evaluation > >> Content Acquisition" addresses finding the appropriate content for an > >> endpoint for collection and evaluation. > >>> > >>> To be more clear about what the change to "Identify Endpoint Targets" > >> entails, here is the original text: > >>> > >>> Identify Endpoint Targets: To identify what potential endpoint > >>> targets the checklist should apply to based on organizatio= nal > >>> policies. > >>> > >>> The new text adds the text in brackets: > >>> > >>> Identify Endpoint Targets: To identify what potential endpoint > >>> targets the checklist should apply to based on [evaluating= ] > >> organizational > >>> policies [against known endpoint attributes]. > >>> > >>> Based on this discussion the complete text might be modified to: > >>> > >>> Endpoint Discovery: To determine the current or historic presence of > >>> endpoints in the environment that are available for postur= e > >> assessment. > >>> > >>> Endpoint Characterization: The act of acquiring, through automated > >>> collection or manual input, and organizing attributes asso= ciated > with > >>> an endpoint (e.g., type, organizationally expected functio= n/role, > >>> hardware/software versions). > >>> > >>> Identify Endpoint Targets: To identify what potential endpoint > >>> targets the checklist should apply to based on evaluating > >> organizational > >>> policies against known endpoint attributes. > >>> > >>> How about this? > >>> From blueroofmusic@gmail.com Wed Feb 5 16:32:27 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217F51A022C for ; Wed, 5 Feb 2014 16:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCL5Zjqt2n8O for ; Wed, 5 Feb 2014 16:32:24 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id DCC741A01ED for ; Wed, 5 Feb 2014 16:32:23 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so4757698iga.1 for ; Wed, 05 Feb 2014 16:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K5Jji8Bmp6t36tqoIrOQLTN2wXDcNnpOCg8UwAwJL24=; b=yrgCX9AHrNL5m3BzkbMg/0G6EW+lOQkxKye+PXdLtptsEibvGyQX4pjDtgY1L4htfm yfDm7pqq3VrnCKRfpkvSLQtuPOhSjIM7iEZTjJGB/0k7BNwpHjDkkNuRndmrQKIYFs7J x9A/znJVJodi7XX1HbUNOYa721TqGq3xuEHiwNAkZ/pnHh1KughprvIHPhFXDo3WjVFB FX7kWNvsAGBV9y3YT0BWlbyzztdLfat+PuE8qwlMLu17gWb8ebpQwKItHL9KQZRLyLGl U0xX1XaJnVHwwjex0uavD7kI6/ld5JMEQYHosJ/7KGMYAbMI8XrP6VIN203r1HR4sKIk moqg== X-Received: by 10.50.194.131 with SMTP id hw3mr6526046igc.4.1391646732520; Wed, 05 Feb 2014 16:32:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Wed, 5 Feb 2014 16:31:11 -0800 (PST) In-Reply-To: <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2D2F3.5070009@ThreatGuard.com> <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> From: Ira McDonald Date: Wed, 5 Feb 2014 19:31:11 -0500 Message-ID: To: "Waltermire, David A." , Ira McDonald Content-Type: multipart/alternative; boundary=14dae9340f7925132104f1b201af Cc: Gunnar Engelbach , David Harrington , "sacm@ietf.org" Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:32:27 -0000 --14dae9340f7925132104f1b201af Content-Type: text/plain; charset=ISO-8859-1 Hi Dave, I like this Identify Endpoint Targets text better. Cheers, - Ira On Wed, Feb 5, 2014 at 7:25 PM, Waltermire, David A. < david.waltermire@nist.gov> wrote: > I just noticed that I dropped some of the original text for this entry. > How about the following that adds this text back in? > > Identify Endpoint Targets: Determine the candidate endpoint target(s) > against which to perform the assessment. Depending on the > assessment trigger, a > single endpoint or multiple endpoints may be targeted > based on characterized > endpoint attributes. Content may describe the applicable > targets for assessment. In > this case the Content Query and/or Content Retrieval > building blocks (see section > XXX) may be used to acquire this content for processing. > > Dave > > > -----Original Message----- > > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > > Sent: Wednesday, February 05, 2014 7:10 PM > > To: Waltermire, David A.; David Harrington; sacm@ietf.org > > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > > Discovery/Characterization/Targeting > > > > > > How about: > > > > Identify Endpoint Targets: Using target attributes to determine the > > applicability of each to a given content item(s). > > > > > > > > On 2/5/2014 3:11 PM, Waltermire, David A. wrote: > > > I don't find the text to be restrictive since any set of endpoint > attributes > > can be used (including aspects of posture). If we kept the text, what > would > > not be supported for targeting? > > > > > > Dave > > > > > >> -----Original Message----- > > >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > > >> Sent: Wednesday, February 05, 2014 3:03 PM > > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org > > >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > > >> Discovery/Characterization/Targeting > > >> > > >> > > >> > > >> With that change to "Endpoint Characterization" I find "Identify > Endpoint > > >> Targets" to be redundant. > > >> > > >> However, if "Identify Endpoint Targets" is kept, I'd suggest dropping > the > > >> clause > > >> > > >> "...based on evaluating organizational policies against known > endpoint > > >> attributes." > > >> > > >> That makes a restrictive assumption about how it can be used. > > >> > > >> > > >> > > >> > > >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > > >>> Gunnar, > > >>> > > >>> I'm changing the subject and trimming the thread to focus on the > single > > >> point of discussion. > > >>> > > >>> Please find my feedback on your comment below. > > >>> > > >>> Dave > > >>> > > >>>> -----Original Message----- > > >>>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > > >>>> Engelbach > > >>>> Sent: Wednesday, February 05, 2014 1:42 PM > > >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org > > >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 > > >>>> > > >>>> > > >>>> All of this looks good to me, with one additional comment near the > > >> bottom... > > >>>> > > >>>> > > >>>> --gun > > >>>> > > >>>> > > >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > > >>>>> > > >>>>> 4) in 2.1.2, > > >>>>> > > >>>>> Endpoint Discovery: The purpose of discovery is to determine the > > >>>>> type of endpoint to be posture assessed. > > >>>>> > > >>>>> QUESTION: Is it just the type? Or is it to identify > what > > >>>>> endpoint instances to target for assessment using > > >>>>> metadata such > > >>>>> > > >>>>> as the endpoint's organizationally expected type (e.g., > > >>>>> > > >>>>> expected function/role, etc.) > > >>>>> > > >>>>> If this is truly endpoint "discovery", then I think this building > > >>>>> block discovers the whole set of endpoints it can see in the > network > > >>>>> - i.e., the whole set of endpoints that might be able to be > assessed. > > >>>>> > > >>>>> In the next step (targeting), that building block selects a subset > > >>>>> of the discovered set of endpoints, based on such things as type of > > >>>>> endpoint, organizationally expected function/role, version, etc. > > >>>>> > > >>>>> [DAW: The discussion on the call resulted in the identification of > > >>>>> two distinct concepts, Endpoint Discovery and Endpoint > > >>>>> Characterization, that are needed to support the identification of > > >>>>> what endpoints should be targeted for an assessment. Both of these > > >>>>> concepts have been combined in the current "Endpoint Discovery" > > >>>>> building block. There was agreement that these two aspects should > > be > > >>>>> broken out into distinct building block items. I took the action to > > propose > > >> some new text. > > >>>>> Please let us know if you have any objections or suggested changes > > >>>>> to the following proposed > > >>>>> change: > > >>>>> > > >>>>> Endpoint Discovery: To determine the current or historic presence > of > > >>>>> endpoints in the environment that are available for posture > > assessment. > > >>>>> > > >>>>> Endpoint Characterization: The act of acquiring, through automated > > >>>>> collection or manual input, and organizing attributes associated > > >>>>> with an endpoint (e.g., type, organizationally expected > > >>>>> function/role, hardware/software versions) that can be used to > > >>>>> evaluate organizational policies that determine what endpoints > > >>>>> should be posture > > >>>> assessed. > > >>>> > > >>>> > > >>>> Just end this definition at the end of the parenthetical expression, > > >>>> which also removes the need for the following "Identify Endpoint > > >> Targets" definition. > > >>>> > > >>>> Classification is for both finding the appropriate content for an > > >>>> endpoint and for finding which endpoints content applies to. > > >>>> Examples for both uses could be simply stated, if necessary. > > >>>> > > >>> > > >>> I am fine with dropping the text "that can be used to evaluate > > >> organizational policies that determine what endpoints should be > posture > > >> assessed", since this is somewhat redundant with the modified text > > under > > >> "Identify Endpoint Targets". > > >>> > > >>> The existing text in (-05) includes a definition for "Identify > Endpoint > > >> Targets". I modified the existing text to tie together the > classification and > > >> targeting concepts. IMHO this addresses finding which endpoints > content > > >> applies to. The text under "Collection Content Acquisition" and > > "Evaluation > > >> Content Acquisition" addresses finding the appropriate content for an > > >> endpoint for collection and evaluation. > > >>> > > >>> To be more clear about what the change to "Identify Endpoint Targets" > > >> entails, here is the original text: > > >>> > > >>> Identify Endpoint Targets: To identify what potential endpoint > > >>> targets the checklist should apply to based on > organizational > > >>> policies. > > >>> > > >>> The new text adds the text in brackets: > > >>> > > >>> Identify Endpoint Targets: To identify what potential endpoint > > >>> targets the checklist should apply to based on > [evaluating] > > >> organizational > > >>> policies [against known endpoint attributes]. > > >>> > > >>> Based on this discussion the complete text might be modified to: > > >>> > > >>> Endpoint Discovery: To determine the current or historic presence of > > >>> endpoints in the environment that are available for > posture > > >> assessment. > > >>> > > >>> Endpoint Characterization: The act of acquiring, through automated > > >>> collection or manual input, and organizing attributes > associated > > with > > >>> an endpoint (e.g., type, organizationally expected > function/role, > > >>> hardware/software versions). > > >>> > > >>> Identify Endpoint Targets: To identify what potential endpoint > > >>> targets the checklist should apply to based on evaluating > > >> organizational > > >>> policies against known endpoint attributes. > > >>> > > >>> How about this? > > >>> > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --14dae9340f7925132104f1b201af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave,

I like this Identify Endpoint T= argets text better.

Cheers,
=
- Ira
=


On Wed, Feb 5, 2014 at 7:25 PM, Waltermi= re, David A. <david.waltermire@nist.gov> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I just noticed that I dropped some of the original text for this entry. How= about the following that adds this text back in?

Identify Endpoint Targets: =A0Determine the candidate endpoint target(s) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 against which to perform the assessment. De= pending on the assessment trigger, a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 single endpoint or multiple endpoints may b= e targeted based on characterized
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 endpoint attributes. Content may describe t= he applicable targets for assessment. In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this case the Content Query and/or Content = Retrieval building blocks (see section
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 XXX) may be used to acquire this content fo= r processing.

Dave

> -----Original Message-----
> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]
> Sent: Wednesday, Februar= y 05, 2014 7:10 PM
> To: Waltermire, David A.; David Harrington; sacm@ietf.org
> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint
> Discovery/Characterization/Targeting
>
>
> How about:
>
> Identify Endpoint Targets: =A0Using target attributes to determine the=
> applicability of each to a given content item(s).
>
>
>
> On 2/5/2014 3:11 PM, Waltermire, David A. wrote:
> > I don't find the text to be restrictive since any set of endp= oint attributes
> can be used (including aspects of posture). If we kept the text, what = would
> not be supported for targeting?
> >
> > Dave
> >
> >> -----Original Message-----
> >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]
> >> Sent: Wednesday, February 05, 2014 3:03 PM
> >> To: Waltermire, David A.; David Harrington; sacm@ietf.org
> >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint=
> >> Discovery/Characterization/Targeting
> >>
> >>
> >>
> >> With that change to "Endpoint Characterization" I f= ind "Identify Endpoint
> >> Targets" to be redundant.
> >>
> >> However, if "Identify Endpoint Targets" is kept, I&= #39;d suggest dropping the
> >> clause
> >>
> >> =A0 =A0 "...based on evaluating organizational policies = against known endpoint
> >> attributes."
> >>
> >> That makes a restrictive assumption about how it can be used.=
> >>
> >>
> >>
> >>
> >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote:
> >>> Gunnar,
> >>>
> >>> I'm changing the subject and trimming the thread to f= ocus on the single
> >> point of discussion.
> >>>
> >>> Please find my feedback on your comment below.
> >>>
> >>> Dave
> >>>
> >>>> -----Original Message-----
> >>>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar
> >>>> Engelbach
> >>>> Sent: Wednesday, February 05, 2014 1:42 PM
> >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org
> >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cas= es-5
> >>>>
> >>>>
> >>>> All of this looks good to me, with one additional com= ment near the
> >> bottom...
> >>>>
> >>>>
> >>>> --gun
> >>>>
> >>>>
> >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote:
> >>>>>
> >>>>> 4) in 2.1.2,
> >>>>>
> >>>>> Endpoint Discovery: =A0The purpose of discovery i= s to determine the
> >>>>> =A0 =A0 =A0 =A0 =A0 =A0 type of endpoint to be po= sture assessed.
> >>>>>
> >>>>> =A0 =A0 =A0 =A0 =A0 =A0 QUESTION: Is it just the = type? =A0Or is it to identify what
> >>>>> =A0 =A0 =A0 =A0 =A0 =A0 endpoint instances to tar= get for assessment using
> >>>>> metadata such
> >>>>>
> >>>>> =A0 =A0 =A0 =A0 =A0 =A0 as the endpoint's org= anizationally expected type (e.g.,
> >>>>>
> >>>>> =A0 =A0 =A0 =A0 =A0 =A0 expected function/role, e= tc.)
> >>>>>
> >>>>> If this is truly endpoint "discovery", = then I think this building
> >>>>> block discovers the whole set of endpoints it can= see in the network
> >>>>> - i.e., the whole set of endpoints that might be = able to be assessed.
> >>>>>
> >>>>> In the next step (targeting), that building block= selects a subset
> >>>>> of the discovered set of endpoints, based on such= things as type of
> >>>>> endpoint, organizationally expected function/role= , version, etc.
> >>>>>
> >>>>> [DAW: The discussion on the call resulted in the = identification of
> >>>>> two distinct concepts, Endpoint Discovery and End= point
> >>>>> Characterization, that are needed to support the = identification of
> >>>>> what endpoints should be targeted for an assessme= nt. Both of these
> >>>>> concepts have been combined in the current "= Endpoint Discovery"
> >>>>> building block. There was agreement that these tw= o aspects should
> be
> >>>>> broken out into distinct building block items. I = took the action to
> propose
> >> some new text.
> >>>>> Please let us know if you have any objections or = suggested changes
> >>>>> to the following proposed
> >>>>> change:
> >>>>>
> >>>>> Endpoint Discovery: To determine the current or h= istoric presence of
> >>>>> endpoints in the environment that are available f= or posture
> assessment.
> >>>>>
> >>>>> Endpoint Characterization: The act of acquiring, = through automated
> >>>>> collection or manual input, and organizing attrib= utes associated
> >>>>> with an endpoint (e.g., type, organizationally ex= pected
> >>>>> function/role, hardware/software versions) that c= an be used to
> >>>>> evaluate organizational policies that determine w= hat endpoints
> >>>>> should be posture
> >>>> assessed.
> >>>>
> >>>>
> >>>> Just end this definition at the end of the parentheti= cal expression,
> >>>> which also removes the need for the following "I= dentify Endpoint
> >> Targets" definition.
> >>>>
> >>>> Classification is for both finding the appropriate co= ntent for an
> >>>> endpoint and for finding which endpoints content appl= ies to.
> >>>> Examples for both uses could be simply stated, if nec= essary.
> >>>>
> >>>
> >>> I am fine with dropping the text "that can be used t= o evaluate
> >> organizational policies that determine what endpoints should = be posture
> >> assessed", since this is somewhat redundant with the mod= ified text
> under
> >> "Identify Endpoint Targets".
> >>>
> >>> The existing text in (-05) includes a definition for &quo= t;Identify Endpoint
> >> Targets". I modified the existing text to tie together t= he classification and
> >> targeting concepts. IMHO this addresses finding which endpoin= ts content
> >> applies to. The text under "Collection Content Acquisiti= on" and
> "Evaluation
> >> Content Acquisition" addresses finding the appropriate c= ontent for an
> >> endpoint for collection and evaluation.
> >>>
> >>> To be more clear about what the change to "Identify = Endpoint Targets"
> >> entails, here is the original text:
> >>>
> >>> Identify Endpoint Targets: =A0To identify what potential = endpoint
> >>> =A0 =A0 =A0 =A0 =A0 =A0targets the checklist should apply= to based on organizational
> >>> =A0 =A0 =A0 =A0 =A0 =A0policies.
> >>>
> >>> The new text adds the text in brackets:
> >>>
> >>> Identify Endpoint Targets: =A0To identify what potential = endpoint
> >>> =A0 =A0 =A0 =A0 =A0 =A0targets the checklist should apply= to based on [evaluating]
> >> organizational
> >>> =A0 =A0 =A0 =A0 =A0 =A0policies [against known endpoint a= ttributes].
> >>>
> >>> Based on this discussion the complete text might be modif= ied to:
> >>>
> >>> Endpoint Discovery: To determine the current or historic = presence of
> >>> =A0 =A0 =A0 =A0 =A0 =A0endpoints in the environment that = are available for posture
> >> assessment.
> >>>
> >>> Endpoint Characterization: The act of acquiring, through = automated
> >>> =A0 =A0 =A0 =A0 =A0 =A0collection or manual input, and or= ganizing attributes associated
> with
> >>> =A0 =A0 =A0 =A0 =A0 =A0an endpoint (e.g., type, organizat= ionally expected function/role,
> >>> =A0 =A0 =A0 =A0 =A0 =A0hardware/software versions).
> >>>
> >>> Identify Endpoint Targets: =A0To identify what potential = endpoint
> >>> =A0 =A0 =A0 =A0 =A0 =A0targets the checklist should apply= to based on evaluating
> >> organizational
> >>> =A0 =A0 =A0 =A0 =A0 =A0policies against known endpoint at= tributes.
> >>>
> >>> How about this?
> >>>
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--14dae9340f7925132104f1b201af-- From gunnar.engelbach@threatguard.com Wed Feb 5 16:37:03 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47AE1A022C for ; Wed, 5 Feb 2014 16:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp__bqVZxfhQ for ; Wed, 5 Feb 2014 16:37:01 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 720611A0280 for ; Wed, 5 Feb 2014 16:37:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=pago3Wo8YlyVvl5xX9e06w4nasMlR2TC5ItwZlgmW/jPjSiJbR4zZFD9WBwxJLawQogWj5gz8PZkxu6BBsXp5dyAz7hUB5BV0ui4rhlq24fwEfVBVxW9A8A/M8SV6eMR; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 21886 invoked from network); 5 Feb 2014 16:43:27 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 16:43:26 -0800 Message-ID: <52F2D93A.5020308@ThreatGuard.com> Date: Wed, 05 Feb 2014 19:37:14 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Waltermire, David A." , Stephen Hanna , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:37:03 -0000 I would prefer to reserve the term "content" for the instructional documentation. That is, the documents that cause an action, be it legislation, prose guidance, or a set of machine instructions that implement that guidance. We typically use "system characteristics" when referring to collected items, and variations on "endpoint attributes" has been used frequently on this list. System characteristics are the product of applying content to an endpoint. Collectively it's all data. Is there a desire to have a general term for all data that could flow through a SACM implementation but is specific to SACM? Also, while I agree with the need to allow the ability to persist collected data items (and the results of posture evaluations), I don't see that as a requirement. On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > Dictionaries of posture attributes was not intended to include attribute > values. IETF examples of this concept might include attributes in a MIB > or a NETMOD model. > > I agree that we need to “persist” posture attribute values. I have > always been on the fence personally about calling collection and > evaluation results “content”. I agree 100% that we need to be crystal > clear about what we mean when we use the terms “content” and “content > repository”. If we choose to lump all of this together as “content”, we > will need to include some discussion in the use case document > contrasting different types of content to drive discussion of content > type-specific requirements. > > I also personally like Ira’s feedback on using a more specific term(s) > instead of the more general “content”. > > I also share the same personal view around interacting with stores of > collected posture attribute values and evaluation results. The larger > data volumes and rate of change will likely require different > approaches. I also believe that the temporal nature of this data, the > need to persist historic information, will be more significant than > other types of data that we may call “content”. > > Are there other opinions on this? Does anyone feel strongly that > collected posture attribute values and evaluation results SHOULD NOT be > considered content? > > Thanks, > > Dave > > *From:*Stephen Hanna [mailto:shanna@juniper.net] > *Sent:* Wednesday, February 05, 2014 6:10 PM > *To:* Panos Kampanakis (pkampana); Waltermire, David A.; sacm@ietf.org > *Subject:* RE: Types of content > > Would “dictionaries of posture attributes” include attribute values that > have been collected from endpoints? > > We want to have the ability to collect attribute values from endpoints > and “persist” them, as described in section 2.1.3. So we’ll need to have > a repository for collected and persisted attribute values. > > If collected endpoint attribute values are considered content, let’s say > so. If not, let’s say that explicitly. > > My personal view is that collected endpoint attribute values should be > considered content. They may be a different kind of content from the > others due to larger volume and higher change rate. For that reason, > people may choose to put them into a different repository and maybe even > use a different query protocol for that repository to munge the large > quantities of data. But they’re still content. > > Thanks, > > Steve > > *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > Kampanakis (pkampana) > *Sent:* Wednesday, February 05, 2014 5:25 PM > *To:* Waltermire, David A.; sacm@ietf.org > *Subject:* Re: [sacm] Types of content > > Sounds like a good summary of what “content” could mean. > > Panos > > *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Waltermire, > David A. > *Sent:* Wednesday, February 05, 2014 10:38 PM > *To:* sacm@ietf.org > *Subject:* [sacm] Types of content > > I’m working through the UC draft addressing discussion items from > yesterday and the previous comments we have received on the list on -05. > > Related to section 2.1.1, we have had many previous discussions around > the notional idea of content. There has been general agreement that we > need to be more specific. Please find below an attempt to put some > “bounds” around different types of content. > > Is this hitting the mark, or do we need to say something more/different? > > The following is a snippet from a possible update to section 2.1.1 with > some additional description: > > I’d appreciate any thoughts, concerns, objections before I include the > changes in the draft. > > Thanks, > > Dave > > 2.1.1. Define, Publish, Query and Retrieve Content > > This use case describes the need for content to be defined and > > published to a data store, as well as queried and retrieved from the > > data store for the explicit use of posture collection and evaluation. > > The term "content" is a general concept that refers to any data > > expression that may be used as part of the process of collecting and > > evaluating endpoint posture. Typical types of content include: > > o Dictionaries of posture attributes (e.g. software installation, > > configuration, privileges) that may be collected from a given > > endpoint type that relate to installed hardware, installed > > software, software configurations, accounts, privileges, and other > > operational state. > > o Expressions that provide instructions for using a specific API, > > management protocol, or other mechanisms to collect specific > > posture attributes from specific device types. > > o Policies that define the selected posture attributes for which > > values must be collected to support one or more posture > > assessments. This may include information that targets collection > > to a specific set of endpoints and instructions on the frequency > > and/or change events (e.g., configuration changes, software > > installation/uninstallation, account/privilege modifications) that > > will trigger collection of one or more posture attributes. > > o Policies that define the logical criteria to evaluate collected > > posture attribute values to determine if they meet organizational > > requirements. This may include information that targets > > evaluation to a specific set of endpoints. > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From gunnar.engelbach@threatguard.com Wed Feb 5 16:52:58 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534421A0211 for ; Wed, 5 Feb 2014 16:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPqdm6Acrfrx for ; Wed, 5 Feb 2014 16:52:52 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id AA37A1A021D for ; Wed, 5 Feb 2014 16:52:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=k4tlrkLRxCtB1jDuSpCmqwxBajEyb9lgplg8gkSD+h1gU+cJAppRHOObCPfl/wrQwRX7LSzAXVhKbvWLlEuS5S47bcXxJybArt//QOJohjDlSjbmKjTgNcfIA2Mf6Q5o; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 22130 invoked from network); 5 Feb 2014 16:59:15 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 16:59:15 -0800 Message-ID: <52F2DCEE.4080007@ThreatGuard.com> Date: Wed, 05 Feb 2014 19:53:02 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ira McDonald , "Waltermire, David A." References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2D2F3.5070009@ThreatGuard.com> <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:52:58 -0000 On 2/5/2014 7:31 PM, Ira McDonald wrote: > Hi Dave, > > I like this Identify Endpoint Targets text better. > > Cheers, > - Ira I second that, but I wonder if somebody new to this would have further questions. For example: "Content may describe the applicable targets for assessment" Does that say that the content will have something like a list of the target IP addresses? How about: "Content may contain instructions or references used to determine its applicability." "In this case the Content Query and/or Content Retrieval building blocks (see section XXX) may be used to acquire this content for processing." Is that to say that the content may refer to other content, which must be retrieved and applied in order to determine applicability? And therefore that referenced content could also contain content references that need to be resolved? Is it also possible for this content to be entirely self-contained in that it also contains all the instructions necessary for determining its own applicability? If that's what's covered in section XXX then.....cool! > > > On Wed, Feb 5, 2014 at 7:25 PM, Waltermire, David A. > > wrote: > > I just noticed that I dropped some of the original text for this > entry. How about the following that adds this text back in? > > Identify Endpoint Targets: Determine the candidate endpoint target(s) > against which to perform the assessment. Depending > on the assessment trigger, a > single endpoint or multiple endpoints may be > targeted based on characterized > endpoint attributes. Content may describe the > applicable targets for assessment. In > this case the Content Query and/or Content > Retrieval building blocks (see section > XXX) may be used to acquire this content for > processing. > > Dave > > > -----Original Message----- > > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com > ] > > Sent: Wednesday, February 05, 2014 7:10 PM > > To: Waltermire, David A.; David Harrington; sacm@ietf.org > > > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > > Discovery/Characterization/Targeting > > > > > > How about: > > > > Identify Endpoint Targets: Using target attributes to determine the > > applicability of each to a given content item(s). > > > > > > > > On 2/5/2014 3:11 PM, Waltermire, David A. wrote: > > > I don't find the text to be restrictive since any set of > endpoint attributes > > can be used (including aspects of posture). If we kept the text, > what would > > not be supported for targeting? > > > > > > Dave > > > > > >> -----Original Message----- > > >> From: Gunnar Engelbach > [mailto:Gunnar.Engelbach@ThreatGuard.com > ] > > >> Sent: Wednesday, February 05, 2014 3:03 PM > > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org > > > >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > > >> Discovery/Characterization/Targeting > > >> > > >> > > >> > > >> With that change to "Endpoint Characterization" I find > "Identify Endpoint > > >> Targets" to be redundant. > > >> > > >> However, if "Identify Endpoint Targets" is kept, I'd suggest > dropping the > > >> clause > > >> > > >> "...based on evaluating organizational policies against > known endpoint > > >> attributes." > > >> > > >> That makes a restrictive assumption about how it can be used. > > >> > > >> > > >> > > >> > > >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > > >>> Gunnar, > > >>> > > >>> I'm changing the subject and trimming the thread to focus on > the single > > >> point of discussion. > > >>> > > >>> Please find my feedback on your comment below. > > >>> > > >>> Dave > > >>> > > >>>> -----Original Message----- > > >>>> From: sacm [mailto:sacm-bounces@ietf.org > ] On Behalf Of Gunnar > > >>>> Engelbach > > >>>> Sent: Wednesday, February 05, 2014 1:42 PM > > >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org > > > >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 > > >>>> > > >>>> > > >>>> All of this looks good to me, with one additional comment > near the > > >> bottom... > > >>>> > > >>>> > > >>>> --gun > > >>>> > > >>>> > > >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > > >>>>> > > >>>>> 4) in 2.1.2, > > >>>>> > > >>>>> Endpoint Discovery: The purpose of discovery is to > determine the > > >>>>> type of endpoint to be posture assessed. > > >>>>> > > >>>>> QUESTION: Is it just the type? Or is it to > identify what > > >>>>> endpoint instances to target for assessment using > > >>>>> metadata such > > >>>>> > > >>>>> as the endpoint's organizationally expected > type (e.g., > > >>>>> > > >>>>> expected function/role, etc.) > > >>>>> > > >>>>> If this is truly endpoint "discovery", then I think this > building > > >>>>> block discovers the whole set of endpoints it can see in > the network > > >>>>> - i.e., the whole set of endpoints that might be able to be > assessed. > > >>>>> > > >>>>> In the next step (targeting), that building block selects a > subset > > >>>>> of the discovered set of endpoints, based on such things as > type of > > >>>>> endpoint, organizationally expected function/role, version, > etc. > > >>>>> > > >>>>> [DAW: The discussion on the call resulted in the > identification of > > >>>>> two distinct concepts, Endpoint Discovery and Endpoint > > >>>>> Characterization, that are needed to support the > identification of > > >>>>> what endpoints should be targeted for an assessment. Both > of these > > >>>>> concepts have been combined in the current "Endpoint Discovery" > > >>>>> building block. There was agreement that these two aspects > should > > be > > >>>>> broken out into distinct building block items. I took the > action to > > propose > > >> some new text. > > >>>>> Please let us know if you have any objections or suggested > changes > > >>>>> to the following proposed > > >>>>> change: > > >>>>> > > >>>>> Endpoint Discovery: To determine the current or historic > presence of > > >>>>> endpoints in the environment that are available for posture > > assessment. > > >>>>> > > >>>>> Endpoint Characterization: The act of acquiring, through > automated > > >>>>> collection or manual input, and organizing attributes > associated > > >>>>> with an endpoint (e.g., type, organizationally expected > > >>>>> function/role, hardware/software versions) that can be used to > > >>>>> evaluate organizational policies that determine what endpoints > > >>>>> should be posture > > >>>> assessed. > > >>>> > > >>>> > > >>>> Just end this definition at the end of the parenthetical > expression, > > >>>> which also removes the need for the following "Identify Endpoint > > >> Targets" definition. > > >>>> > > >>>> Classification is for both finding the appropriate content > for an > > >>>> endpoint and for finding which endpoints content applies to. > > >>>> Examples for both uses could be simply stated, if necessary. > > >>>> > > >>> > > >>> I am fine with dropping the text "that can be used to evaluate > > >> organizational policies that determine what endpoints should > be posture > > >> assessed", since this is somewhat redundant with the modified text > > under > > >> "Identify Endpoint Targets". > > >>> > > >>> The existing text in (-05) includes a definition for > "Identify Endpoint > > >> Targets". I modified the existing text to tie together the > classification and > > >> targeting concepts. IMHO this addresses finding which > endpoints content > > >> applies to. The text under "Collection Content Acquisition" and > > "Evaluation > > >> Content Acquisition" addresses finding the appropriate content > for an > > >> endpoint for collection and evaluation. > > >>> > > >>> To be more clear about what the change to "Identify Endpoint > Targets" > > >> entails, here is the original text: > > >>> > > >>> Identify Endpoint Targets: To identify what potential endpoint > > >>> targets the checklist should apply to based on > organizational > > >>> policies. > > >>> > > >>> The new text adds the text in brackets: > > >>> > > >>> Identify Endpoint Targets: To identify what potential endpoint > > >>> targets the checklist should apply to based on > [evaluating] > > >> organizational > > >>> policies [against known endpoint attributes]. > > >>> > > >>> Based on this discussion the complete text might be modified to: > > >>> > > >>> Endpoint Discovery: To determine the current or historic > presence of > > >>> endpoints in the environment that are available > for posture > > >> assessment. > > >>> > > >>> Endpoint Characterization: The act of acquiring, through > automated > > >>> collection or manual input, and organizing > attributes associated > > with > > >>> an endpoint (e.g., type, organizationally expected > function/role, > > >>> hardware/software versions). > > >>> > > >>> Identify Endpoint Targets: To identify what potential endpoint > > >>> targets the checklist should apply to based on > evaluating > > >> organizational > > >>> policies against known endpoint attributes. > > >>> > > >>> How about this? > > >>> > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > From david.waltermire@nist.gov Wed Feb 5 17:02:15 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D601A0202 for ; Wed, 5 Feb 2014 17:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF2S5ZY-g05d for ; Wed, 5 Feb 2014 17:02:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0478D1A011B for ; Wed, 5 Feb 2014 17:02:11 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 01:02:10 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 01:02:09 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , Ira McDonald Thread-Topic: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting Thread-Index: Ac8ip4YavIuzj5GPS3G7cT9B5maaAQABbooAAAAq3iAACHq0gAAATnnwAABq5YAAAMNbAAAAIiBw Date: Thu, 6 Feb 2014 01:02:09 +0000 Message-ID: <57f27aeea674492faf8c30a3cd05b2ec@BLUPR09MB038.namprd09.prod.outlook.com> References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2D2F3.5070009@ThreatGuard.com> <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2DCEE.4080007@ThreatGuard.com> In-Reply-To: <52F2DCEE.4080007@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(51704005)(479174003)(377454003)(54094003)(199002)(13464003)(189002)(81816001)(56816005)(85852003)(63696002)(87266001)(83072002)(15975445006)(94946001)(80022001)(65816001)(74876001)(93516002)(54356001)(93136001)(74706001)(92566001)(59766001)(66066001)(46102001)(51856001)(53806001)(54316002)(76482001)(56776001)(77982001)(2656002)(79102001)(94316002)(86362001)(4396001)(87936001)(81686001)(47446002)(85306002)(90146001)(74502001)(80976001)(81542001)(76786001)(81342001)(19580405001)(47736001)(19580395003)(31966008)(50986001)(49866001)(33646001)(83322001)(47976001)(76576001)(69226001)(76796001)(74662001)(77096001)(74316001)(74366001)(95416001)(21314002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EEACF22C.A6E25958.71DFB76F.CAECD941.20570; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:02:15 -0000 How about a slight refinement of that: "Content describing the assessment to be performed may contain instructions= or references used to determine the applicable assessment targets." > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Wednesday, February 05, 2014 7:53 PM > To: Ira McDonald; Waltermire, David A. > Cc: David Harrington; sacm@ietf.org > Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint > Discovery/Characterization/Targeting >=20 >=20 >=20 > On 2/5/2014 7:31 PM, Ira McDonald wrote: > > Hi Dave, > > > > I like this Identify Endpoint Targets text better. > > > > Cheers, > > - Ira >=20 >=20 > I second that, but I wonder if somebody new to this would have further > questions. >=20 > For example: >=20 > "Content may describe the applicable targets for assessment" >=20 > Does that say that the content will have something like a list of the tar= get IP > addresses? >=20 >=20 > How about: >=20 > "Content may contain instructions or references used to determine its > applicability." >=20 >=20 >=20 >=20 > "In this case the Content Query and/or Content Retrieval building blocks > (see section XXX) may be used to acquire this content for processing." >=20 > Is that to say that the content may refer to other content, which must > be retrieved and applied in order to determine applicability? And > therefore that referenced content could also contain content references > that need to be resolved? >=20 > Is it also possible for this content to be entirely self-contained in > that it also contains all the instructions necessary for determining its > own applicability? >=20 >=20 > If that's what's covered in section XXX then.....cool! >=20 >=20 > > > > > > On Wed, Feb 5, 2014 at 7:25 PM, Waltermire, David A. > > > wrote: > > > > I just noticed that I dropped some of the original text for this > > entry. How about the following that adds this text back in? > > > > Identify Endpoint Targets: Determine the candidate endpoint target= (s) > > against which to perform the assessment. Depending > > on the assessment trigger, a > > single endpoint or multiple endpoints may be > > targeted based on characterized > > endpoint attributes. Content may describe the > > applicable targets for assessment. In > > this case the Content Query and/or Content > > Retrieval building blocks (see section > > XXX) may be used to acquire this content for > > processing. > > > > Dave > > > > > -----Original Message----- > > > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com > > ] > > > Sent: Wednesday, February 05, 2014 7:10 PM > > > To: Waltermire, David A.; David Harrington; sacm@ietf.org > > > > > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > > > Discovery/Characterization/Targeting > > > > > > > > > How about: > > > > > > Identify Endpoint Targets: Using target attributes to determine= the > > > applicability of each to a given content item(s). > > > > > > > > > > > > On 2/5/2014 3:11 PM, Waltermire, David A. wrote: > > > > I don't find the text to be restrictive since any set of > > endpoint attributes > > > can be used (including aspects of posture). If we kept the text, > > what would > > > not be supported for targeting? > > > > > > > > Dave > > > > > > > >> -----Original Message----- > > > >> From: Gunnar Engelbach > > [mailto:Gunnar.Engelbach@ThreatGuard.com > > ] > > > >> Sent: Wednesday, February 05, 2014 3:03 PM > > > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org > > > > > >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > > > >> Discovery/Characterization/Targeting > > > >> > > > >> > > > >> > > > >> With that change to "Endpoint Characterization" I find > > "Identify Endpoint > > > >> Targets" to be redundant. > > > >> > > > >> However, if "Identify Endpoint Targets" is kept, I'd suggest > > dropping the > > > >> clause > > > >> > > > >> "...based on evaluating organizational policies against > > known endpoint > > > >> attributes." > > > >> > > > >> That makes a restrictive assumption about how it can be used. > > > >> > > > >> > > > >> > > > >> > > > >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > > > >>> Gunnar, > > > >>> > > > >>> I'm changing the subject and trimming the thread to focus on > > the single > > > >> point of discussion. > > > >>> > > > >>> Please find my feedback on your comment below. > > > >>> > > > >>> Dave > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: sacm [mailto:sacm-bounces@ietf.org > > ] On Behalf Of Gunnar > > > >>>> Engelbach > > > >>>> Sent: Wednesday, February 05, 2014 1:42 PM > > > >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org > > > > > >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 > > > >>>> > > > >>>> > > > >>>> All of this looks good to me, with one additional comment > > near the > > > >> bottom... > > > >>>> > > > >>>> > > > >>>> --gun > > > >>>> > > > >>>> > > > >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > > > >>>>> > > > >>>>> 4) in 2.1.2, > > > >>>>> > > > >>>>> Endpoint Discovery: The purpose of discovery is to > > determine the > > > >>>>> type of endpoint to be posture assessed. > > > >>>>> > > > >>>>> QUESTION: Is it just the type? Or is it to > > identify what > > > >>>>> endpoint instances to target for assessment us= ing > > > >>>>> metadata such > > > >>>>> > > > >>>>> as the endpoint's organizationally expected > > type (e.g., > > > >>>>> > > > >>>>> expected function/role, etc.) > > > >>>>> > > > >>>>> If this is truly endpoint "discovery", then I think this > > building > > > >>>>> block discovers the whole set of endpoints it can see in > > the network > > > >>>>> - i.e., the whole set of endpoints that might be able to b= e > > assessed. > > > >>>>> > > > >>>>> In the next step (targeting), that building block selects = a > > subset > > > >>>>> of the discovered set of endpoints, based on such things a= s > > type of > > > >>>>> endpoint, organizationally expected function/role, version= , > > etc. > > > >>>>> > > > >>>>> [DAW: The discussion on the call resulted in the > > identification of > > > >>>>> two distinct concepts, Endpoint Discovery and Endpoint > > > >>>>> Characterization, that are needed to support the > > identification of > > > >>>>> what endpoints should be targeted for an assessment. Both > > of these > > > >>>>> concepts have been combined in the current "Endpoint > Discovery" > > > >>>>> building block. There was agreement that these two aspects > > should > > > be > > > >>>>> broken out into distinct building block items. I took the > > action to > > > propose > > > >> some new text. > > > >>>>> Please let us know if you have any objections or suggested > > changes > > > >>>>> to the following proposed > > > >>>>> change: > > > >>>>> > > > >>>>> Endpoint Discovery: To determine the current or historic > > presence of > > > >>>>> endpoints in the environment that are available for postur= e > > > assessment. > > > >>>>> > > > >>>>> Endpoint Characterization: The act of acquiring, through > > automated > > > >>>>> collection or manual input, and organizing attributes > > associated > > > >>>>> with an endpoint (e.g., type, organizationally expected > > > >>>>> function/role, hardware/software versions) that can be use= d to > > > >>>>> evaluate organizational policies that determine what endpo= ints > > > >>>>> should be posture > > > >>>> assessed. > > > >>>> > > > >>>> > > > >>>> Just end this definition at the end of the parenthetical > > expression, > > > >>>> which also removes the need for the following "Identify End= point > > > >> Targets" definition. > > > >>>> > > > >>>> Classification is for both finding the appropriate content > > for an > > > >>>> endpoint and for finding which endpoints content applies to= . > > > >>>> Examples for both uses could be simply stated, if necessary= . > > > >>>> > > > >>> > > > >>> I am fine with dropping the text "that can be used to evalua= te > > > >> organizational policies that determine what endpoints should > > be posture > > > >> assessed", since this is somewhat redundant with the modified= text > > > under > > > >> "Identify Endpoint Targets". > > > >>> > > > >>> The existing text in (-05) includes a definition for > > "Identify Endpoint > > > >> Targets". I modified the existing text to tie together the > > classification and > > > >> targeting concepts. IMHO this addresses finding which > > endpoints content > > > >> applies to. The text under "Collection Content Acquisition" a= nd > > > "Evaluation > > > >> Content Acquisition" addresses finding the appropriate conten= t > > for an > > > >> endpoint for collection and evaluation. > > > >>> > > > >>> To be more clear about what the change to "Identify Endpoint > > Targets" > > > >> entails, here is the original text: > > > >>> > > > >>> Identify Endpoint Targets: To identify what potential endpo= int > > > >>> targets the checklist should apply to based on > > organizational > > > >>> policies. > > > >>> > > > >>> The new text adds the text in brackets: > > > >>> > > > >>> Identify Endpoint Targets: To identify what potential endpo= int > > > >>> targets the checklist should apply to based on > > [evaluating] > > > >> organizational > > > >>> policies [against known endpoint attributes]. > > > >>> > > > >>> Based on this discussion the complete text might be modified= to: > > > >>> > > > >>> Endpoint Discovery: To determine the current or historic > > presence of > > > >>> endpoints in the environment that are available > > for posture > > > >> assessment. > > > >>> > > > >>> Endpoint Characterization: The act of acquiring, through > > automated > > > >>> collection or manual input, and organizing > > attributes associated > > > with > > > >>> an endpoint (e.g., type, organizationally expecte= d > > function/role, > > > >>> hardware/software versions). > > > >>> > > > >>> Identify Endpoint Targets: To identify what potential endpo= int > > > >>> targets the checklist should apply to based on > > evaluating > > > >> organizational > > > >>> policies against known endpoint attributes. > > > >>> > > > >>> How about this? > > > >>> > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > From gunnar.engelbach@threatguard.com Wed Feb 5 17:53:24 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8AF1A0237 for ; Wed, 5 Feb 2014 17:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaOHdPv1hoka for ; Wed, 5 Feb 2014 17:53:18 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 151391A0266 for ; Wed, 5 Feb 2014 17:53:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=JIOdwkKKqkPvLXW5kK9I9Lk5MJnm9n0nQiyTWKp8EAOyVlqHXcmy4ex+kLuc9hM3p9yNaFpn6cGQy083OQHeV0BFkPX1WdE8HFCZI+dhZNIcvLwG50UtGStH2ahz0nB3; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23225 invoked from network); 5 Feb 2014 17:59:43 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 17:59:43 -0800 Message-ID: <52F2EB1A.4030603@ThreatGuard.com> Date: Wed, 05 Feb 2014 20:53:30 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Waltermire, David A." , Ira McDonald References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2D2F3.5070009@ThreatGuard.com> <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2DCEE.4080007@ThreatGuard.com> <57f27aeea674492faf8c30a3cd05b2ec@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <57f27aeea674492faf8c30a3cd05b2ec@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:53:24 -0000 On 2/5/2014 8:02 PM, Waltermire, David A. wrote: > How about a slight refinement of that: > > "Content describing the assessment to be performed may contain instructions or references used to determine the applicable assessment targets." Works for me. > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Wednesday, February 05, 2014 7:53 PM >> To: Ira McDonald; Waltermire, David A. >> Cc: David Harrington; sacm@ietf.org >> Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint >> Discovery/Characterization/Targeting >> >> >> >> On 2/5/2014 7:31 PM, Ira McDonald wrote: >>> Hi Dave, >>> >>> I like this Identify Endpoint Targets text better. >>> >>> Cheers, >>> - Ira >> >> >> I second that, but I wonder if somebody new to this would have further >> questions. >> >> For example: >> >> "Content may describe the applicable targets for assessment" >> >> Does that say that the content will have something like a list of the target IP >> addresses? >> >> >> How about: >> >> "Content may contain instructions or references used to determine its >> applicability." >> >> >> >> >> "In this case the Content Query and/or Content Retrieval building blocks >> (see section XXX) may be used to acquire this content for processing." >> >> Is that to say that the content may refer to other content, which must >> be retrieved and applied in order to determine applicability? And >> therefore that referenced content could also contain content references >> that need to be resolved? >> >> Is it also possible for this content to be entirely self-contained in >> that it also contains all the instructions necessary for determining its >> own applicability? >> >> >> If that's what's covered in section XXX then.....cool! >> >> >>> >>> >>> On Wed, Feb 5, 2014 at 7:25 PM, Waltermire, David A. >>> > wrote: >>> >>> I just noticed that I dropped some of the original text for this >>> entry. How about the following that adds this text back in? >>> >>> Identify Endpoint Targets: Determine the candidate endpoint target(s) >>> against which to perform the assessment. Depending >>> on the assessment trigger, a >>> single endpoint or multiple endpoints may be >>> targeted based on characterized >>> endpoint attributes. Content may describe the >>> applicable targets for assessment. In >>> this case the Content Query and/or Content >>> Retrieval building blocks (see section >>> XXX) may be used to acquire this content for >>> processing. >>> >>> Dave >>> >>> > -----Original Message----- >>> > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com >>> ] >>> > Sent: Wednesday, February 05, 2014 7:10 PM >>> > To: Waltermire, David A.; David Harrington; sacm@ietf.org >>> >>> > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint >>> > Discovery/Characterization/Targeting >>> > >>> > >>> > How about: >>> > >>> > Identify Endpoint Targets: Using target attributes to determine the >>> > applicability of each to a given content item(s). >>> > >>> > >>> > >>> > On 2/5/2014 3:11 PM, Waltermire, David A. wrote: >>> > > I don't find the text to be restrictive since any set of >>> endpoint attributes >>> > can be used (including aspects of posture). If we kept the text, >>> what would >>> > not be supported for targeting? >>> > > >>> > > Dave >>> > > >>> > >> -----Original Message----- >>> > >> From: Gunnar Engelbach >>> [mailto:Gunnar.Engelbach@ThreatGuard.com >>> ] >>> > >> Sent: Wednesday, February 05, 2014 3:03 PM >>> > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org >>> >>> > >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint >>> > >> Discovery/Characterization/Targeting >>> > >> >>> > >> >>> > >> >>> > >> With that change to "Endpoint Characterization" I find >>> "Identify Endpoint >>> > >> Targets" to be redundant. >>> > >> >>> > >> However, if "Identify Endpoint Targets" is kept, I'd suggest >>> dropping the >>> > >> clause >>> > >> >>> > >> "...based on evaluating organizational policies against >>> known endpoint >>> > >> attributes." >>> > >> >>> > >> That makes a restrictive assumption about how it can be used. >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: >>> > >>> Gunnar, >>> > >>> >>> > >>> I'm changing the subject and trimming the thread to focus on >>> the single >>> > >> point of discussion. >>> > >>> >>> > >>> Please find my feedback on your comment below. >>> > >>> >>> > >>> Dave >>> > >>> >>> > >>>> -----Original Message----- >>> > >>>> From: sacm [mailto:sacm-bounces@ietf.org >>> ] On Behalf Of Gunnar >>> > >>>> Engelbach >>> > >>>> Sent: Wednesday, February 05, 2014 1:42 PM >>> > >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.org >>> >>> > >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-5 >>> > >>>> >>> > >>>> >>> > >>>> All of this looks good to me, with one additional comment >>> near the >>> > >> bottom... >>> > >>>> >>> > >>>> >>> > >>>> --gun >>> > >>>> >>> > >>>> >>> > >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: >>> > >>>>> >>> > >>>>> 4) in 2.1.2, >>> > >>>>> >>> > >>>>> Endpoint Discovery: The purpose of discovery is to >>> determine the >>> > >>>>> type of endpoint to be posture assessed. >>> > >>>>> >>> > >>>>> QUESTION: Is it just the type? Or is it to >>> identify what >>> > >>>>> endpoint instances to target for assessment using >>> > >>>>> metadata such >>> > >>>>> >>> > >>>>> as the endpoint's organizationally expected >>> type (e.g., >>> > >>>>> >>> > >>>>> expected function/role, etc.) >>> > >>>>> >>> > >>>>> If this is truly endpoint "discovery", then I think this >>> building >>> > >>>>> block discovers the whole set of endpoints it can see in >>> the network >>> > >>>>> - i.e., the whole set of endpoints that might be able to be >>> assessed. >>> > >>>>> >>> > >>>>> In the next step (targeting), that building block selects a >>> subset >>> > >>>>> of the discovered set of endpoints, based on such things as >>> type of >>> > >>>>> endpoint, organizationally expected function/role, version, >>> etc. >>> > >>>>> >>> > >>>>> [DAW: The discussion on the call resulted in the >>> identification of >>> > >>>>> two distinct concepts, Endpoint Discovery and Endpoint >>> > >>>>> Characterization, that are needed to support the >>> identification of >>> > >>>>> what endpoints should be targeted for an assessment. Both >>> of these >>> > >>>>> concepts have been combined in the current "Endpoint >> Discovery" >>> > >>>>> building block. There was agreement that these two aspects >>> should >>> > be >>> > >>>>> broken out into distinct building block items. I took the >>> action to >>> > propose >>> > >> some new text. >>> > >>>>> Please let us know if you have any objections or suggested >>> changes >>> > >>>>> to the following proposed >>> > >>>>> change: >>> > >>>>> >>> > >>>>> Endpoint Discovery: To determine the current or historic >>> presence of >>> > >>>>> endpoints in the environment that are available for posture >>> > assessment. >>> > >>>>> >>> > >>>>> Endpoint Characterization: The act of acquiring, through >>> automated >>> > >>>>> collection or manual input, and organizing attributes >>> associated >>> > >>>>> with an endpoint (e.g., type, organizationally expected >>> > >>>>> function/role, hardware/software versions) that can be used to >>> > >>>>> evaluate organizational policies that determine what endpoints >>> > >>>>> should be posture >>> > >>>> assessed. >>> > >>>> >>> > >>>> >>> > >>>> Just end this definition at the end of the parenthetical >>> expression, >>> > >>>> which also removes the need for the following "Identify Endpoint >>> > >> Targets" definition. >>> > >>>> >>> > >>>> Classification is for both finding the appropriate content >>> for an >>> > >>>> endpoint and for finding which endpoints content applies to. >>> > >>>> Examples for both uses could be simply stated, if necessary. >>> > >>>> >>> > >>> >>> > >>> I am fine with dropping the text "that can be used to evaluate >>> > >> organizational policies that determine what endpoints should >>> be posture >>> > >> assessed", since this is somewhat redundant with the modified text >>> > under >>> > >> "Identify Endpoint Targets". >>> > >>> >>> > >>> The existing text in (-05) includes a definition for >>> "Identify Endpoint >>> > >> Targets". I modified the existing text to tie together the >>> classification and >>> > >> targeting concepts. IMHO this addresses finding which >>> endpoints content >>> > >> applies to. The text under "Collection Content Acquisition" and >>> > "Evaluation >>> > >> Content Acquisition" addresses finding the appropriate content >>> for an >>> > >> endpoint for collection and evaluation. >>> > >>> >>> > >>> To be more clear about what the change to "Identify Endpoint >>> Targets" >>> > >> entails, here is the original text: >>> > >>> >>> > >>> Identify Endpoint Targets: To identify what potential endpoint >>> > >>> targets the checklist should apply to based on >>> organizational >>> > >>> policies. >>> > >>> >>> > >>> The new text adds the text in brackets: >>> > >>> >>> > >>> Identify Endpoint Targets: To identify what potential endpoint >>> > >>> targets the checklist should apply to based on >>> [evaluating] >>> > >> organizational >>> > >>> policies [against known endpoint attributes]. >>> > >>> >>> > >>> Based on this discussion the complete text might be modified to: >>> > >>> >>> > >>> Endpoint Discovery: To determine the current or historic >>> presence of >>> > >>> endpoints in the environment that are available >>> for posture >>> > >> assessment. >>> > >>> >>> > >>> Endpoint Characterization: The act of acquiring, through >>> automated >>> > >>> collection or manual input, and organizing >>> attributes associated >>> > with >>> > >>> an endpoint (e.g., type, organizationally expected >>> function/role, >>> > >>> hardware/software versions). >>> > >>> >>> > >>> Identify Endpoint Targets: To identify what potential endpoint >>> > >>> targets the checklist should apply to based on >>> evaluating >>> > >> organizational >>> > >>> policies against known endpoint attributes. >>> > >>> >>> > >>> How about this? >>> > >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >>> From david.waltermire@nist.gov Wed Feb 5 17:56:45 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE31A0277 for ; Wed, 5 Feb 2014 17:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eJg7kp6dqFX for ; Wed, 5 Feb 2014 17:56:42 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id 486541A0207 for ; Wed, 5 Feb 2014 17:56:42 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 01:56:39 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 01:56:39 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , Ira McDonald Thread-Topic: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting Thread-Index: Ac8ip4YavIuzj5GPS3G7cT9B5maaAQABbooAAAAq3iAACHq0gAAATnnwAABq5YAAAMNbAAAAIiBwAAH6fQAAAAhSIA== Date: Thu, 6 Feb 2014 01:56:38 +0000 Message-ID: <568b3069f396469a8005321027801c45@BLUPR09MB038.namprd09.prod.outlook.com> References: <28d92e2d8cb741aaa06a7d39be0da9f5@BLUPR09MB038.namprd09.prod.outlook.com> <52F298EC.6080101@ThreatGuard.com> <80a229767be24030bf17352a5e157c9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2D2F3.5070009@ThreatGuard.com> <5830b1957f68465c91f0f1ae3a4e7b9f@BLUPR09MB038.namprd09.prod.outlook.com> <52F2DCEE.4080007@ThreatGuard.com> <57f27aeea674492faf8c30a3cd05b2ec@BLUPR09MB038.namprd09.prod.outlook.com> <52F2EB1A.4030603@ThreatGuard.com> In-Reply-To: <52F2EB1A.4030603@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(479174003)(377454003)(164054003)(51704005)(54094003)(13464003)(189002)(199002)(53806001)(54356001)(85306002)(2656002)(92566001)(81686001)(90146001)(54316002)(76482001)(46102001)(94946001)(47736001)(65816001)(94316002)(4396001)(74876001)(74502001)(93516002)(15975445006)(87266001)(77982001)(51856001)(83072002)(81816001)(85852003)(56776001)(93136001)(86362001)(59766001)(63696002)(79102001)(95416001)(80022001)(56816005)(74706001)(66066001)(47446002)(87936001)(49866001)(33646001)(80976001)(81342001)(74662001)(31966008)(47976001)(50986001)(74316001)(19580395003)(83322001)(19580405001)(77096001)(81542001)(76576001)(69226001)(76796001)(74366001)(76786001)(21314002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EEACF22C.A6E25958.71DFB76F.CAECD941.2058F; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint Discovery/Characterization/Targeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:56:46 -0000 Here is the updated text for the modified building block entries in section= 2.1.2: Endpoint Discovery: To determine the current or historic presence of endpoints in the environment that are available for posture assessment. Endpoint Characterization: The act of acquiring, through automated collection or manual input, and organizing attributes associated with an endpoint (e.g., type, organizationally expected function/role, hardware/software versions). Identify Endpoint Targets: Determine the candidate endpoint target(s) against which to perform the assessment. Depending on the assessment trigger, a single endpoint or multiple endpoints may be targeted based on characterized endpoint attributes. Content describing the assessment to be performed may contain instructions or references used to determine the applicable assessment targets. In this case the Content Query and/or Content Retrieval building blocks (see section 2.1.1) may be used to acquire this content. Any additional concerns with this text? Thanks, Dave > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Wednesday, February 05, 2014 8:54 PM > To: Waltermire, David A.; Ira McDonald > Cc: David Harrington; sacm@ietf.org > Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint > Discovery/Characterization/Targeting >=20 >=20 >=20 > On 2/5/2014 8:02 PM, Waltermire, David A. wrote: > > How about a slight refinement of that: > > > > "Content describing the assessment to be performed may contain > instructions or references used to determine the applicable assessment > targets." >=20 >=20 > Works for me. >=20 >=20 >=20 >=20 > > > >> -----Original Message----- > >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > >> Sent: Wednesday, February 05, 2014 7:53 PM > >> To: Ira McDonald; Waltermire, David A. > >> Cc: David Harrington; sacm@ietf.org > >> Subject: Re: [sacm] QUESTION on UCs Section 2.1.2 Regarding Endpoint > >> Discovery/Characterization/Targeting > >> > >> > >> > >> On 2/5/2014 7:31 PM, Ira McDonald wrote: > >>> Hi Dave, > >>> > >>> I like this Identify Endpoint Targets text better. > >>> > >>> Cheers, > >>> - Ira > >> > >> > >> I second that, but I wonder if somebody new to this would have > >> further questions. > >> > >> For example: > >> > >> "Content may describe the applicable targets for assessment" > >> > >> Does that say that the content will have something like a list of the > >> target IP addresses? > >> > >> > >> How about: > >> > >> "Content may contain instructions or references used to determine its > >> applicability." > >> > >> > >> > >> > >> "In this case the Content Query and/or Content Retrieval building > >> blocks (see section XXX) may be used to acquire this content for > processing." > >> > >> Is that to say that the content may refer to other content, which > >> must be retrieved and applied in order to determine applicability? > >> And therefore that referenced content could also contain content > >> references that need to be resolved? > >> > >> Is it also possible for this content to be entirely self-contained in > >> that it also contains all the instructions necessary for determining > >> its own applicability? > >> > >> > >> If that's what's covered in section XXX then.....cool! > >> > >> > >>> > >>> > >>> On Wed, Feb 5, 2014 at 7:25 PM, Waltermire, David A. > >>> > > wrote: > >>> > >>> I just noticed that I dropped some of the original text for this > >>> entry. How about the following that adds this text back in? > >>> > >>> Identify Endpoint Targets: Determine the candidate endpoint > target(s) > >>> against which to perform the assessment. Depend= ing > >>> on the assessment trigger, a > >>> single endpoint or multiple endpoints may be > >>> targeted based on characterized > >>> endpoint attributes. Content may describe the > >>> applicable targets for assessment. In > >>> this case the Content Query and/or Content > >>> Retrieval building blocks (see section > >>> XXX) may be used to acquire this content for > >>> processing. > >>> > >>> Dave > >>> > >>> > -----Original Message----- > >>> > From: Gunnar Engelbach > [mailto:Gunnar.Engelbach@ThreatGuard.com > >>> ] > >>> > Sent: Wednesday, February 05, 2014 7:10 PM > >>> > To: Waltermire, David A.; David Harrington; sacm@ietf.org > >>> > >>> > Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpoint > >>> > Discovery/Characterization/Targeting > >>> > > >>> > > >>> > How about: > >>> > > >>> > Identify Endpoint Targets: Using target attributes to determ= ine the > >>> > applicability of each to a given content item(s). > >>> > > >>> > > >>> > > >>> > On 2/5/2014 3:11 PM, Waltermire, David A. wrote: > >>> > > I don't find the text to be restrictive since any set of > >>> endpoint attributes > >>> > can be used (including aspects of posture). If we kept the te= xt, > >>> what would > >>> > not be supported for targeting? > >>> > > > >>> > > Dave > >>> > > > >>> > >> -----Original Message----- > >>> > >> From: Gunnar Engelbach > >>> [mailto:Gunnar.Engelbach@ThreatGuard.com > >>> ] > >>> > >> Sent: Wednesday, February 05, 2014 3:03 PM > >>> > >> To: Waltermire, David A.; David Harrington; sacm@ietf.org > >>> > >>> > >> Subject: Re: QUESTION on UCs Section 2.1.2 Regarding Endpo= int > >>> > >> Discovery/Characterization/Targeting > >>> > >> > >>> > >> > >>> > >> > >>> > >> With that change to "Endpoint Characterization" I find > >>> "Identify Endpoint > >>> > >> Targets" to be redundant. > >>> > >> > >>> > >> However, if "Identify Endpoint Targets" is kept, I'd sugge= st > >>> dropping the > >>> > >> clause > >>> > >> > >>> > >> "...based on evaluating organizational policies agains= t > >>> known endpoint > >>> > >> attributes." > >>> > >> > >>> > >> That makes a restrictive assumption about how it can be us= ed. > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> On 2/5/2014 2:24 PM, Waltermire, David A. wrote: > >>> > >>> Gunnar, > >>> > >>> > >>> > >>> I'm changing the subject and trimming the thread to focus= on > >>> the single > >>> > >> point of discussion. > >>> > >>> > >>> > >>> Please find my feedback on your comment below. > >>> > >>> > >>> > >>> Dave > >>> > >>> > >>> > >>>> -----Original Message----- > >>> > >>>> From: sacm [mailto:sacm-bounces@ietf.org > >>> ] On Behalf Of Gunnar > >>> > >>>> Engelbach > >>> > >>>> Sent: Wednesday, February 05, 2014 1:42 PM > >>> > >>>> To: Waltermire, David A.; David Harrington; sacm@ietf.or= g > >>> > >>> > >>>> Subject: Re: [sacm] Consensus on QUESTIONS in use-cases-= 5 > >>> > >>>> > >>> > >>>> > >>> > >>>> All of this looks good to me, with one additional commen= t > >>> near the > >>> > >> bottom... > >>> > >>>> > >>> > >>>> > >>> > >>>> --gun > >>> > >>>> > >>> > >>>> > >>> > >>>> On 2/5/2014 12:29 PM, Waltermire, David A. wrote: > >>> > >>>>> > >>> > >>>>> 4) in 2.1.2, > >>> > >>>>> > >>> > >>>>> Endpoint Discovery: The purpose of discovery is to > >>> determine the > >>> > >>>>> type of endpoint to be posture assessed. > >>> > >>>>> > >>> > >>>>> QUESTION: Is it just the type? Or is it to > >>> identify what > >>> > >>>>> endpoint instances to target for assessment= using > >>> > >>>>> metadata such > >>> > >>>>> > >>> > >>>>> as the endpoint's organizationally expected > >>> type (e.g., > >>> > >>>>> > >>> > >>>>> expected function/role, etc.) > >>> > >>>>> > >>> > >>>>> If this is truly endpoint "discovery", then I think thi= s > >>> building > >>> > >>>>> block discovers the whole set of endpoints it can see i= n > >>> the network > >>> > >>>>> - i.e., the whole set of endpoints that might be able t= o be > >>> assessed. > >>> > >>>>> > >>> > >>>>> In the next step (targeting), that building block selec= ts a > >>> subset > >>> > >>>>> of the discovered set of endpoints, based on such thing= s as > >>> type of > >>> > >>>>> endpoint, organizationally expected function/role, vers= ion, > >>> etc. > >>> > >>>>> > >>> > >>>>> [DAW: The discussion on the call resulted in the > >>> identification of > >>> > >>>>> two distinct concepts, Endpoint Discovery and Endpoint > >>> > >>>>> Characterization, that are needed to support the > >>> identification of > >>> > >>>>> what endpoints should be targeted for an assessment. Bo= th > >>> of these > >>> > >>>>> concepts have been combined in the current "Endpoint > >> Discovery" > >>> > >>>>> building block. There was agreement that these two aspe= cts > >>> should > >>> > be > >>> > >>>>> broken out into distinct building block items. I took t= he > >>> action to > >>> > propose > >>> > >> some new text. > >>> > >>>>> Please let us know if you have any objections or sugges= ted > >>> changes > >>> > >>>>> to the following proposed > >>> > >>>>> change: > >>> > >>>>> > >>> > >>>>> Endpoint Discovery: To determine the current or histori= c > >>> presence of > >>> > >>>>> endpoints in the environment that are available for pos= ture > >>> > assessment. > >>> > >>>>> > >>> > >>>>> Endpoint Characterization: The act of acquiring, throug= h > >>> automated > >>> > >>>>> collection or manual input, and organizing attributes > >>> associated > >>> > >>>>> with an endpoint (e.g., type, organizationally expected > >>> > >>>>> function/role, hardware/software versions) that can be = used > to > >>> > >>>>> evaluate organizational policies that determine what > endpoints > >>> > >>>>> should be posture > >>> > >>>> assessed. > >>> > >>>> > >>> > >>>> > >>> > >>>> Just end this definition at the end of the parenthetical > >>> expression, > >>> > >>>> which also removes the need for the following "Identify > Endpoint > >>> > >> Targets" definition. > >>> > >>>> > >>> > >>>> Classification is for both finding the appropriate conte= nt > >>> for an > >>> > >>>> endpoint and for finding which endpoints content applies= to. > >>> > >>>> Examples for both uses could be simply stated, if necess= ary. > >>> > >>>> > >>> > >>> > >>> > >>> I am fine with dropping the text "that can be used to eva= luate > >>> > >> organizational policies that determine what endpoints shou= ld > >>> be posture > >>> > >> assessed", since this is somewhat redundant with the modif= ied > text > >>> > under > >>> > >> "Identify Endpoint Targets". > >>> > >>> > >>> > >>> The existing text in (-05) includes a definition for > >>> "Identify Endpoint > >>> > >> Targets". I modified the existing text to tie together the > >>> classification and > >>> > >> targeting concepts. IMHO this addresses finding which > >>> endpoints content > >>> > >> applies to. The text under "Collection Content Acquisition= " and > >>> > "Evaluation > >>> > >> Content Acquisition" addresses finding the appropriate con= tent > >>> for an > >>> > >> endpoint for collection and evaluation. > >>> > >>> > >>> > >>> To be more clear about what the change to "Identify Endpo= int > >>> Targets" > >>> > >> entails, here is the original text: > >>> > >>> > >>> > >>> Identify Endpoint Targets: To identify what potential en= dpoint > >>> > >>> targets the checklist should apply to based on > >>> organizational > >>> > >>> policies. > >>> > >>> > >>> > >>> The new text adds the text in brackets: > >>> > >>> > >>> > >>> Identify Endpoint Targets: To identify what potential en= dpoint > >>> > >>> targets the checklist should apply to based on > >>> [evaluating] > >>> > >> organizational > >>> > >>> policies [against known endpoint attributes]. > >>> > >>> > >>> > >>> Based on this discussion the complete text might be modif= ied > to: > >>> > >>> > >>> > >>> Endpoint Discovery: To determine the current or historic > >>> presence of > >>> > >>> endpoints in the environment that are availabl= e > >>> for posture > >>> > >> assessment. > >>> > >>> > >>> > >>> Endpoint Characterization: The act of acquiring, through > >>> automated > >>> > >>> collection or manual input, and organizing > >>> attributes associated > >>> > with > >>> > >>> an endpoint (e.g., type, organizationally expe= cted > >>> function/role, > >>> > >>> hardware/software versions). > >>> > >>> > >>> > >>> Identify Endpoint Targets: To identify what potential en= dpoint > >>> > >>> targets the checklist should apply to based on > >>> evaluating > >>> > >> organizational > >>> > >>> policies against known endpoint attributes. > >>> > >>> > >>> > >>> How about this? > >>> > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >>> > >>> From shanna@juniper.net Wed Feb 5 18:13:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8A1A0214 for ; Wed, 5 Feb 2014 18:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlx6CvtoaFBR for ; Wed, 5 Feb 2014 18:13:51 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id A26791A0207 for ; Wed, 5 Feb 2014 18:13:51 -0800 (PST) Received: from mail195-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE028.bigfish.com (10.243.66.91) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Feb 2014 02:13:50 +0000 Received: from mail195-co1 (localhost [127.0.0.1]) by mail195-co1-R.bigfish.com (Postfix) with ESMTP id 72FD9180121; Thu, 6 Feb 2014 02:13:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1432I1418I4015I168aJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h9a9j1155h) Received-SPF: pass (mail195-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(479174003)(377454003)(51444003)(164054003)(51704005)(24454002)(189002)(13464003)(199002)(57704003)(47976001)(50986001)(19580395003)(74662001)(81342001)(76796001)(74502001)(83322001)(19580405001)(76576001)(76786001)(74316001)(74366001)(69226001)(95416001)(4396001)(31966008)(15975445006)(81542001)(66066001)(81816001)(59766001)(79102001)(77982001)(33646001)(56816005)(87266001)(47736001)(81686001)(80976001)(93136001)(92566001)(80022001)(74706001)(53806001)(63696002)(93516002)(83072002)(54356001)(47446002)(87936001)(2656002)(90146001)(49866001)(85852003)(51856001)(94316002)(56776001)(86362001)(46102001)(54316002)(94946001)(65816001)(85306002)(74876001)(76482001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB737; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.12; FPR:AE6CF1D4.ABF2C142.78D13D6B.42E4F971.205EA; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail195-co1 (localhost.localdomain [127.0.0.1]) by mail195-co1 (MessageSwitch) id 1391652827759576_16059; Thu, 6 Feb 2014 02:13:47 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.233]) by mail195-co1.bigfish.com (Postfix) with ESMTP id B4908840047; Thu, 6 Feb 2014 02:13:47 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Feb 2014 02:13:47 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 6 Feb 2014 02:13:46 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 02:13:45 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 02:13:45 +0000 From: Stephen Hanna To: Gunnar Engelbach , "Waltermire, David A." , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVA= Date: Thu, 6 Feb 2014 02:13:44 +0000 Message-ID: <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> In-Reply-To: <52F2D93A.5020308@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-forefront-prvs: 0114FF88F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 02:13:55 -0000 The terms "content" and "data" are just too general. "SA content" isn't much better. It seems to include any kind of data related to security automation. In the long run, that might include lots of things like vulnerability reports and alerts that an intrusion has been detected and remediation or mitigation instructions. Also reports on endpoint compliance and attributes that have been collected from endpoints and maybe persisted. It's just not useful to use one term for all those kinds of things. I think that we need a new, more specific term for the things that Dave described below: attribute identifiers, lists of=20 attributes that are to be collected and when and perhaps how, and policies about what attribute values are acceptable for different kinds or groups of endpoints. I suggest that we use the collective term "guidance" for these things. This indicates that these things (and maybe others to be added later) guide the attribute collection and evaluation process. We also need to have a term for attribute values that have been collected from endpoints. I vote for "collected attributes". These attributes might be persisted (stored) or maybe not. Either way, they are attribute values that have been collected from endpoints. Thanks, Steve > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach > Sent: Wednesday, February 05, 2014 7:37 PM > To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis (pkampana); > sacm@ietf.org > Subject: Re: [sacm] Types of content >=20 >=20 > I would prefer to reserve the term "content" for the instructional > documentation. That is, the documents that cause an action, be it > legislation, prose guidance, or a set of machine instructions that > implement that guidance. >=20 > We typically use "system characteristics" when referring to collected > items, and variations on "endpoint attributes" has been used frequently > on this list. System characteristics are the product of applying > content to an endpoint. >=20 > Collectively it's all data. Is there a desire to have a general term > for all data that could flow through a SACM implementation but is > specific to SACM? >=20 >=20 > Also, while I agree with the need to allow the ability to persist > collected data items (and the results of posture evaluations), I don't > see that as a requirement. >=20 >=20 >=20 >=20 > On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > > Dictionaries of posture attributes was not intended to include > attribute > > values. IETF examples of this concept might include attributes in a > MIB > > or a NETMOD model. > > > > I agree that we need to "persist" posture attribute values. I have > > always been on the fence personally about calling collection and > > evaluation results "content". I agree 100% that we need to be crystal > > clear about what we mean when we use the terms "content" and "content > > repository". If we choose to lump all of this together as "content", > we > > will need to include some discussion in the use case document > > contrasting different types of content to drive discussion of content > > type-specific requirements. > > > > I also personally like Ira's feedback on using a more specific > term(s) > > instead of the more general "content". > > > > I also share the same personal view around interacting with stores of > > collected posture attribute values and evaluation results. The larger > > data volumes and rate of change will likely require different > > approaches. I also believe that the temporal nature of this data, the > > need to persist historic information, will be more significant than > > other types of data that we may call "content". > > > > Are there other opinions on this? Does anyone feel strongly that > > collected posture attribute values and evaluation results SHOULD NOT > be > > considered content? > > > > Thanks, > > > > Dave > > > > *From:*Stephen Hanna [mailto:shanna@juniper.net] > > *Sent:* Wednesday, February 05, 2014 6:10 PM > > *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > sacm@ietf.org > > *Subject:* RE: Types of content > > > > Would "dictionaries of posture attributes" include attribute values > that > > have been collected from endpoints? > > > > We want to have the ability to collect attribute values from > endpoints > > and "persist" them, as described in section 2.1.3. So we'll need to > have > > a repository for collected and persisted attribute values. > > > > If collected endpoint attribute values are considered content, let's > say > > so. If not, let's say that explicitly. > > > > My personal view is that collected endpoint attribute values should > be > > considered content. They may be a different kind of content from the > > others due to larger volume and higher change rate. For that reason, > > people may choose to put them into a different repository and maybe > even > > use a different query protocol for that repository to munge the large > > quantities of data. But they're still content. > > > > Thanks, > > > > Steve > > > > *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > > Kampanakis (pkampana) > > *Sent:* Wednesday, February 05, 2014 5:25 PM > > *To:* Waltermire, David A.; sacm@ietf.org > > *Subject:* Re: [sacm] Types of content > > > > Sounds like a good summary of what "content" could mean. > > > > Panos > > > > *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Waltermire, > > David A. > > *Sent:* Wednesday, February 05, 2014 10:38 PM > > *To:* sacm@ietf.org > > *Subject:* [sacm] Types of content > > > > I'm working through the UC draft addressing discussion items from > > yesterday and the previous comments we have received on the list on - > 05. > > > > Related to section 2.1.1, we have had many previous discussions > around > > the notional idea of content. There has been general agreement that > we > > need to be more specific. Please find below an attempt to put some > > "bounds" around different types of content. > > > > Is this hitting the mark, or do we need to say something > more/different? > > > > The following is a snippet from a possible update to section 2.1.1 > with > > some additional description: > > > > I'd appreciate any thoughts, concerns, objections before I include > the > > changes in the draft. > > > > Thanks, > > > > Dave > > > > 2.1.1. Define, Publish, Query and Retrieve Content > > > > This use case describes the need for content to be defined and > > > > published to a data store, as well as queried and retrieved from > the > > > > data store for the explicit use of posture collection and > evaluation. > > > > The term "content" is a general concept that refers to any data > > > > expression that may be used as part of the process of collecting > and > > > > evaluating endpoint posture. Typical types of content include: > > > > o Dictionaries of posture attributes (e.g. software > installation, > > > > configuration, privileges) that may be collected from a given > > > > endpoint type that relate to installed hardware, installed > > > > software, software configurations, accounts, privileges, and > other > > > > operational state. > > > > o Expressions that provide instructions for using a specific > API, > > > > management protocol, or other mechanisms to collect specific > > > > posture attributes from specific device types. > > > > o Policies that define the selected posture attributes for which > > > > values must be collected to support one or more posture > > > > assessments. This may include information that targets > collection > > > > to a specific set of endpoints and instructions on the > frequency > > > > and/or change events (e.g., configuration changes, software > > > > installation/uninstallation, account/privilege modifications) > that > > > > will trigger collection of one or more posture attributes. > > > > o Policies that define the logical criteria to evaluate > collected > > > > posture attribute values to determine if they meet > organizational > > > > requirements. This may include information that targets > > > > evaluation to a specific set of endpoints. > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From gunnar.engelbach@threatguard.com Wed Feb 5 19:34:11 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618D11A0010 for ; Wed, 5 Feb 2014 19:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGhUo-wTKSkk for ; Wed, 5 Feb 2014 19:34:08 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED7D1A034B for ; Wed, 5 Feb 2014 19:34:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=dNcc44IIAxCSzs1SzYRy2ObboTbzFJmtMef3ioT1fIBS7unJU4yY8rEqefGOnAWuZA+Q8vVU2OLz8nVJav5Uhi6UtsT0vGh4tvUV3cZDcqx5RPPF1s2paq0KY4/wyk34; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 24913 invoked from network); 5 Feb 2014 19:40:33 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Feb 2014 19:40:33 -0800 Message-ID: <52F302BC.30501@ThreatGuard.com> Date: Wed, 05 Feb 2014 22:34:20 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Hanna , "Waltermire, David A." , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> In-Reply-To: <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 03:34:11 -0000 So "Guidance" is input and "collected attributes" is the immediate product? That works. And is line with common usage. And for the final result of applying the collected attributes to the guidance, how about "assessment results?" Is there a need for anything more granular? Mention of other terms commonly used for the same thing? What I frequently see: Input: Guidance Content Checklist Questionnaire Data stream Benchmark Definitions Product: Collected Attributes System Characteristics Assessment Results Posture On 2/5/2014 9:13 PM, Stephen Hanna wrote: > The terms "content" and "data" are just too general. "SA content" > isn't much better. It seems to include any kind of data related > to security automation. In the long run, that might include lots > of things like vulnerability reports and alerts that an intrusion > has been detected and remediation or mitigation instructions. > Also reports on endpoint compliance and attributes that have > been collected from endpoints and maybe persisted. It's just > not useful to use one term for all those kinds of things. > > I think that we need a new, more specific term for the things > that Dave described below: attribute identifiers, lists of > attributes that are to be collected and when and perhaps how, > and policies about what attribute values are acceptable for > different kinds or groups of endpoints. I suggest that we > use the collective term "guidance" for these things. This > indicates that these things (and maybe others to be added > later) guide the attribute collection and evaluation process. > > We also need to have a term for attribute values that have > been collected from endpoints. I vote for "collected attributes". > These attributes might be persisted (stored) or maybe not. > Either way, they are attribute values that have been collected > from endpoints. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach >> Sent: Wednesday, February 05, 2014 7:37 PM >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis (pkampana); >> sacm@ietf.org >> Subject: Re: [sacm] Types of content >> >> >> I would prefer to reserve the term "content" for the instructional >> documentation. That is, the documents that cause an action, be it >> legislation, prose guidance, or a set of machine instructions that >> implement that guidance. >> >> We typically use "system characteristics" when referring to collected >> items, and variations on "endpoint attributes" has been used frequently >> on this list. System characteristics are the product of applying >> content to an endpoint. >> >> Collectively it's all data. Is there a desire to have a general term >> for all data that could flow through a SACM implementation but is >> specific to SACM? >> >> >> Also, while I agree with the need to allow the ability to persist >> collected data items (and the results of posture evaluations), I don't >> see that as a requirement. >> >> >> >> >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: >>> Dictionaries of posture attributes was not intended to include >> attribute >>> values. IETF examples of this concept might include attributes in a >> MIB >>> or a NETMOD model. >>> >>> I agree that we need to "persist" posture attribute values. I have >>> always been on the fence personally about calling collection and >>> evaluation results "content". I agree 100% that we need to be crystal >>> clear about what we mean when we use the terms "content" and "content >>> repository". If we choose to lump all of this together as "content", >> we >>> will need to include some discussion in the use case document >>> contrasting different types of content to drive discussion of content >>> type-specific requirements. >>> >>> I also personally like Ira's feedback on using a more specific >> term(s) >>> instead of the more general "content". >>> >>> I also share the same personal view around interacting with stores of >>> collected posture attribute values and evaluation results. The larger >>> data volumes and rate of change will likely require different >>> approaches. I also believe that the temporal nature of this data, the >>> need to persist historic information, will be more significant than >>> other types of data that we may call "content". >>> >>> Are there other opinions on this? Does anyone feel strongly that >>> collected posture attribute values and evaluation results SHOULD NOT >> be >>> considered content? >>> >>> Thanks, >>> >>> Dave >>> >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] >>> *Sent:* Wednesday, February 05, 2014 6:10 PM >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; >> sacm@ietf.org >>> *Subject:* RE: Types of content >>> >>> Would "dictionaries of posture attributes" include attribute values >> that >>> have been collected from endpoints? >>> >>> We want to have the ability to collect attribute values from >> endpoints >>> and "persist" them, as described in section 2.1.3. So we'll need to >> have >>> a repository for collected and persisted attribute values. >>> >>> If collected endpoint attribute values are considered content, let's >> say >>> so. If not, let's say that explicitly. >>> >>> My personal view is that collected endpoint attribute values should >> be >>> considered content. They may be a different kind of content from the >>> others due to larger volume and higher change rate. For that reason, >>> people may choose to put them into a different repository and maybe >> even >>> use a different query protocol for that repository to munge the large >>> quantities of data. But they're still content. >>> >>> Thanks, >>> >>> Steve >>> >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos >>> Kampanakis (pkampana) >>> *Sent:* Wednesday, February 05, 2014 5:25 PM >>> *To:* Waltermire, David A.; sacm@ietf.org >>> *Subject:* Re: [sacm] Types of content >>> >>> Sounds like a good summary of what "content" could mean. >>> >>> Panos >>> >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Waltermire, >>> David A. >>> *Sent:* Wednesday, February 05, 2014 10:38 PM >>> *To:* sacm@ietf.org >>> *Subject:* [sacm] Types of content >>> >>> I'm working through the UC draft addressing discussion items from >>> yesterday and the previous comments we have received on the list on - >> 05. >>> >>> Related to section 2.1.1, we have had many previous discussions >> around >>> the notional idea of content. There has been general agreement that >> we >>> need to be more specific. Please find below an attempt to put some >>> "bounds" around different types of content. >>> >>> Is this hitting the mark, or do we need to say something >> more/different? >>> >>> The following is a snippet from a possible update to section 2.1.1 >> with >>> some additional description: >>> >>> I'd appreciate any thoughts, concerns, objections before I include >> the >>> changes in the draft. >>> >>> Thanks, >>> >>> Dave >>> >>> 2.1.1. Define, Publish, Query and Retrieve Content >>> >>> This use case describes the need for content to be defined and >>> >>> published to a data store, as well as queried and retrieved from >> the >>> >>> data store for the explicit use of posture collection and >> evaluation. >>> >>> The term "content" is a general concept that refers to any data >>> >>> expression that may be used as part of the process of collecting >> and >>> >>> evaluating endpoint posture. Typical types of content include: >>> >>> o Dictionaries of posture attributes (e.g. software >> installation, >>> >>> configuration, privileges) that may be collected from a given >>> >>> endpoint type that relate to installed hardware, installed >>> >>> software, software configurations, accounts, privileges, and >> other >>> >>> operational state. >>> >>> o Expressions that provide instructions for using a specific >> API, >>> >>> management protocol, or other mechanisms to collect specific >>> >>> posture attributes from specific device types. >>> >>> o Policies that define the selected posture attributes for which >>> >>> values must be collected to support one or more posture >>> >>> assessments. This may include information that targets >> collection >>> >>> to a specific set of endpoints and instructions on the >> frequency >>> >>> and/or change events (e.g., configuration changes, software >>> >>> installation/uninstallation, account/privilege modifications) >> that >>> >>> will trigger collection of one or more posture attributes. >>> >>> o Policies that define the logical criteria to evaluate >> collected >>> >>> posture attribute values to determine if they meet >> organizational >>> >>> requirements. This may include information that targets >>> >>> evaluation to a specific set of endpoints. >>> >>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > > From shanna@juniper.net Wed Feb 5 19:48:29 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4BC1A0363 for ; Wed, 5 Feb 2014 19:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAdutTMk-dAa for ; Wed, 5 Feb 2014 19:48:25 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 91F521A0362 for ; Wed, 5 Feb 2014 19:48:25 -0800 (PST) Received: from mail185-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Feb 2014 03:48:24 +0000 Received: from mail185-co9 (localhost [127.0.0.1]) by mail185-co9-R.bigfish.com (Postfix) with ESMTP id 645B8200401; Thu, 6 Feb 2014 03:48:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1432I1418I4015I168aJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h9a9j1155h) Received-SPF: pass (mail185-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(57704003)(51704005)(479174003)(377454003)(164054003)(51444003)(13464003)(199002)(189002)(92566001)(80022001)(63696002)(74706001)(53806001)(93516002)(54356001)(80976001)(83072002)(2656002)(79102001)(76482001)(87266001)(15975445006)(81686001)(66066001)(81816001)(94946001)(51856001)(93136001)(85852003)(94316002)(86362001)(54316002)(65816001)(77982001)(46102001)(74876001)(95416001)(85306002)(56776001)(59766001)(33646001)(87936001)(90146001)(56816005)(47736001)(4396001)(74366001)(81342001)(81542001)(76576001)(31966008)(47976001)(50986001)(49866001)(83322001)(19580395003)(74662001)(76786001)(19580405001)(47446002)(74316001)(76796001)(74502001)(69226001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB738; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.12; FPR:AE6CF1D4.ABF2C142.78D13D6B.42E4C941.2066D; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail185-co9 (localhost.localdomain [127.0.0.1]) by mail185-co9 (MessageSwitch) id 1391658501872939_9901; Thu, 6 Feb 2014 03:48:21 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.254]) by mail185-co9.bigfish.com (Postfix) with ESMTP id D00872C004C; Thu, 6 Feb 2014 03:48:21 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Feb 2014 03:48:21 +0000 Received: from BLUPR05MB738.namprd05.prod.outlook.com (10.141.208.21) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 6 Feb 2014 03:48:20 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB738.namprd05.prod.outlook.com (10.141.208.21) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 03:48:18 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 03:48:18 +0000 From: Stephen Hanna To: Gunnar Engelbach , "Waltermire, David A." , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVAAAzOpAAAARPnQ Date: Thu, 6 Feb 2014 03:48:17 +0000 Message-ID: References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: <52F302BC.30501@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-forefront-prvs: 0114FF88F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 03:48:30 -0000 Gunnar Engelbach wrote: > So "Guidance" is input and "collected attributes" is the immediate > product? Right. At least, that's one way of describing it. I'm thinking that guidance would include all the things that Dave was previously calling "content". > That works. And is line with common usage. Good! I'm glad to hear that it makes sense to you. > And for the final result of applying the collected attributes to the > guidance, how about "assessment results?" Yes, I like that also. > Is there a need for anything more granular? Probably eventually. But there also seems to be a need for broad terms since people want to be able to put all the "guidance" into one repository (perhaps) and have a different kind of repository for "collected attributes" and maybe also "assessment results". > Mention of other terms commonly used for the > same thing? Maybe. Listing alternative terms in common usage today can be confusing since different people may use those terms differently. Thanks, Steve >=20 >=20 > What I frequently see: >=20 > Input: > Guidance > Content > Checklist > Questionnaire > Data stream > Benchmark > Definitions >=20 >=20 > Product: > Collected Attributes > System Characteristics > Assessment Results > Posture >=20 >=20 >=20 >=20 > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > > The terms "content" and "data" are just too general. "SA content" > > isn't much better. It seems to include any kind of data related > > to security automation. In the long run, that might include lots > > of things like vulnerability reports and alerts that an intrusion > > has been detected and remediation or mitigation instructions. > > Also reports on endpoint compliance and attributes that have > > been collected from endpoints and maybe persisted. It's just > > not useful to use one term for all those kinds of things. > > > > I think that we need a new, more specific term for the things > > that Dave described below: attribute identifiers, lists of > > attributes that are to be collected and when and perhaps how, > > and policies about what attribute values are acceptable for > > different kinds or groups of endpoints. I suggest that we > > use the collective term "guidance" for these things. This > > indicates that these things (and maybe others to be added > > later) guide the attribute collection and evaluation process. > > > > We also need to have a term for attribute values that have > > been collected from endpoints. I vote for "collected attributes". > > These attributes might be persisted (stored) or maybe not. > > Either way, they are attribute values that have been collected > > from endpoints. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > Engelbach > >> Sent: Wednesday, February 05, 2014 7:37 PM > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > (pkampana); > >> sacm@ietf.org > >> Subject: Re: [sacm] Types of content > >> > >> > >> I would prefer to reserve the term "content" for the instructional > >> documentation. That is, the documents that cause an action, be it > >> legislation, prose guidance, or a set of machine instructions that > >> implement that guidance. > >> > >> We typically use "system characteristics" when referring to > collected > >> items, and variations on "endpoint attributes" has been used > frequently > >> on this list. System characteristics are the product of applying > >> content to an endpoint. > >> > >> Collectively it's all data. Is there a desire to have a general > term > >> for all data that could flow through a SACM implementation but is > >> specific to SACM? > >> > >> > >> Also, while I agree with the need to allow the ability to persist > >> collected data items (and the results of posture evaluations), I > don't > >> see that as a requirement. > >> > >> > >> > >> > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > >>> Dictionaries of posture attributes was not intended to include > >> attribute > >>> values. IETF examples of this concept might include attributes in a > >> MIB > >>> or a NETMOD model. > >>> > >>> I agree that we need to "persist" posture attribute values. I have > >>> always been on the fence personally about calling collection and > >>> evaluation results "content". I agree 100% that we need to be > crystal > >>> clear about what we mean when we use the terms "content" and > "content > >>> repository". If we choose to lump all of this together as > "content", > >> we > >>> will need to include some discussion in the use case document > >>> contrasting different types of content to drive discussion of > content > >>> type-specific requirements. > >>> > >>> I also personally like Ira's feedback on using a more specific > >> term(s) > >>> instead of the more general "content". > >>> > >>> I also share the same personal view around interacting with stores > of > >>> collected posture attribute values and evaluation results. The > larger > >>> data volumes and rate of change will likely require different > >>> approaches. I also believe that the temporal nature of this data, > the > >>> need to persist historic information, will be more significant than > >>> other types of data that we may call "content". > >>> > >>> Are there other opinions on this? Does anyone feel strongly that > >>> collected posture attribute values and evaluation results SHOULD > NOT > >> be > >>> considered content? > >>> > >>> Thanks, > >>> > >>> Dave > >>> > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > >> sacm@ietf.org > >>> *Subject:* RE: Types of content > >>> > >>> Would "dictionaries of posture attributes" include attribute values > >> that > >>> have been collected from endpoints? > >>> > >>> We want to have the ability to collect attribute values from > >> endpoints > >>> and "persist" them, as described in section 2.1.3. So we'll need to > >> have > >>> a repository for collected and persisted attribute values. > >>> > >>> If collected endpoint attribute values are considered content, > let's > >> say > >>> so. If not, let's say that explicitly. > >>> > >>> My personal view is that collected endpoint attribute values should > >> be > >>> considered content. They may be a different kind of content from > the > >>> others due to larger volume and higher change rate. For that > reason, > >>> people may choose to put them into a different repository and maybe > >> even > >>> use a different query protocol for that repository to munge the > large > >>> quantities of data. But they're still content. > >>> > >>> Thanks, > >>> > >>> Steve > >>> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > >>> Kampanakis (pkampana) > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > >>> *To:* Waltermire, David A.; sacm@ietf.org > >>> *Subject:* Re: [sacm] Types of content > >>> > >>> Sounds like a good summary of what "content" could mean. > >>> > >>> Panos > >>> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Waltermire, > >>> David A. > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > >>> *To:* sacm@ietf.org > >>> *Subject:* [sacm] Types of content > >>> > >>> I'm working through the UC draft addressing discussion items from > >>> yesterday and the previous comments we have received on the list on > - > >> 05. > >>> > >>> Related to section 2.1.1, we have had many previous discussions > >> around > >>> the notional idea of content. There has been general agreement that > >> we > >>> need to be more specific. Please find below an attempt to put some > >>> "bounds" around different types of content. > >>> > >>> Is this hitting the mark, or do we need to say something > >> more/different? > >>> > >>> The following is a snippet from a possible update to section 2.1.1 > >> with > >>> some additional description: > >>> > >>> I'd appreciate any thoughts, concerns, objections before I include > >> the > >>> changes in the draft. > >>> > >>> Thanks, > >>> > >>> Dave > >>> > >>> 2.1.1. Define, Publish, Query and Retrieve Content > >>> > >>> This use case describes the need for content to be defined and > >>> > >>> published to a data store, as well as queried and retrieved > from > >> the > >>> > >>> data store for the explicit use of posture collection and > >> evaluation. > >>> > >>> The term "content" is a general concept that refers to any > data > >>> > >>> expression that may be used as part of the process of > collecting > >> and > >>> > >>> evaluating endpoint posture. Typical types of content > include: > >>> > >>> o Dictionaries of posture attributes (e.g. software > >> installation, > >>> > >>> configuration, privileges) that may be collected from a > given > >>> > >>> endpoint type that relate to installed hardware, installed > >>> > >>> software, software configurations, accounts, privileges, > and > >> other > >>> > >>> operational state. > >>> > >>> o Expressions that provide instructions for using a specific > >> API, > >>> > >>> management protocol, or other mechanisms to collect > specific > >>> > >>> posture attributes from specific device types. > >>> > >>> o Policies that define the selected posture attributes for > which > >>> > >>> values must be collected to support one or more posture > >>> > >>> assessments. This may include information that targets > >> collection > >>> > >>> to a specific set of endpoints and instructions on the > >> frequency > >>> > >>> and/or change events (e.g., configuration changes, software > >>> > >>> installation/uninstallation, account/privilege > modifications) > >> that > >>> > >>> will trigger collection of one or more posture attributes. > >>> > >>> o Policies that define the logical criteria to evaluate > >> collected > >>> > >>> posture attribute values to determine if they meet > >> organizational > >>> > >>> requirements. This may include information that targets > >>> > >>> evaluation to a specific set of endpoints. > >>> > >>> > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >>> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > >> > > > > >=20 From david.waltermire@nist.gov Thu Feb 6 07:29:40 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9D1A03DB for ; Thu, 6 Feb 2014 07:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4mdCGx0WCrD for ; Thu, 6 Feb 2014 07:29:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id 626CF1A03DA for ; Thu, 6 Feb 2014 07:29:37 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 15:29:35 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.127]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.181]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 15:29:34 +0000 From: "Waltermire, David A." To: Stephen Hanna , Gunnar Engelbach , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVAAAzOpAAAARPnQABdl6XA= Date: Thu, 6 Feb 2014 15:29:34 +0000 Message-ID: <8230608db259410c8e0bf8ad74fecce2@BLUPR09MB038.namprd09.prod.outlook.com> References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(479174003)(377454003)(51444003)(189002)(199002)(164054003)(13464003)(57704003)(24454002)(74662001)(31966008)(80976001)(74502001)(19580395003)(19580405001)(83322001)(74706001)(90146001)(65816001)(87266001)(80022001)(47446002)(4396001)(77096001)(76576001)(47976001)(49866001)(50986001)(47736001)(76786001)(76796001)(94316002)(56816005)(51856001)(46102001)(54356001)(95416001)(94946001)(81686001)(53806001)(15975445006)(74876001)(77982001)(59766001)(93136001)(56776001)(93516002)(66066001)(79102001)(83072002)(2656002)(92566001)(85852003)(54316002)(76482001)(81816001)(87936001)(63696002)(85306002)(86362001)(74316001)(69226001)(1941001)(81542001)(81342001)(74366001)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EC4CF1D5.ABF2C142.78D13D6B.41E4C941.20737; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:29:40 -0000 This has been a great discussion. Some additional thoughts are below, along= with some questions. > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, February 05, 2014 10:48 PM > To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis (pkampana); > sacm@ietf.org > Subject: RE: [sacm] Types of content >=20 > Gunnar Engelbach wrote: > > So "Guidance" is input and "collected attributes" is the immediate > > product? >=20 > Right. At least, that's one way of describing it. > I'm thinking that guidance would include all the things that Dave was > previously calling "content". We have three basic processes defined in the use cases: Assessment Planning= , Collection, and Evaluation. For each there are a set of instructions that= may be used as input and a set of outputs that result from the process. Th= e following listing of data inputs and outputs is derived from the use case= /building block text. This represents a fairly comprehensive list of variou= s forms of "content" that we will be dealing with. The inputs for Assessment Planning include: - Characterizations of endpoints (BB: Endpoint Characterization) - Endpoint= metadata that describes the endpoint type, organizationally expected funct= ion/role, etc. - Posture attributes values for HW/SW inventory and accounts/privileges (BB= : Endpoint Component Inventory) - This provides context to identify what po= sture attributes should be collected as part of the assessment.=20 - Assessment applicability statements (BB: Identify Endpoint Targets) - Thi= s supports the targeting concept allowing characterizations and collected p= osture attribute values to be evaluated to determine what set of endpoints = should be assessed. - Evaluation instructions (BB: Posture Attribute Identification) - Use to d= etermine the set of posture attributes for which values are required for ev= aluation. The outputs for the Assessment Planning include: - An identified set of endpoints (BB: Identify Endpoint Targets) - The endp= oints to assess. - A set of identified posture attributes (BB: Posture Attribute Identificat= ion) - The required posture attributes needed to perform the evaluation. At this point Collection will occur to collect the necessary posture attrib= utes. This may have been done historically completely or in-part. If there = is incomplete or stale information, this may be collected immediately or sc= heduled as appropriate. The inputs for Collection include the following (provided by the outputs of= assessment planning): - An identified set of endpoints (BB: Identify Endpoint Targets) - The endp= oints to assess. - A set of identified posture attributes (BB: Posture Attribute Identificat= ion) - The required posture attributes needed to perform the evaluation. - Collection instructions (BB: Collection Content Acquisition) - Directives= on how the posture attributes should be collected. This may include: event= s to monitor, scheduling info, instructions for using specific models/proto= cols, etc. The outputs for Collection include the following: - A set of posture attributes and associated values (BB: Posture Attribute = Value Collection) - The result of collection. At this point evaluation can occur. The inputs for Posture Evaluation include the following: - A set of posture attributes and associated values (BB: Posture Attribute = Value Query) - The previously collected posture attribute values. This may = not require a query if the data is fed directly to an evaluator after colle= ction. - Evaluation instructions (BB: Evaluation Content Acquisition) - Directives= on how to evaluate posture attribute values. This will likely include comp= arison operators and logical constructs. Additional instructions might indi= cate the required result output format. The outputs for Posture Evaluation include the following: - Assessment Results (BB: Posture Attribute Evaluation) - The resulting out= put generated by the evaluation process. The big questions are: 1) Is this a complete list? 2) What of this will be stored or have the potential to be stored in a data= repository? 3) What groupings of content types do we want to define? Any thoughts are appreciated. Thanks, Dave > > That works. And is line with common usage. >=20 > Good! I'm glad to hear that it makes sense to you. >=20 > > And for the final result of applying the collected attributes to the > > guidance, how about "assessment results?" >=20 > Yes, I like that also. >=20 > > Is there a need for anything more granular? >=20 > Probably eventually. But there also seems to be a need for broad terms si= nce > people want to be able to put all the "guidance" into one repository > (perhaps) and have a different kind of repository for "collected attribut= es" > and maybe also "assessment results". >=20 > > Mention of other terms commonly used for the same thing? >=20 > Maybe. Listing alternative terms in common usage today can be confusing > since different people may use those terms differently. >=20 > Thanks, >=20 > Steve >=20 > > > > > > What I frequently see: > > > > Input: > > Guidance > > Content > > Checklist > > Questionnaire > > Data stream > > Benchmark > > Definitions > > > > > > Product: > > Collected Attributes > > System Characteristics > > Assessment Results > > Posture > > > > > > > > > > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > > > The terms "content" and "data" are just too general. "SA content" > > > isn't much better. It seems to include any kind of data related to > > > security automation. In the long run, that might include lots of > > > things like vulnerability reports and alerts that an intrusion has > > > been detected and remediation or mitigation instructions. > > > Also reports on endpoint compliance and attributes that have been > > > collected from endpoints and maybe persisted. It's just not useful > > > to use one term for all those kinds of things. > > > > > > I think that we need a new, more specific term for the things that > > > Dave described below: attribute identifiers, lists of attributes > > > that are to be collected and when and perhaps how, and policies > > > about what attribute values are acceptable for different kinds or > > > groups of endpoints. I suggest that we use the collective term > > > "guidance" for these things. This indicates that these things (and > > > maybe others to be added > > > later) guide the attribute collection and evaluation process. > > > > > > We also need to have a term for attribute values that have been > > > collected from endpoints. I vote for "collected attributes". > > > These attributes might be persisted (stored) or maybe not. > > > Either way, they are attribute values that have been collected from > > > endpoints. > > > > > > Thanks, > > > > > > Steve > > > > > >> -----Original Message----- > > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > > Engelbach > > >> Sent: Wednesday, February 05, 2014 7:37 PM > > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > > (pkampana); > > >> sacm@ietf.org > > >> Subject: Re: [sacm] Types of content > > >> > > >> > > >> I would prefer to reserve the term "content" for the instructional > > >> documentation. That is, the documents that cause an action, be it > > >> legislation, prose guidance, or a set of machine instructions that > > >> implement that guidance. > > >> > > >> We typically use "system characteristics" when referring to > > collected > > >> items, and variations on "endpoint attributes" has been used > > frequently > > >> on this list. System characteristics are the product of applying > > >> content to an endpoint. > > >> > > >> Collectively it's all data. Is there a desire to have a general > > term > > >> for all data that could flow through a SACM implementation but is > > >> specific to SACM? > > >> > > >> > > >> Also, while I agree with the need to allow the ability to persist > > >> collected data items (and the results of posture evaluations), I > > don't > > >> see that as a requirement. > > >> > > >> > > >> > > >> > > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > > >>> Dictionaries of posture attributes was not intended to include > > >> attribute > > >>> values. IETF examples of this concept might include attributes in > > >>> a > > >> MIB > > >>> or a NETMOD model. > > >>> > > >>> I agree that we need to "persist" posture attribute values. I have > > >>> always been on the fence personally about calling collection and > > >>> evaluation results "content". I agree 100% that we need to be > > crystal > > >>> clear about what we mean when we use the terms "content" and > > "content > > >>> repository". If we choose to lump all of this together as > > "content", > > >> we > > >>> will need to include some discussion in the use case document > > >>> contrasting different types of content to drive discussion of > > content > > >>> type-specific requirements. > > >>> > > >>> I also personally like Ira's feedback on using a more specific > > >> term(s) > > >>> instead of the more general "content". > > >>> > > >>> I also share the same personal view around interacting with stores > > of > > >>> collected posture attribute values and evaluation results. The > > larger > > >>> data volumes and rate of change will likely require different > > >>> approaches. I also believe that the temporal nature of this data, > > the > > >>> need to persist historic information, will be more significant > > >>> than other types of data that we may call "content". > > >>> > > >>> Are there other opinions on this? Does anyone feel strongly that > > >>> collected posture attribute values and evaluation results SHOULD > > NOT > > >> be > > >>> considered content? > > >>> > > >>> Thanks, > > >>> > > >>> Dave > > >>> > > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > > >> sacm@ietf.org > > >>> *Subject:* RE: Types of content > > >>> > > >>> Would "dictionaries of posture attributes" include attribute > > >>> values > > >> that > > >>> have been collected from endpoints? > > >>> > > >>> We want to have the ability to collect attribute values from > > >> endpoints > > >>> and "persist" them, as described in section 2.1.3. So we'll need > > >>> to > > >> have > > >>> a repository for collected and persisted attribute values. > > >>> > > >>> If collected endpoint attribute values are considered content, > > let's > > >> say > > >>> so. If not, let's say that explicitly. > > >>> > > >>> My personal view is that collected endpoint attribute values > > >>> should > > >> be > > >>> considered content. They may be a different kind of content from > > the > > >>> others due to larger volume and higher change rate. For that > > reason, > > >>> people may choose to put them into a different repository and > > >>> maybe > > >> even > > >>> use a different query protocol for that repository to munge the > > large > > >>> quantities of data. But they're still content. > > >>> > > >>> Thanks, > > >>> > > >>> Steve > > >>> > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > > >>> Kampanakis (pkampana) > > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > > >>> *To:* Waltermire, David A.; sacm@ietf.org > > >>> *Subject:* Re: [sacm] Types of content > > >>> > > >>> Sounds like a good summary of what "content" could mean. > > >>> > > >>> Panos > > >>> > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > > *Waltermire, > > >>> David A. > > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > > >>> *To:* sacm@ietf.org > > >>> *Subject:* [sacm] Types of content > > >>> > > >>> I'm working through the UC draft addressing discussion items from > > >>> yesterday and the previous comments we have received on the list > > >>> on > > - > > >> 05. > > >>> > > >>> Related to section 2.1.1, we have had many previous discussions > > >> around > > >>> the notional idea of content. There has been general agreement > > >>> that > > >> we > > >>> need to be more specific. Please find below an attempt to put some > > >>> "bounds" around different types of content. > > >>> > > >>> Is this hitting the mark, or do we need to say something > > >> more/different? > > >>> > > >>> The following is a snippet from a possible update to section 2.1.1 > > >> with > > >>> some additional description: > > >>> > > >>> I'd appreciate any thoughts, concerns, objections before I include > > >> the > > >>> changes in the draft. > > >>> > > >>> Thanks, > > >>> > > >>> Dave > > >>> > > >>> 2.1.1. Define, Publish, Query and Retrieve Content > > >>> > > >>> This use case describes the need for content to be defined > > >>> and > > >>> > > >>> published to a data store, as well as queried and retrieved > > from > > >> the > > >>> > > >>> data store for the explicit use of posture collection and > > >> evaluation. > > >>> > > >>> The term "content" is a general concept that refers to any > > data > > >>> > > >>> expression that may be used as part of the process of > > collecting > > >> and > > >>> > > >>> evaluating endpoint posture. Typical types of content > > include: > > >>> > > >>> o Dictionaries of posture attributes (e.g. software > > >> installation, > > >>> > > >>> configuration, privileges) that may be collected from a > > given > > >>> > > >>> endpoint type that relate to installed hardware, installed > > >>> > > >>> software, software configurations, accounts, privileges, > > and > > >> other > > >>> > > >>> operational state. > > >>> > > >>> o Expressions that provide instructions for using a specific > > >> API, > > >>> > > >>> management protocol, or other mechanisms to collect > > specific > > >>> > > >>> posture attributes from specific device types. > > >>> > > >>> o Policies that define the selected posture attributes for > > which > > >>> > > >>> values must be collected to support one or more posture > > >>> > > >>> assessments. This may include information that targets > > >> collection > > >>> > > >>> to a specific set of endpoints and instructions on the > > >> frequency > > >>> > > >>> and/or change events (e.g., configuration changes, > > >>> software > > >>> > > >>> installation/uninstallation, account/privilege > > modifications) > > >> that > > >>> > > >>> will trigger collection of one or more posture attributes. > > >>> > > >>> o Policies that define the logical criteria to evaluate > > >> collected > > >>> > > >>> posture attribute values to determine if they meet > > >> organizational > > >>> > > >>> requirements. This may include information that targets > > >>> > > >>> evaluation to a specific set of endpoints. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> sacm mailing list > > >>> sacm@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sacm > > >>> > > >> _______________________________________________ > > >> sacm mailing list > > >> sacm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sacm > > >> > > > > > > > > >=20 From ncamwing@cisco.com Sun Feb 9 08:29:57 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897751A03BB for ; Sun, 9 Feb 2014 08:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6jJBhpiT3jx for ; Sun, 9 Feb 2014 08:29:55 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 991CA1A01E1 for ; Sun, 9 Feb 2014 08:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1892; q=dns/txt; s=iport; t=1391963396; x=1393172996; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=fFLScOE/8hwSXppaanHIEFwjnoC/lXZs5XuLfVgjTpE=; b=gPeVwXc+m560ZBUKIQodhucOJttGGK9FYBb8q/7BjD1PiikBgLyWa0FV qncyzfb2uqwDTHyqBX4h+nwzefuPMP9yMwxO+T2Nb4/lGVkNr1fq7o1/9 bzvX6GLeiW7jjFfgViEi4I3G5QjWtUawn9Ko4jm3n1FAcHxRjNt+yXjq3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAFSs91KtJXG8/2dsb2JhbABZgww4UQa/QYEGFnSCJQEBAQQBAQE3NB0BCBIkNwsXBAEGAwIEEwmHfAgFmGevQxeOfwWEOASYK4Eyiy+FQIMtgio X-IronPort-AV: E=Sophos;i="4.95,812,1384300800"; d="scan'208";a="302863070" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 09 Feb 2014 16:29:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s19GTsl4026389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 9 Feb 2014 16:29:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Sun, 9 Feb 2014 10:29:54 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: I-D Action: draft-camwinget-sacm-requirements-02.txt Thread-Index: AQHPJbQpyMrabi/kO0m6bR9rh0WaRg== Date: Sun, 9 Feb 2014 16:29:54 +0000 Message-ID: In-Reply-To: <20140207160357.26196.90103.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.112.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A482A54EB9B5D4C91B30AF2A1B5BF99@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] FW: I-D Action: draft-camwinget-sacm-requirements-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 16:29:57 -0000 I managed to officially post the -02 draft that we discussed on the last call. I'll be making updates per comments on the call (thanks David Misell for the notes!) and try to submit another version by Friday. Please continue to provide comments to I can try to address them by then. Thanks, Nancy On 2/7/14 8:03 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Secure Automation and Continuous Monitoring >(SACM) Requirements > Author : Nancy Cam-Winget > Filename : draft-camwinget-sacm-requirements-02.txt > Pages : 7 > Date : 2014-02-06 > >Abstract: > This document defines the scope and set of requirements for the > Secure Automation and Continuous Monitoring working group. The > requirements and scope are based on the agreed upon use cases and > architecture defined. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-camwinget-sacm-requirements/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-camwinget-sacm-requirements-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-camwinget-sacm-requirements-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From david.waltermire@nist.gov Tue Feb 11 16:13:34 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C151A0767 for ; Tue, 11 Feb 2014 16:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUCeMHWgz1R6 for ; Tue, 11 Feb 2014 16:13:29 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 10F881A0786 for ; Tue, 11 Feb 2014 16:13:28 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.873.15; Wed, 12 Feb 2014 00:13:26 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.27]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.27]) with mapi id 15.00.0878.008; Wed, 12 Feb 2014 00:13:26 +0000 From: "Waltermire, David A." To: Stephen Hanna , Gunnar Engelbach , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVAAAzOpAAAARPnQARgzlgA= Date: Wed, 12 Feb 2014 00:13:25 +0000 Message-ID: References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(377454003)(46034005)(164054003)(51444003)(199002)(13464003)(189002)(57704003)(24454002)(479174003)(76482001)(74502001)(53806001)(46102001)(51856001)(94316002)(31966008)(81542001)(69226001)(47446002)(94946001)(90146001)(56776001)(92566001)(15975445006)(76786001)(83072002)(86362001)(83322001)(80976001)(19580405001)(85852003)(93136001)(85306002)(93516002)(95666001)(54316002)(81342001)(81816001)(74662001)(81686001)(33646001)(54356001)(56816005)(95416001)(19580395003)(59766001)(76796001)(74706001)(4396001)(77982001)(2656002)(74876001)(74316001)(77096001)(76576001)(1941001)(74366001)(80022001)(65816001)(66066001)(87266001)(47976001)(50986001)(47736001)(49866001)(87936001)(63696002)(79102001)(24736002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EE7CF1D5.ABF2A142.78D1F16B.82E4C941.20829; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 00:13:34 -0000 I'd like to get the discussion around this topic to a point where I have cl= ear editorial direction on what text we want included in the updated use ca= se draft for this Friday's submission cutoff deadline. Based on the mailing list discussions to date, I'd like to propose the foll= owing categories of security automation data for inclusion in the use cases= draft: Guidance, Endpoint/Asset Attribute Data, and Processing Artifacts. The following sections roughly define each of the proposed categories. For = each section some insights are provided into the how the data might be sour= ced and how often it may change. I have also included examples of the class= es of information for each category with mappings to the use cases and buil= ding blocks they support to insure we have the necessary coverage. To move forward I need answers to the following questions: 1) Do you like these groupings? If not, is there a better set of groupings? 2) Do you like the labels for each of the groups? If not, do you have a bet= ter label(s)? 3) Are there other types of content that should be included? 4) What level of detail should be included in the use cases draft regarding= this discussion? What I have below is likely too much detail. Thanks, Dave Guidance: ------------ The term "guidance" was proposed by Steve Hanna and was supported by Gunnar= Engelbach on the list. Steve proposed that this concept encompasses "attri= bute identifiers, lists of attributes that are to be collected and when and= perhaps how, and policies about what attribute values are acceptable for d= ifferent kinds or groups of endpoints. This indicates that these things (an= d maybe others to be added later) guide the attribute collection and evalua= tion process." I would also add that this should include instructions suppo= rting data-driven evaluation processes. This data tends to change in units of months and days. In cases where asses= sments are made more dynamic, it may be necessary to handle changes in the = scope of hours or minutes. This data will typically be provided by large or= ganizations, product vendors, and some 3rd-parties. Thus, it will tend to b= e shared across large enterprises and customer communities. In some cases a= ccess may be controlled to specific authenticated users. In other cases, th= e data may be provided broadly with little to no access control. This would include: - Applicability Statements: Data the identifies the conditional applicabili= ty of an assessment (and related assessment "guidance") based on automated = collection of endpoint posture attribute values and other endpoint characte= rizations. + Endpoint Identification and Assessment Planning BB: Identify Endpoint= Targets - This supports the targeting concept allowing characterizations a= nd collected posture attribute values to be evaluated to determine what set= of endpoints should be assessed. - Collection Instructions: Data that drives the identification of the set o= f posture attributes needed to perform an assessment and the collection of = posture attributes. + Endpoint Identification and Assessment Planning BB: Posture Attribute= Identification - Used to determine the set of posture attributes for which= values must be collected (or retrieved) to support the evaluation. + Endpoint Posture Attribute Value Collection BB: Collection Content Ac= quisition - Data is retrieved based on its relationship to the assessment a= nd other applicability concepts to drive collection activities. + Endpoint Posture Attribute Value Collection BB: Posture Attribute Val= ue Collection - Directives on how the posture attributes should be collecte= d. This may include: events to monitor, scheduling info, instructions for u= sing specific models/protocols, etc. - Evaluation instructions: Data the identifies what endpoint posture attrib= ute values are to be evaluated and how this evaluation should be performed. + Endpoint Identification and Assessment Planning BB: Posture Attribute= Identification - Use to determine the set of posture attributes for which = values are required for evaluation. + Posture Evaluation BB: Evaluation Content Acquisition - Data is retri= eved based on its relationship to the assessment and other applicability co= ncepts to drive evaluation activities. + Posture Evaluation BB: Posture Attribute Evaluation - Instructs the e= valuation of collected endpoint posture attribute values. This will likely = include comparison operators and logical constructs. Additional instruction= s might indicate the required result output format. Our information model will need to relate the concepts of applicability sta= tements, collection instructions, and evaluation instructions in support of= assessment activities. Endpoint/Asset Attribute Data: -------------------------------------- This category includes contextual metadata pertaining to endpoints and the = assets that they are composed of (e.g., hardware, software, accounts), and = collected endpoint posture attributes, their associated values, and related= context. This data tends to change in units of days, minutes, a seconds with posture= attribute values typically changing more frequently than endpoint characte= rizations. This data tends to be organizationally and endpoint specific, wi= th specific operational groups of endpoints tending to exhibit similar attr= ibute profiles. This data will generally not be shared outside an organizat= ional boundary and will generally require authentication with specific acce= ss controls. This would include: - Characterizations of endpoints: Endpoint metadata that describes the endp= oint type, organizationally expected function/role, etc. + Endpoint Identification and Assessment Planning BB: Endpoint Characte= rization - Gathered through automated posture attribute collection, manual = data entry/query, and interactions with other data stores. - Collected Posture Attributes: Posture attributes and associated values co= llected from endpoints representing hardware, software inventory, configura= tions, accounts/privileges, and other aspects of endpoint state. + Endpoint Identification and Assessment Planning BB: Endpoint Componen= t Inventory - This provides context to identify what posture attributes sho= uld be collected as part of the assessment based on the current endpoint po= sture (e.g., what software is installed). + Endpoint Posture Attribute Value Collection BB: Posture Attribute Val= ue Collection - For each targeted endpoint, the set of collected posture at= tributes and associated values. The result of collection. + Posture Evaluation BB: Posture Attribute Value Query - The retrieval = of a set of previously collected posture attributes and associated values. = This may not be required if collected data is fed directly to an evaluator = after collection. An important dimension here may be the separation between actual and expect= ed posture attribute values. It may be possible to express guidance in a wa= y that allows expected values to parameterized. In this case it will be nec= essary to allow for organizationally expected values to be associated with = defined guidance (perhaps provided by a different party). Our information model will need to relate the concepts of endpoint characte= rizations and collected posture information to the types of guidance data. Processing Artifacts: ------------------------- This type of data is generated by and is specific to an individual assessme= nt process. This data may be used as part of the interactions between SACM = architectural components to drive and coordinate collection and evaluation = activities. Its lifespan will be bounded by the lifespan of the assessment.= It may also be exchanged and stored to provide historic context around an = assessment activity. This would include: - Endpoint Targets: An identified set of endpoints for which an assessment = should be performed. + Endpoint Identification and Assessment Planning BB: Identify Endpoint= Targets - The endpoints targeted for an assessment. - Identified Posture Attributes + Endpoint Identification and Assessment Planning BB: Posture Attribute= Identification - The required posture attributes that need to be collected= to perform the evaluation. - Assessment Results: The resulting output generated by the evaluation proc= ess. + Posture Evaluation BB: Posture Attribute Evaluation - The results pro= duced through the comparison of actual collected posture attribute values against their expected state. The specific output an evalua= tion criteria may be specified by the required evaluation instructions. Our information model will need to relate these concepts to those provided = in the other two categories. I know this is not saying much, but I am tired= and ready to end this email. ;-) > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, February 05, 2014 10:48 PM > To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis (pkampana); > sacm@ietf.org > Subject: RE: [sacm] Types of content >=20 > Gunnar Engelbach wrote: > > So "Guidance" is input and "collected attributes" is the immediate > > product? >=20 > Right. At least, that's one way of describing it. > I'm thinking that guidance would include all the things that Dave was > previously calling "content". >=20 > > That works. And is line with common usage. >=20 > Good! I'm glad to hear that it makes sense to you. >=20 > > And for the final result of applying the collected attributes to the > > guidance, how about "assessment results?" >=20 > Yes, I like that also. >=20 > > Is there a need for anything more granular? >=20 > Probably eventually. But there also seems to be a need for broad terms si= nce > people want to be able to put all the "guidance" into one repository > (perhaps) and have a different kind of repository for "collected attribut= es" > and maybe also "assessment results". >=20 > > Mention of other terms commonly used for the same thing? >=20 > Maybe. Listing alternative terms in common usage today can be confusing > since different people may use those terms differently. >=20 > Thanks, >=20 > Steve >=20 > > > > > > What I frequently see: > > > > Input: > > Guidance > > Content > > Checklist > > Questionnaire > > Data stream > > Benchmark > > Definitions > > > > > > Product: > > Collected Attributes > > System Characteristics > > Assessment Results > > Posture > > > > > > > > > > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > > > The terms "content" and "data" are just too general. "SA content" > > > isn't much better. It seems to include any kind of data related to > > > security automation. In the long run, that might include lots of > > > things like vulnerability reports and alerts that an intrusion has > > > been detected and remediation or mitigation instructions. > > > Also reports on endpoint compliance and attributes that have been > > > collected from endpoints and maybe persisted. It's just not useful > > > to use one term for all those kinds of things. > > > > > > I think that we need a new, more specific term for the things that > > > Dave described below: attribute identifiers, lists of attributes > > > that are to be collected and when and perhaps how, and policies > > > about what attribute values are acceptable for different kinds or > > > groups of endpoints. I suggest that we use the collective term > > > "guidance" for these things. This indicates that these things (and > > > maybe others to be added > > > later) guide the attribute collection and evaluation process. > > > > > > We also need to have a term for attribute values that have been > > > collected from endpoints. I vote for "collected attributes". > > > These attributes might be persisted (stored) or maybe not. > > > Either way, they are attribute values that have been collected from > > > endpoints. > > > > > > Thanks, > > > > > > Steve > > > > > >> -----Original Message----- > > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > > Engelbach > > >> Sent: Wednesday, February 05, 2014 7:37 PM > > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > > (pkampana); > > >> sacm@ietf.org > > >> Subject: Re: [sacm] Types of content > > >> > > >> > > >> I would prefer to reserve the term "content" for the instructional > > >> documentation. That is, the documents that cause an action, be it > > >> legislation, prose guidance, or a set of machine instructions that > > >> implement that guidance. > > >> > > >> We typically use "system characteristics" when referring to > > collected > > >> items, and variations on "endpoint attributes" has been used > > frequently > > >> on this list. System characteristics are the product of applying > > >> content to an endpoint. > > >> > > >> Collectively it's all data. Is there a desire to have a general > > term > > >> for all data that could flow through a SACM implementation but is > > >> specific to SACM? > > >> > > >> > > >> Also, while I agree with the need to allow the ability to persist > > >> collected data items (and the results of posture evaluations), I > > don't > > >> see that as a requirement. > > >> > > >> > > >> > > >> > > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > > >>> Dictionaries of posture attributes was not intended to include > > >> attribute > > >>> values. IETF examples of this concept might include attributes in > > >>> a > > >> MIB > > >>> or a NETMOD model. > > >>> > > >>> I agree that we need to "persist" posture attribute values. I have > > >>> always been on the fence personally about calling collection and > > >>> evaluation results "content". I agree 100% that we need to be > > crystal > > >>> clear about what we mean when we use the terms "content" and > > "content > > >>> repository". If we choose to lump all of this together as > > "content", > > >> we > > >>> will need to include some discussion in the use case document > > >>> contrasting different types of content to drive discussion of > > content > > >>> type-specific requirements. > > >>> > > >>> I also personally like Ira's feedback on using a more specific > > >> term(s) > > >>> instead of the more general "content". > > >>> > > >>> I also share the same personal view around interacting with stores > > of > > >>> collected posture attribute values and evaluation results. The > > larger > > >>> data volumes and rate of change will likely require different > > >>> approaches. I also believe that the temporal nature of this data, > > the > > >>> need to persist historic information, will be more significant > > >>> than other types of data that we may call "content". > > >>> > > >>> Are there other opinions on this? Does anyone feel strongly that > > >>> collected posture attribute values and evaluation results SHOULD > > NOT > > >> be > > >>> considered content? > > >>> > > >>> Thanks, > > >>> > > >>> Dave > > >>> > > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > > >> sacm@ietf.org > > >>> *Subject:* RE: Types of content > > >>> > > >>> Would "dictionaries of posture attributes" include attribute > > >>> values > > >> that > > >>> have been collected from endpoints? > > >>> > > >>> We want to have the ability to collect attribute values from > > >> endpoints > > >>> and "persist" them, as described in section 2.1.3. So we'll need > > >>> to > > >> have > > >>> a repository for collected and persisted attribute values. > > >>> > > >>> If collected endpoint attribute values are considered content, > > let's > > >> say > > >>> so. If not, let's say that explicitly. > > >>> > > >>> My personal view is that collected endpoint attribute values > > >>> should > > >> be > > >>> considered content. They may be a different kind of content from > > the > > >>> others due to larger volume and higher change rate. For that > > reason, > > >>> people may choose to put them into a different repository and > > >>> maybe > > >> even > > >>> use a different query protocol for that repository to munge the > > large > > >>> quantities of data. But they're still content. > > >>> > > >>> Thanks, > > >>> > > >>> Steve > > >>> > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > > >>> Kampanakis (pkampana) > > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > > >>> *To:* Waltermire, David A.; sacm@ietf.org > > >>> *Subject:* Re: [sacm] Types of content > > >>> > > >>> Sounds like a good summary of what "content" could mean. > > >>> > > >>> Panos > > >>> > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > > *Waltermire, > > >>> David A. > > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > > >>> *To:* sacm@ietf.org > > >>> *Subject:* [sacm] Types of content > > >>> > > >>> I'm working through the UC draft addressing discussion items from > > >>> yesterday and the previous comments we have received on the list > > >>> on > > - > > >> 05. > > >>> > > >>> Related to section 2.1.1, we have had many previous discussions > > >> around > > >>> the notional idea of content. There has been general agreement > > >>> that > > >> we > > >>> need to be more specific. Please find below an attempt to put some > > >>> "bounds" around different types of content. > > >>> > > >>> Is this hitting the mark, or do we need to say something > > >> more/different? > > >>> > > >>> The following is a snippet from a possible update to section 2.1.1 > > >> with > > >>> some additional description: > > >>> > > >>> I'd appreciate any thoughts, concerns, objections before I include > > >> the > > >>> changes in the draft. > > >>> > > >>> Thanks, > > >>> > > >>> Dave > > >>> > > >>> 2.1.1. Define, Publish, Query and Retrieve Content > > >>> > > >>> This use case describes the need for content to be defined > > >>> and > > >>> > > >>> published to a data store, as well as queried and retrieved > > from > > >> the > > >>> > > >>> data store for the explicit use of posture collection and > > >> evaluation. > > >>> > > >>> The term "content" is a general concept that refers to any > > data > > >>> > > >>> expression that may be used as part of the process of > > collecting > > >> and > > >>> > > >>> evaluating endpoint posture. Typical types of content > > include: > > >>> > > >>> o Dictionaries of posture attributes (e.g. software > > >> installation, > > >>> > > >>> configuration, privileges) that may be collected from a > > given > > >>> > > >>> endpoint type that relate to installed hardware, installed > > >>> > > >>> software, software configurations, accounts, privileges, > > and > > >> other > > >>> > > >>> operational state. > > >>> > > >>> o Expressions that provide instructions for using a specific > > >> API, > > >>> > > >>> management protocol, or other mechanisms to collect > > specific > > >>> > > >>> posture attributes from specific device types. > > >>> > > >>> o Policies that define the selected posture attributes for > > which > > >>> > > >>> values must be collected to support one or more posture > > >>> > > >>> assessments. This may include information that targets > > >> collection > > >>> > > >>> to a specific set of endpoints and instructions on the > > >> frequency > > >>> > > >>> and/or change events (e.g., configuration changes, > > >>> software > > >>> > > >>> installation/uninstallation, account/privilege > > modifications) > > >> that > > >>> > > >>> will trigger collection of one or more posture attributes. > > >>> > > >>> o Policies that define the logical criteria to evaluate > > >> collected > > >>> > > >>> posture attribute values to determine if they meet > > >> organizational > > >>> > > >>> requirements. This may include information that targets > > >>> > > >>> evaluation to a specific set of endpoints. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> sacm mailing list > > >>> sacm@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sacm > > >>> > > >> _______________________________________________ > > >> sacm mailing list > > >> sacm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sacm > > >> > > > > > > > > >=20 From gunnar.engelbach@threatguard.com Tue Feb 11 18:27:07 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CA11A07A6 for ; Tue, 11 Feb 2014 18:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5ZAFqGl9BQS for ; Tue, 11 Feb 2014 18:27:03 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id DC7771A070B for ; Tue, 11 Feb 2014 18:27:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=MCTJT6nxCF6zYtTlWYUkH3NrtrgiyBtiETMTwXcyd5FNrQdLCIPP45qkxjg7BsmvzxLwE1H3DKgX/ZC9/gnL2jlTE+uXwGgMN/wUdn/isSvrNVaIycXm7wW+w+8zm2ze; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 22274 invoked from network); 11 Feb 2014 18:33:43 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 11 Feb 2014 18:33:42 -0800 Message-ID: <52FADBF7.9070705@ThreatGuard.com> Date: Tue, 11 Feb 2014 21:27:03 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Waltermire, David A." , Stephen Hanna , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 02:27:07 -0000 On 2/11/2014 7:13 PM, Waltermire, David A. wrote: > I'd like to get the discussion around this topic to a point where I have clear editorial direction on what text we want included in the updated use case draft for this Friday's submission cutoff deadline. > > Based on the mailing list discussions to date, I'd like to propose the following categories of security automation data for inclusion in the use cases draft: Guidance, Endpoint/Asset Attribute Data, and Processing Artifacts. > > The following sections roughly define each of the proposed categories. For each section some insights are provided into the how the data might be sourced and how often it may change. I have also included examples of the classes of information for each category with mappings to the use cases and building blocks they support to insure we have the necessary coverage. > > To move forward I need answers to the following questions: > > 1) Do you like these groupings? If not, is there a better set of groupings? Categorizing in this manner makes a lot of sense to me. I can see an argument for lumping Attribute Artifacts and Processing Artifacts together, but I would prefer that they not be. > 2) Do you like the labels for each of the groups? If not, do you have a better label(s)? "Guidance" is great. I'd like to simplify "Endpoint/Asset Attribute Data" to just "Attribute Data." "Collected Artifacts" also works for me, except that it's easier to confuse the terms if two of them have "Artifacts" in their name. "Processing Artifacts" isn't really clicking with me, but I can't think of anything better. Before reading your descriptive text I knew from the name what you were getting at, so it's got that going for it. > 3) Are there other types of content that should be included? Yes. Guidance should also include the guidance that the automated guidance is meant to fulfill. The prose guidance that the STIGS are drawn from, for example. Vendor best practices documents. Legal guidance and legislation. Guidance can also be instructional materials related to the other content. > 4) What level of detail should be included in the use cases draft regarding this discussion? What I have below is likely too much detail. I have no problem with this level of detail, and more, but if it's too much then maybe the bulk of it could live in an appendix. > > Thanks, > Dave > > Guidance: > ------------ > The term "guidance" was proposed by Steve Hanna and was supported by Gunnar Engelbach on the list. Steve proposed that this concept encompasses "attribute identifiers, lists of attributes that are to be collected and when and perhaps how, and policies about what attribute values are acceptable for different kinds or groups of endpoints. This indicates that these things (and maybe others to be added later) guide the attribute collection and evaluation process." I would also add that this should include instructions supporting data-driven evaluation processes. > > This data tends to change in units of months and days. In cases where assessments are made more dynamic, it may be necessary to handle changes in the scope of hours or minutes. This data will typically be provided by large organizations, product vendors, and some 3rd-parties. Thus, it will tend to be shared across large enterprises and customer communities. In some cases access may be controlled to specific authenticated users. In other cases, the data may be provided broadly with little to no access control. > > This would include: > > - Applicability Statements: Data the identifies the conditional applicability of an assessment (and related assessment "guidance") based on automated collection of endpoint posture attribute values and other endpoint characterizations. > + Endpoint Identification and Assessment Planning BB: Identify Endpoint Targets - This supports the targeting concept allowing characterizations and collected posture attribute values to be evaluated to determine what set of endpoints should be assessed. > > - Collection Instructions: Data that drives the identification of the set of posture attributes needed to perform an assessment and the collection of posture attributes. > + Endpoint Identification and Assessment Planning BB: Posture Attribute Identification - Used to determine the set of posture attributes for which values must be collected (or retrieved) to support the evaluation. > + Endpoint Posture Attribute Value Collection BB: Collection Content Acquisition - Data is retrieved based on its relationship to the assessment and other applicability concepts to drive collection activities. > + Endpoint Posture Attribute Value Collection BB: Posture Attribute Value Collection - Directives on how the posture attributes should be collected. This may include: events to monitor, scheduling info, instructions for using specific models/protocols, etc. > > - Evaluation instructions: Data the identifies what endpoint posture attribute values are to be evaluated and how this evaluation should be performed. > + Endpoint Identification and Assessment Planning BB: Posture Attribute Identification - Use to determine the set of posture attributes for which values are required for evaluation. > + Posture Evaluation BB: Evaluation Content Acquisition - Data is retrieved based on its relationship to the assessment and other applicability concepts to drive evaluation activities. > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs the evaluation of collected endpoint posture attribute values. This will likely include comparison operators and logical constructs. Additional instructions might indicate the required result output format. > > Our information model will need to relate the concepts of applicability statements, collection instructions, and evaluation instructions in support of assessment activities. > > Endpoint/Asset Attribute Data: > -------------------------------------- > > This category includes contextual metadata pertaining to endpoints and the assets that they are composed of (e.g., hardware, software, accounts), and collected endpoint posture attributes, their associated values, and related context. > > This data tends to change in units of days, minutes, a seconds with posture attribute values typically changing more frequently than endpoint characterizations. This data tends to be organizationally and endpoint specific, with specific operational groups of endpoints tending to exhibit similar attribute profiles. This data will generally not be shared outside an organizational boundary and will generally require authentication with specific access controls. > > This would include: > > - Characterizations of endpoints: Endpoint metadata that describes the endpoint type, organizationally expected function/role, etc. > + Endpoint Identification and Assessment Planning BB: Endpoint Characterization - Gathered through automated posture attribute collection, manual data entry/query, and interactions with other data stores. > > - Collected Posture Attributes: Posture attributes and associated values collected from endpoints representing hardware, software inventory, configurations, accounts/privileges, and other aspects of endpoint state. > + Endpoint Identification and Assessment Planning BB: Endpoint Component Inventory - This provides context to identify what posture attributes should be collected as part of the assessment based on the current endpoint posture (e.g., what software is installed). > + Endpoint Posture Attribute Value Collection BB: Posture Attribute Value Collection - For each targeted endpoint, the set of collected posture attributes and associated values. The result of collection. > + Posture Evaluation BB: Posture Attribute Value Query - The retrieval of a set of previously collected posture attributes and associated values. This may not be required if collected data is fed directly to an evaluator after collection. > > An important dimension here may be the separation between actual and expected posture attribute values. It may be possible to express guidance in a way that allows expected values to parameterized. In this case it will be necessary to allow for organizationally expected values to be associated with defined guidance (perhaps provided by a different party). > > Our information model will need to relate the concepts of endpoint characterizations and collected posture information to the types of guidance data. > > Processing Artifacts: > ------------------------- > > This type of data is generated by and is specific to an individual assessment process. This data may be used as part of the interactions between SACM architectural components to drive and coordinate collection and evaluation activities. Its lifespan will be bounded by the lifespan of the assessment. It may also be exchanged and stored to provide historic context around an assessment activity. > > This would include: > > - Endpoint Targets: An identified set of endpoints for which an assessment should be performed. > + Endpoint Identification and Assessment Planning BB: Identify Endpoint Targets - The endpoints targeted for an assessment. > > - Identified Posture Attributes > + Endpoint Identification and Assessment Planning BB: Posture Attribute Identification - The required posture attributes that need to be collected to perform the evaluation. > > - Assessment Results: The resulting output generated by the evaluation process. > + Posture Evaluation BB: Posture Attribute Evaluation - The results produced through the comparison of actual collected posture attribute > values against their expected state. The specific output an evaluation criteria may be specified by the required evaluation instructions. > > Our information model will need to relate these concepts to those provided in the other two categories. I know this is not saying much, but I am tired and ready to end this email. ;-) > >> -----Original Message----- >> From: Stephen Hanna [mailto:shanna@juniper.net] >> Sent: Wednesday, February 05, 2014 10:48 PM >> To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis (pkampana); >> sacm@ietf.org >> Subject: RE: [sacm] Types of content >> >> Gunnar Engelbach wrote: >>> So "Guidance" is input and "collected attributes" is the immediate >>> product? >> >> Right. At least, that's one way of describing it. >> I'm thinking that guidance would include all the things that Dave was >> previously calling "content". >> >>> That works. And is line with common usage. >> >> Good! I'm glad to hear that it makes sense to you. >> >>> And for the final result of applying the collected attributes to the >>> guidance, how about "assessment results?" >> >> Yes, I like that also. >> >>> Is there a need for anything more granular? >> >> Probably eventually. But there also seems to be a need for broad terms since >> people want to be able to put all the "guidance" into one repository >> (perhaps) and have a different kind of repository for "collected attributes" >> and maybe also "assessment results". >> >>> Mention of other terms commonly used for the same thing? >> >> Maybe. Listing alternative terms in common usage today can be confusing >> since different people may use those terms differently. >> >> Thanks, >> >> Steve >> >>> >>> >>> What I frequently see: >>> >>> Input: >>> Guidance >>> Content >>> Checklist >>> Questionnaire >>> Data stream >>> Benchmark >>> Definitions >>> >>> >>> Product: >>> Collected Attributes >>> System Characteristics >>> Assessment Results >>> Posture >>> >>> >>> >>> >>> On 2/5/2014 9:13 PM, Stephen Hanna wrote: >>>> The terms "content" and "data" are just too general. "SA content" >>>> isn't much better. It seems to include any kind of data related to >>>> security automation. In the long run, that might include lots of >>>> things like vulnerability reports and alerts that an intrusion has >>>> been detected and remediation or mitigation instructions. >>>> Also reports on endpoint compliance and attributes that have been >>>> collected from endpoints and maybe persisted. It's just not useful >>>> to use one term for all those kinds of things. >>>> >>>> I think that we need a new, more specific term for the things that >>>> Dave described below: attribute identifiers, lists of attributes >>>> that are to be collected and when and perhaps how, and policies >>>> about what attribute values are acceptable for different kinds or >>>> groups of endpoints. I suggest that we use the collective term >>>> "guidance" for these things. This indicates that these things (and >>>> maybe others to be added >>>> later) guide the attribute collection and evaluation process. >>>> >>>> We also need to have a term for attribute values that have been >>>> collected from endpoints. I vote for "collected attributes". >>>> These attributes might be persisted (stored) or maybe not. >>>> Either way, they are attribute values that have been collected from >>>> endpoints. >>>> >>>> Thanks, >>>> >>>> Steve >>>> >>>>> -----Original Message----- >>>>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar >>> Engelbach >>>>> Sent: Wednesday, February 05, 2014 7:37 PM >>>>> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis >>> (pkampana); >>>>> sacm@ietf.org >>>>> Subject: Re: [sacm] Types of content >>>>> >>>>> >>>>> I would prefer to reserve the term "content" for the instructional >>>>> documentation. That is, the documents that cause an action, be it >>>>> legislation, prose guidance, or a set of machine instructions that >>>>> implement that guidance. >>>>> >>>>> We typically use "system characteristics" when referring to >>> collected >>>>> items, and variations on "endpoint attributes" has been used >>> frequently >>>>> on this list. System characteristics are the product of applying >>>>> content to an endpoint. >>>>> >>>>> Collectively it's all data. Is there a desire to have a general >>> term >>>>> for all data that could flow through a SACM implementation but is >>>>> specific to SACM? >>>>> >>>>> >>>>> Also, while I agree with the need to allow the ability to persist >>>>> collected data items (and the results of posture evaluations), I >>> don't >>>>> see that as a requirement. >>>>> >>>>> >>>>> >>>>> >>>>> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: >>>>>> Dictionaries of posture attributes was not intended to include >>>>> attribute >>>>>> values. IETF examples of this concept might include attributes in >>>>>> a >>>>> MIB >>>>>> or a NETMOD model. >>>>>> >>>>>> I agree that we need to "persist" posture attribute values. I have >>>>>> always been on the fence personally about calling collection and >>>>>> evaluation results "content". I agree 100% that we need to be >>> crystal >>>>>> clear about what we mean when we use the terms "content" and >>> "content >>>>>> repository". If we choose to lump all of this together as >>> "content", >>>>> we >>>>>> will need to include some discussion in the use case document >>>>>> contrasting different types of content to drive discussion of >>> content >>>>>> type-specific requirements. >>>>>> >>>>>> I also personally like Ira's feedback on using a more specific >>>>> term(s) >>>>>> instead of the more general "content". >>>>>> >>>>>> I also share the same personal view around interacting with stores >>> of >>>>>> collected posture attribute values and evaluation results. The >>> larger >>>>>> data volumes and rate of change will likely require different >>>>>> approaches. I also believe that the temporal nature of this data, >>> the >>>>>> need to persist historic information, will be more significant >>>>>> than other types of data that we may call "content". >>>>>> >>>>>> Are there other opinions on this? Does anyone feel strongly that >>>>>> collected posture attribute values and evaluation results SHOULD >>> NOT >>>>> be >>>>>> considered content? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Dave >>>>>> >>>>>> *From:*Stephen Hanna [mailto:shanna@juniper.net] >>>>>> *Sent:* Wednesday, February 05, 2014 6:10 PM >>>>>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; >>>>> sacm@ietf.org >>>>>> *Subject:* RE: Types of content >>>>>> >>>>>> Would "dictionaries of posture attributes" include attribute >>>>>> values >>>>> that >>>>>> have been collected from endpoints? >>>>>> >>>>>> We want to have the ability to collect attribute values from >>>>> endpoints >>>>>> and "persist" them, as described in section 2.1.3. So we'll need >>>>>> to >>>>> have >>>>>> a repository for collected and persisted attribute values. >>>>>> >>>>>> If collected endpoint attribute values are considered content, >>> let's >>>>> say >>>>>> so. If not, let's say that explicitly. >>>>>> >>>>>> My personal view is that collected endpoint attribute values >>>>>> should >>>>> be >>>>>> considered content. They may be a different kind of content from >>> the >>>>>> others due to larger volume and higher change rate. For that >>> reason, >>>>>> people may choose to put them into a different repository and >>>>>> maybe >>>>> even >>>>>> use a different query protocol for that repository to munge the >>> large >>>>>> quantities of data. But they're still content. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve >>>>>> >>>>>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos >>>>>> Kampanakis (pkampana) >>>>>> *Sent:* Wednesday, February 05, 2014 5:25 PM >>>>>> *To:* Waltermire, David A.; sacm@ietf.org >>>>>> *Subject:* Re: [sacm] Types of content >>>>>> >>>>>> Sounds like a good summary of what "content" could mean. >>>>>> >>>>>> Panos >>>>>> >>>>>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of >>> *Waltermire, >>>>>> David A. >>>>>> *Sent:* Wednesday, February 05, 2014 10:38 PM >>>>>> *To:* sacm@ietf.org >>>>>> *Subject:* [sacm] Types of content >>>>>> >>>>>> I'm working through the UC draft addressing discussion items from >>>>>> yesterday and the previous comments we have received on the list >>>>>> on >>> - >>>>> 05. >>>>>> >>>>>> Related to section 2.1.1, we have had many previous discussions >>>>> around >>>>>> the notional idea of content. There has been general agreement >>>>>> that >>>>> we >>>>>> need to be more specific. Please find below an attempt to put some >>>>>> "bounds" around different types of content. >>>>>> >>>>>> Is this hitting the mark, or do we need to say something >>>>> more/different? >>>>>> >>>>>> The following is a snippet from a possible update to section 2.1.1 >>>>> with >>>>>> some additional description: >>>>>> >>>>>> I'd appreciate any thoughts, concerns, objections before I include >>>>> the >>>>>> changes in the draft. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Dave >>>>>> >>>>>> 2.1.1. Define, Publish, Query and Retrieve Content >>>>>> >>>>>> This use case describes the need for content to be defined >>>>>> and >>>>>> >>>>>> published to a data store, as well as queried and retrieved >>> from >>>>> the >>>>>> >>>>>> data store for the explicit use of posture collection and >>>>> evaluation. >>>>>> >>>>>> The term "content" is a general concept that refers to any >>> data >>>>>> >>>>>> expression that may be used as part of the process of >>> collecting >>>>> and >>>>>> >>>>>> evaluating endpoint posture. Typical types of content >>> include: >>>>>> >>>>>> o Dictionaries of posture attributes (e.g. software >>>>> installation, >>>>>> >>>>>> configuration, privileges) that may be collected from a >>> given >>>>>> >>>>>> endpoint type that relate to installed hardware, installed >>>>>> >>>>>> software, software configurations, accounts, privileges, >>> and >>>>> other >>>>>> >>>>>> operational state. >>>>>> >>>>>> o Expressions that provide instructions for using a specific >>>>> API, >>>>>> >>>>>> management protocol, or other mechanisms to collect >>> specific >>>>>> >>>>>> posture attributes from specific device types. >>>>>> >>>>>> o Policies that define the selected posture attributes for >>> which >>>>>> >>>>>> values must be collected to support one or more posture >>>>>> >>>>>> assessments. This may include information that targets >>>>> collection >>>>>> >>>>>> to a specific set of endpoints and instructions on the >>>>> frequency >>>>>> >>>>>> and/or change events (e.g., configuration changes, >>>>>> software >>>>>> >>>>>> installation/uninstallation, account/privilege >>> modifications) >>>>> that >>>>>> >>>>>> will trigger collection of one or more posture attributes. >>>>>> >>>>>> o Policies that define the logical criteria to evaluate >>>>> collected >>>>>> >>>>>> posture attribute values to determine if they meet >>>>> organizational >>>>>> >>>>>> requirements. This may include information that targets >>>>>> >>>>>> evaluation to a specific set of endpoints. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>> >>>> >>> >> > From kimberly.watson@hq.dhs.gov Wed Feb 12 09:31:05 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264F11A0684 for ; Wed, 12 Feb 2014 09:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNRESOLVED_TEMPLATE=1.252] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGsvBc7gFbLt for ; Wed, 12 Feb 2014 09:30:56 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8681B1A0376 for ; Wed, 12 Feb 2014 09:30:54 -0800 (PST) Received: from mail102-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Feb 2014 17:30:53 +0000 Received: from mail102-ch1 (localhost [127.0.0.1]) by mail102-ch1-R.bigfish.com (Postfix) with ESMTP id 6F55F22026E; Wed, 12 Feb 2014 17:30:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:216.81.82.138; KIP:(null); UIP:(null); IPV:NLI; H:d2iblprhq101.dhs.gov; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zzbb2dI98dI9371I542I1432I1418I4015I11fbI168aJzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz1de098h1033IL8275dh1de097h186068hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh1155h) Received: from mail102-ch1 (localhost.localdomain [127.0.0.1]) by mail102-ch1 (MessageSwitch) id 1392226251699281_23507; Wed, 12 Feb 2014 17:30:51 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail102-ch1.bigfish.com (Postfix) with ESMTP id A46F52E0060; Wed, 12 Feb 2014 17:30:51 +0000 (UTC) Received: from d2iblprhq101.dhs.gov (216.81.82.138) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 12 Feb 2014 17:30:51 +0000 Received: from D2IBLPRHQ106.dhs.gov (192.168.49.136) by D2IBLPRHQ101.dhs.gov (10.82.0.52) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 11 Feb 2014 12:29:46 -0500 Received: from D2ABLPRHQ103.DSA.DHS (10.237.115.14) by D2IBLPRHQ106.dhs.gov (10.82.4.53) with Microsoft SMTP Server (TLS) id 14.2.347.0; Wed, 12 Feb 2014 12:30:29 -0500 Received: from D2ASEPREA006.DSA.DHS ([169.254.10.89]) by D2ABLPRHQ103.DSA.DHS ([fe80::15d4:e9b9:8b5:7449%10]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 12:30:31 -0500 From: "Watson, Kimberly" To: "Waltermire, David A." , Stephen Hanna , Gunnar Engelbach , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: AQHPJ5n2Wof41vaRa0iaeufxSwKwwJqx3TKw Date: Wed, 12 Feb 2014 17:30:30 +0000 Message-ID: References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.235.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hq.dhs.gov X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:31:05 -0000 1) Do you like these groupings? If not, is there a better set of groupings? The categorization makes sense. Processing Artifacts and Attribute Data mus= t be associated, but they are very separate things, so I prefer to keep the= m apart. 2) Do you like the labels for each of the groups? If not, do you have a bet= ter label(s)? Agree with removing endpoint/asset and sticking with Attribute Data to keep= things simpler. I could not come up with a better label for Processing Artifacts - since th= ey seems to represent meta-data about collection and/or evaluation such tha= t individual assessments can be grouped/evaluated/reported in an enterprise= context. Guidance is fine label. 3) Are there other types of content that should be included? There is definitely a hierarchy of policy, so it makes perfect sense to me = that there is a hierarchy of guidance. It might just be best to acknowledge= that hierarchies can be represented and make sure we have content that sup= ports that... There is a need to be able to know what guidance was used for any processin= g, since it can be dynamic (as stated in the text). That means we now have = what was assessed, what it was assessed against, what was used, and what th= e results were...i think we are missing when the attributes were collected = and when the attributes were evaluated. I think this is necessary to suppor= t the independent aspects of the two processes to support assessments. I fu= lly expect guidance to specify how old collected data can be to be used for= evaluation - which means we need to be able to report a result that assess= ment didn't occur because collection did not occur and previous collection = was too old. Maybe a time artifact is already included (by default), but I= want to make sure it isn't in there because it doesn't need to be... 4) What level of detail should be included in the use cases draft regarding= this discussion? What I have below is likely too much detail. I have no background to make any suggestion about this, but I like the leve= l of detail used here to describe things, and I would be willing to accept = even more detail where necessary to make the delineating/defining point. -- Kim Watson Office of Cybersecurity and Communications Federal Network Resilience Blackberry: (202) 494-2534 -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, February 11, 2014 7:13 PM To: Stephen Hanna; Gunnar Engelbach; Panos Kampanakis (pkampana); sacm@ietf= .org Subject: Re: [sacm] Types of content I'd like to get the discussion around this topic to a point where I have cl= ear editorial direction on what text we want included in the updated use ca= se draft for this Friday's submission cutoff deadline. Based on the mailing list discussions to date, I'd like to propose the foll= owing categories of security automation data for inclusion in the use cases= draft: Guidance, Endpoint/Asset Attribute Data, and Processing Artifacts. The following sections roughly define each of the proposed categories. For = each section some insights are provided into the how the data might be sour= ced and how often it may change. I have also included examples of the class= es of information for each category with mappings to the use cases and buil= ding blocks they support to insure we have the necessary coverage. To move forward I need answers to the following questions: 1) Do you like these groupings? If not, is there a better set of groupings? 2) Do you like the labels for each of the groups? If not, do you have a bet= ter label(s)? 3) Are there other types of content that should be included? 4) What level of detail should be included in the use cases draft regarding= this discussion? What I have below is likely too much detail. Thanks, Dave Guidance: ------------ The term "guidance" was proposed by Steve Hanna and was supported by Gunnar= Engelbach on the list. Steve proposed that this concept encompasses "attri= bute identifiers, lists of attributes that are to be collected and when and= perhaps how, and policies about what attribute values are acceptable for d= ifferent kinds or groups of endpoints. This indicates that these things (an= d maybe others to be added later) guide the attribute collection and evalua= tion process." I would also add that this should include instructions suppo= rting data-driven evaluation processes. This data tends to change in units of months and days. In cases where asses= sments are made more dynamic, it may be necessary to handle changes in the = scope of hours or minutes. This data will typically be provided by large or= ganizations, product vendors, and some 3rd-parties. Thus, it will tend to b= e shared across large enterprises and customer communities. In some cases a= ccess may be controlled to specific authenticated users. In other cases, th= e data may be provided broadly with little to no access control. This would include: - Applicability Statements: Data the identifies the conditional applicabili= ty of an assessment (and related assessment "guidance") based on automated = collection of endpoint posture attribute values and other endpoint characte= rizations. + Endpoint Identification and Assessment Planning BB: Identify Endpoint= Targets - This supports the targeting concept allowing characterizations a= nd collected posture attribute values to be evaluated to determine what set= of endpoints should be assessed. - Collection Instructions: Data that drives the identification of the set o= f posture attributes needed to perform an assessment and the collection of = posture attributes. + Endpoint Identification and Assessment Planning BB: Posture Attribute= Identification - Used to determine the set of posture attributes for which= values must be collected (or retrieved) to support the evaluation. + Endpoint Posture Attribute Value Collection BB: Collection Content Ac= quisition - Data is retrieved based on its relationship to the assessment a= nd other applicability concepts to drive collection activities. + Endpoint Posture Attribute Value Collection BB: Posture Attribute Val= ue Collection - Directives on how the posture attributes should be collecte= d. This may include: events to monitor, scheduling info, instructions for u= sing specific models/protocols, etc. - Evaluation instructions: Data the identifies what endpoint posture attrib= ute values are to be evaluated and how this evaluation should be performed. + Endpoint Identification and Assessment Planning BB: Posture Attribute= Identification - Use to determine the set of posture attributes for which = values are required for evaluation. + Posture Evaluation BB: Evaluation Content Acquisition - Data is retri= eved based on its relationship to the assessment and other applicability co= ncepts to drive evaluation activities. + Posture Evaluation BB: Posture Attribute Evaluation - Instructs the e= valuation of collected endpoint posture attribute values. This will likely = include comparison operators and logical constructs. Additional instruction= s might indicate the required result output format. Our information model will need to relate the concepts of applicability sta= tements, collection instructions, and evaluation instructions in support of= assessment activities. Endpoint/Asset Attribute Data: -------------------------------------- This category includes contextual metadata pertaining to endpoints and the = assets that they are composed of (e.g., hardware, software, accounts), and = collected endpoint posture attributes, their associated values, and related= context. This data tends to change in units of days, minutes, a seconds with posture= attribute values typically changing more frequently than endpoint characte= rizations. This data tends to be organizationally and endpoint specific, wi= th specific operational groups of endpoints tending to exhibit similar attr= ibute profiles. This data will generally not be shared outside an organizat= ional boundary and will generally require authentication with specific acce= ss controls. This would include: - Characterizations of endpoints: Endpoint metadata that describes the endp= oint type, organizationally expected function/role, etc. + Endpoint Identification and Assessment Planning BB: Endpoint Characte= rization - Gathered through automated posture attribute collection, manual = data entry/query, and interactions with other data stores. - Collected Posture Attributes: Posture attributes and associated values co= llected from endpoints representing hardware, software inventory, configura= tions, accounts/privileges, and other aspects of endpoint state. + Endpoint Identification and Assessment Planning BB: Endpoint Componen= t Inventory - This provides context to identify what posture attributes sho= uld be collected as part of the assessment based on the current endpoint po= sture (e.g., what software is installed). + Endpoint Posture Attribute Value Collection BB: Posture Attribute Val= ue Collection - For each targeted endpoint, the set of collected posture at= tributes and associated values. The result of collection. + Posture Evaluation BB: Posture Attribute Value Query - The retrieval = of a set of previously collected posture attributes and associated values. = This may not be required if collected data is fed directly to an evaluator = after collection. An important dimension here may be the separation between actual and expect= ed posture attribute values. It may be possible to express guidance in a wa= y that allows expected values to parameterized. In this case it will be nec= essary to allow for organizationally expected values to be associated with = defined guidance (perhaps provided by a different party). Our information model will need to relate the concepts of endpoint characte= rizations and collected posture information to the types of guidance data. Processing Artifacts: ------------------------- This type of data is generated by and is specific to an individual assessme= nt process. This data may be used as part of the interactions between SACM = architectural components to drive and coordinate collection and evaluation = activities. Its lifespan will be bounded by the lifespan of the assessment.= It may also be exchanged and stored to provide historic context around an = assessment activity. This would include: - Endpoint Targets: An identified set of endpoints for which an assessment = should be performed. + Endpoint Identification and Assessment Planning BB: Identify Endpoint= Targets - The endpoints targeted for an assessment. - Identified Posture Attributes + Endpoint Identification and Assessment Planning BB: Posture Attribute= Identification - The required posture attributes that need to be collected= to perform the evaluation. - Assessment Results: The resulting output generated by the evaluation proc= ess. + Posture Evaluation BB: Posture Attribute Evaluation - The results pro= duced through the comparison of actual collected posture attribute values against their expected state. The specific output an evalua= tion criteria may be specified by the required evaluation instructions. Our information model will need to relate these concepts to those provided = in the other two categories. I know this is not saying much, but I am tired= and ready to end this email. ;-) > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, February 05, 2014 10:48 PM > To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis=20 > (pkampana); sacm@ietf.org > Subject: RE: [sacm] Types of content >=20 > Gunnar Engelbach wrote: > > So "Guidance" is input and "collected attributes" is the immediate=20 > > product? >=20 > Right. At least, that's one way of describing it. > I'm thinking that guidance would include all the things that Dave was=20 > previously calling "content". >=20 > > That works. And is line with common usage. >=20 > Good! I'm glad to hear that it makes sense to you. >=20 > > And for the final result of applying the collected attributes to the=20 > > guidance, how about "assessment results?" >=20 > Yes, I like that also. >=20 > > Is there a need for anything more granular? >=20 > Probably eventually. But there also seems to be a need for broad terms=20 > since people want to be able to put all the "guidance" into one=20 > repository > (perhaps) and have a different kind of repository for "collected attribut= es" > and maybe also "assessment results". >=20 > > Mention of other terms commonly used for the same thing? >=20 > Maybe. Listing alternative terms in common usage today can be=20 > confusing since different people may use those terms differently. >=20 > Thanks, >=20 > Steve >=20 > > > > > > What I frequently see: > > > > Input: > > Guidance > > Content > > Checklist > > Questionnaire > > Data stream > > Benchmark > > Definitions > > > > > > Product: > > Collected Attributes > > System Characteristics > > Assessment Results > > Posture > > > > > > > > > > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > > > The terms "content" and "data" are just too general. "SA content" > > > isn't much better. It seems to include any kind of data related to=20 > > > security automation. In the long run, that might include lots of=20 > > > things like vulnerability reports and alerts that an intrusion has=20 > > > been detected and remediation or mitigation instructions. > > > Also reports on endpoint compliance and attributes that have been=20 > > > collected from endpoints and maybe persisted. It's just not useful=20 > > > to use one term for all those kinds of things. > > > > > > I think that we need a new, more specific term for the things that=20 > > > Dave described below: attribute identifiers, lists of attributes=20 > > > that are to be collected and when and perhaps how, and policies=20 > > > about what attribute values are acceptable for different kinds or=20 > > > groups of endpoints. I suggest that we use the collective term=20 > > > "guidance" for these things. This indicates that these things (and=20 > > > maybe others to be added > > > later) guide the attribute collection and evaluation process. > > > > > > We also need to have a term for attribute values that have been=20 > > > collected from endpoints. I vote for "collected attributes". > > > These attributes might be persisted (stored) or maybe not. > > > Either way, they are attribute values that have been collected=20 > > > from endpoints. > > > > > > Thanks, > > > > > > Steve > > > > > >> -----Original Message----- > > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > > Engelbach > > >> Sent: Wednesday, February 05, 2014 7:37 PM > > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > > (pkampana); > > >> sacm@ietf.org > > >> Subject: Re: [sacm] Types of content > > >> > > >> > > >> I would prefer to reserve the term "content" for the=20 > > >> instructional documentation. That is, the documents that cause=20 > > >> an action, be it legislation, prose guidance, or a set of machine=20 > > >> instructions that implement that guidance. > > >> > > >> We typically use "system characteristics" when referring to > > collected > > >> items, and variations on "endpoint attributes" has been used > > frequently > > >> on this list. System characteristics are the product of applying=20 > > >> content to an endpoint. > > >> > > >> Collectively it's all data. Is there a desire to have a general > > term > > >> for all data that could flow through a SACM implementation but is=20 > > >> specific to SACM? > > >> > > >> > > >> Also, while I agree with the need to allow the ability to persist=20 > > >> collected data items (and the results of posture evaluations), I > > don't > > >> see that as a requirement. > > >> > > >> > > >> > > >> > > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > > >>> Dictionaries of posture attributes was not intended to include > > >> attribute > > >>> values. IETF examples of this concept might include attributes=20 > > >>> in a > > >> MIB > > >>> or a NETMOD model. > > >>> > > >>> I agree that we need to "persist" posture attribute values. I=20 > > >>> have always been on the fence personally about calling=20 > > >>> collection and evaluation results "content". I agree 100% that=20 > > >>> we need to be > > crystal > > >>> clear about what we mean when we use the terms "content" and > > "content > > >>> repository". If we choose to lump all of this together as > > "content", > > >> we > > >>> will need to include some discussion in the use case document=20 > > >>> contrasting different types of content to drive discussion of > > content > > >>> type-specific requirements. > > >>> > > >>> I also personally like Ira's feedback on using a more specific > > >> term(s) > > >>> instead of the more general "content". > > >>> > > >>> I also share the same personal view around interacting with=20 > > >>> stores > > of > > >>> collected posture attribute values and evaluation results. The > > larger > > >>> data volumes and rate of change will likely require different=20 > > >>> approaches. I also believe that the temporal nature of this=20 > > >>> data, > > the > > >>> need to persist historic information, will be more significant=20 > > >>> than other types of data that we may call "content". > > >>> > > >>> Are there other opinions on this? Does anyone feel strongly that=20 > > >>> collected posture attribute values and evaluation results SHOULD > > NOT > > >> be > > >>> considered content? > > >>> > > >>> Thanks, > > >>> > > >>> Dave > > >>> > > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > > >> sacm@ietf.org > > >>> *Subject:* RE: Types of content > > >>> > > >>> Would "dictionaries of posture attributes" include attribute=20 > > >>> values > > >> that > > >>> have been collected from endpoints? > > >>> > > >>> We want to have the ability to collect attribute values from > > >> endpoints > > >>> and "persist" them, as described in section 2.1.3. So we'll need=20 > > >>> to > > >> have > > >>> a repository for collected and persisted attribute values. > > >>> > > >>> If collected endpoint attribute values are considered content, > > let's > > >> say > > >>> so. If not, let's say that explicitly. > > >>> > > >>> My personal view is that collected endpoint attribute values=20 > > >>> should > > >> be > > >>> considered content. They may be a different kind of content from > > the > > >>> others due to larger volume and higher change rate. For that > > reason, > > >>> people may choose to put them into a different repository and=20 > > >>> maybe > > >> even > > >>> use a different query protocol for that repository to munge the > > large > > >>> quantities of data. But they're still content. > > >>> > > >>> Thanks, > > >>> > > >>> Steve > > >>> > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos=20 > > >>> Kampanakis (pkampana) > > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > > >>> *To:* Waltermire, David A.; sacm@ietf.org > > >>> *Subject:* Re: [sacm] Types of content > > >>> > > >>> Sounds like a good summary of what "content" could mean. > > >>> > > >>> Panos > > >>> > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > > *Waltermire, > > >>> David A. > > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > > >>> *To:* sacm@ietf.org > > >>> *Subject:* [sacm] Types of content > > >>> > > >>> I'm working through the UC draft addressing discussion items=20 > > >>> from yesterday and the previous comments we have received on the=20 > > >>> list on > > - > > >> 05. > > >>> > > >>> Related to section 2.1.1, we have had many previous discussions > > >> around > > >>> the notional idea of content. There has been general agreement=20 > > >>> that > > >> we > > >>> need to be more specific. Please find below an attempt to put=20 > > >>> some "bounds" around different types of content. > > >>> > > >>> Is this hitting the mark, or do we need to say something > > >> more/different? > > >>> > > >>> The following is a snippet from a possible update to section=20 > > >>> 2.1.1 > > >> with > > >>> some additional description: > > >>> > > >>> I'd appreciate any thoughts, concerns, objections before I=20 > > >>> include > > >> the > > >>> changes in the draft. > > >>> > > >>> Thanks, > > >>> > > >>> Dave > > >>> > > >>> 2.1.1. Define, Publish, Query and Retrieve Content > > >>> > > >>> This use case describes the need for content to be defined=20 > > >>> and > > >>> > > >>> published to a data store, as well as queried and retrieved > > from > > >> the > > >>> > > >>> data store for the explicit use of posture collection and > > >> evaluation. > > >>> > > >>> The term "content" is a general concept that refers to any > > data > > >>> > > >>> expression that may be used as part of the process of > > collecting > > >> and > > >>> > > >>> evaluating endpoint posture. Typical types of content > > include: > > >>> > > >>> o Dictionaries of posture attributes (e.g. software > > >> installation, > > >>> > > >>> configuration, privileges) that may be collected from a > > given > > >>> > > >>> endpoint type that relate to installed hardware,=20 > > >>> installed > > >>> > > >>> software, software configurations, accounts, privileges, > > and > > >> other > > >>> > > >>> operational state. > > >>> > > >>> o Expressions that provide instructions for using a=20 > > >>> specific > > >> API, > > >>> > > >>> management protocol, or other mechanisms to collect > > specific > > >>> > > >>> posture attributes from specific device types. > > >>> > > >>> o Policies that define the selected posture attributes for > > which > > >>> > > >>> values must be collected to support one or more posture > > >>> > > >>> assessments. This may include information that targets > > >> collection > > >>> > > >>> to a specific set of endpoints and instructions on the > > >> frequency > > >>> > > >>> and/or change events (e.g., configuration changes,=20 > > >>> software > > >>> > > >>> installation/uninstallation, account/privilege > > modifications) > > >> that > > >>> > > >>> will trigger collection of one or more posture attributes. > > >>> > > >>> o Policies that define the logical criteria to evaluate > > >> collected > > >>> > > >>> posture attribute values to determine if they meet > > >> organizational > > >>> > > >>> requirements. This may include information that targets > > >>> > > >>> evaluation to a specific set of endpoints. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> sacm mailing list > > >>> sacm@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sacm > > >>> > > >> _______________________________________________ > > >> sacm mailing list > > >> sacm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sacm > > >> > > > > > > > > >=20 From gunnar.engelbach@threatguard.com Wed Feb 12 10:27:29 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1976E1A066C for ; Wed, 12 Feb 2014 10:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fu1HkP1NKce for ; Wed, 12 Feb 2014 10:27:24 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 360ED1A06BA for ; Wed, 12 Feb 2014 10:27:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=CpJJeb2uhgLnbKC70Vtz3WbPgFq0RGdDutOBNqSLtb/h0PeMvAFnsIBIhTB+ENDpmOsnpRucxcE6lOGMFFDnOiy2dJOy8gguUN0CluLLWG1moXl4L2HgCjjBKusqGjES; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 18489 invoked from network); 12 Feb 2014 10:34:04 -0800 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 12 Feb 2014 10:34:03 -0800 Message-ID: <52FBBD0C.8020602@ThreatGuard.com> Date: Wed, 12 Feb 2014 13:27:24 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Watson, Kimberly" , "Waltermire, David A." , Stephen Hanna , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 18:27:29 -0000 On 2/12/2014 12:30 PM, Watson, Kimberly wrote: > 1) Do you like these groupings? If not, is there a better set of groupings? > > The categorization makes sense. Processing Artifacts and Attribute Data must be associated, but they are very separate things, so I prefer to keep them apart. > > 2) Do you like the labels for each of the groups? If not, do you have a better label(s)? > > Agree with removing endpoint/asset and sticking with Attribute Data to keep things simpler. > I could not come up with a better label for Processing Artifacts - since they seems to represent meta-data about collection and/or evaluation such that individual assessments can be grouped/evaluated/reported in an enterprise context. > Guidance is fine label. > > 3) Are there other types of content that should be included? > > There is definitely a hierarchy of policy, so it makes perfect sense to me that there is a hierarchy of guidance. It might just be best to acknowledge that hierarchies can be represented and make sure we have content that supports that... > > There is a need to be able to know what guidance was used for any processing, since it can be dynamic (as stated in the text). That means we now have what was assessed, what it was assessed against, what was used, and what the results were...i think we are missing when the attributes were collected and when the attributes were evaluated. I think this is necessary to support the independent aspects of the two processes to support assessments. I fully expect guidance to specify how old collected data can be to be used for evaluation - which means we need to be able to report a result that assessment didn't occur because collection did not occur and previous collection was too old. Maybe a time artifact is already included (by default), but I want to make sure it isn't in there because it doesn't need to be... Thanks for the reminder. The age of a collected artifact is something that came up in early discussions, along with information to help determine the level of trust that should be placed on the value such as the source of the artifact, what entities it has passed through from collection to usage, a signature, etc. That kind of metadata falls within the Collected Artifacts category but is more specific to SACM -- something we need to remember to get into the requirements. > > 4) What level of detail should be included in the use cases draft regarding this discussion? What I have below is likely too much detail. > > I have no background to make any suggestion about this, but I like the level of detail used here to describe things, and I would be willing to accept even more detail where necessary to make the delineating/defining point. > > -- > Kim Watson > Office of Cybersecurity and Communications > Federal Network Resilience > Blackberry: (202) 494-2534 > > > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Tuesday, February 11, 2014 7:13 PM > To: Stephen Hanna; Gunnar Engelbach; Panos Kampanakis (pkampana); sacm@ietf.org > Subject: Re: [sacm] Types of content > > I'd like to get the discussion around this topic to a point where I have clear editorial direction on what text we want included in the updated use case draft for this Friday's submission cutoff deadline. > > Based on the mailing list discussions to date, I'd like to propose the following categories of security automation data for inclusion in the use cases draft: Guidance, Endpoint/Asset Attribute Data, and Processing Artifacts. > > The following sections roughly define each of the proposed categories. For each section some insights are provided into the how the data might be sourced and how often it may change. I have also included examples of the classes of information for each category with mappings to the use cases and building blocks they support to insure we have the necessary coverage. > > To move forward I need answers to the following questions: > > 1) Do you like these groupings? If not, is there a better set of groupings? > 2) Do you like the labels for each of the groups? If not, do you have a better label(s)? > 3) Are there other types of content that should be included? > 4) What level of detail should be included in the use cases draft regarding this discussion? What I have below is likely too much detail. > > Thanks, > Dave > > Guidance: > ------------ > The term "guidance" was proposed by Steve Hanna and was supported by Gunnar Engelbach on the list. Steve proposed that this concept encompasses "attribute identifiers, lists of attributes that are to be collected and when and perhaps how, and policies about what attribute values are acceptable for different kinds or groups of endpoints. This indicates that these things (and maybe others to be added later) guide the attribute collection and evaluation process." I would also add that this should include instructions supporting data-driven evaluation processes. > > This data tends to change in units of months and days. In cases where assessments are made more dynamic, it may be necessary to handle changes in the scope of hours or minutes. This data will typically be provided by large organizations, product vendors, and some 3rd-parties. Thus, it will tend to be shared across large enterprises and customer communities. In some cases access may be controlled to specific authenticated users. In other cases, the data may be provided broadly with little to no access control. > > This would include: > > - Applicability Statements: Data the identifies the conditional applicability of an assessment (and related assessment "guidance") based on automated collection of endpoint posture attribute values and other endpoint characterizations. > + Endpoint Identification and Assessment Planning BB: Identify Endpoint Targets - This supports the targeting concept allowing characterizations and collected posture attribute values to be evaluated to determine what set of endpoints should be assessed. > > - Collection Instructions: Data that drives the identification of the set of posture attributes needed to perform an assessment and the collection of posture attributes. > + Endpoint Identification and Assessment Planning BB: Posture Attribute Identification - Used to determine the set of posture attributes for which values must be collected (or retrieved) to support the evaluation. > + Endpoint Posture Attribute Value Collection BB: Collection Content Acquisition - Data is retrieved based on its relationship to the assessment and other applicability concepts to drive collection activities. > + Endpoint Posture Attribute Value Collection BB: Posture Attribute Value Collection - Directives on how the posture attributes should be collected. This may include: events to monitor, scheduling info, instructions for using specific models/protocols, etc. > > - Evaluation instructions: Data the identifies what endpoint posture attribute values are to be evaluated and how this evaluation should be performed. > + Endpoint Identification and Assessment Planning BB: Posture Attribute Identification - Use to determine the set of posture attributes for which values are required for evaluation. > + Posture Evaluation BB: Evaluation Content Acquisition - Data is retrieved based on its relationship to the assessment and other applicability concepts to drive evaluation activities. > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs the evaluation of collected endpoint posture attribute values. This will likely include comparison operators and logical constructs. Additional instructions might indicate the required result output format. > > Our information model will need to relate the concepts of applicability statements, collection instructions, and evaluation instructions in support of assessment activities. > > Endpoint/Asset Attribute Data: > -------------------------------------- > > This category includes contextual metadata pertaining to endpoints and the assets that they are composed of (e.g., hardware, software, accounts), and collected endpoint posture attributes, their associated values, and related context. > > This data tends to change in units of days, minutes, a seconds with posture attribute values typically changing more frequently than endpoint characterizations. This data tends to be organizationally and endpoint specific, with specific operational groups of endpoints tending to exhibit similar attribute profiles. This data will generally not be shared outside an organizational boundary and will generally require authentication with specific access controls. > > This would include: > > - Characterizations of endpoints: Endpoint metadata that describes the endpoint type, organizationally expected function/role, etc. > + Endpoint Identification and Assessment Planning BB: Endpoint Characterization - Gathered through automated posture attribute collection, manual data entry/query, and interactions with other data stores. > > - Collected Posture Attributes: Posture attributes and associated values collected from endpoints representing hardware, software inventory, configurations, accounts/privileges, and other aspects of endpoint state. > + Endpoint Identification and Assessment Planning BB: Endpoint Component Inventory - This provides context to identify what posture attributes should be collected as part of the assessment based on the current endpoint posture (e.g., what software is installed). > + Endpoint Posture Attribute Value Collection BB: Posture Attribute Value Collection - For each targeted endpoint, the set of collected posture attributes and associated values. The result of collection. > + Posture Evaluation BB: Posture Attribute Value Query - The retrieval of a set of previously collected posture attributes and associated values. This may not be required if collected data is fed directly to an evaluator after collection. > > An important dimension here may be the separation between actual and expected posture attribute values. It may be possible to express guidance in a way that allows expected values to parameterized. In this case it will be necessary to allow for organizationally expected values to be associated with defined guidance (perhaps provided by a different party). > > Our information model will need to relate the concepts of endpoint characterizations and collected posture information to the types of guidance data. > > Processing Artifacts: > ------------------------- > > This type of data is generated by and is specific to an individual assessment process. This data may be used as part of the interactions between SACM architectural components to drive and coordinate collection and evaluation activities. Its lifespan will be bounded by the lifespan of the assessment. It may also be exchanged and stored to provide historic context around an assessment activity. > > This would include: > > - Endpoint Targets: An identified set of endpoints for which an assessment should be performed. > + Endpoint Identification and Assessment Planning BB: Identify Endpoint Targets - The endpoints targeted for an assessment. > > - Identified Posture Attributes > + Endpoint Identification and Assessment Planning BB: Posture Attribute Identification - The required posture attributes that need to be collected to perform the evaluation. > > - Assessment Results: The resulting output generated by the evaluation process. > + Posture Evaluation BB: Posture Attribute Evaluation - The results produced through the comparison of actual collected posture attribute > values against their expected state. The specific output an evaluation criteria may be specified by the required evaluation instructions. > > Our information model will need to relate these concepts to those provided in the other two categories. I know this is not saying much, but I am tired and ready to end this email. ;-) > >> -----Original Message----- >> From: Stephen Hanna [mailto:shanna@juniper.net] >> Sent: Wednesday, February 05, 2014 10:48 PM >> To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis >> (pkampana); sacm@ietf.org >> Subject: RE: [sacm] Types of content >> >> Gunnar Engelbach wrote: >>> So "Guidance" is input and "collected attributes" is the immediate >>> product? >> >> Right. At least, that's one way of describing it. >> I'm thinking that guidance would include all the things that Dave was >> previously calling "content". >> >>> That works. And is line with common usage. >> >> Good! I'm glad to hear that it makes sense to you. >> >>> And for the final result of applying the collected attributes to the >>> guidance, how about "assessment results?" >> >> Yes, I like that also. >> >>> Is there a need for anything more granular? >> >> Probably eventually. But there also seems to be a need for broad terms >> since people want to be able to put all the "guidance" into one >> repository >> (perhaps) and have a different kind of repository for "collected attributes" >> and maybe also "assessment results". >> >>> Mention of other terms commonly used for the same thing? >> >> Maybe. Listing alternative terms in common usage today can be >> confusing since different people may use those terms differently. >> >> Thanks, >> >> Steve >> >>> >>> >>> What I frequently see: >>> >>> Input: >>> Guidance >>> Content >>> Checklist >>> Questionnaire >>> Data stream >>> Benchmark >>> Definitions >>> >>> >>> Product: >>> Collected Attributes >>> System Characteristics >>> Assessment Results >>> Posture >>> >>> >>> >>> >>> On 2/5/2014 9:13 PM, Stephen Hanna wrote: >>>> The terms "content" and "data" are just too general. "SA content" >>>> isn't much better. It seems to include any kind of data related to >>>> security automation. In the long run, that might include lots of >>>> things like vulnerability reports and alerts that an intrusion has >>>> been detected and remediation or mitigation instructions. >>>> Also reports on endpoint compliance and attributes that have been >>>> collected from endpoints and maybe persisted. It's just not useful >>>> to use one term for all those kinds of things. >>>> >>>> I think that we need a new, more specific term for the things that >>>> Dave described below: attribute identifiers, lists of attributes >>>> that are to be collected and when and perhaps how, and policies >>>> about what attribute values are acceptable for different kinds or >>>> groups of endpoints. I suggest that we use the collective term >>>> "guidance" for these things. This indicates that these things (and >>>> maybe others to be added >>>> later) guide the attribute collection and evaluation process. >>>> >>>> We also need to have a term for attribute values that have been >>>> collected from endpoints. I vote for "collected attributes". >>>> These attributes might be persisted (stored) or maybe not. >>>> Either way, they are attribute values that have been collected >>>> from endpoints. >>>> >>>> Thanks, >>>> >>>> Steve >>>> >>>>> -----Original Message----- >>>>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar >>> Engelbach >>>>> Sent: Wednesday, February 05, 2014 7:37 PM >>>>> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis >>> (pkampana); >>>>> sacm@ietf.org >>>>> Subject: Re: [sacm] Types of content >>>>> >>>>> >>>>> I would prefer to reserve the term "content" for the >>>>> instructional documentation. That is, the documents that cause >>>>> an action, be it legislation, prose guidance, or a set of machine >>>>> instructions that implement that guidance. >>>>> >>>>> We typically use "system characteristics" when referring to >>> collected >>>>> items, and variations on "endpoint attributes" has been used >>> frequently >>>>> on this list. System characteristics are the product of applying >>>>> content to an endpoint. >>>>> >>>>> Collectively it's all data. Is there a desire to have a general >>> term >>>>> for all data that could flow through a SACM implementation but is >>>>> specific to SACM? >>>>> >>>>> >>>>> Also, while I agree with the need to allow the ability to persist >>>>> collected data items (and the results of posture evaluations), I >>> don't >>>>> see that as a requirement. >>>>> >>>>> >>>>> >>>>> >>>>> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: >>>>>> Dictionaries of posture attributes was not intended to include >>>>> attribute >>>>>> values. IETF examples of this concept might include attributes >>>>>> in a >>>>> MIB >>>>>> or a NETMOD model. >>>>>> >>>>>> I agree that we need to "persist" posture attribute values. I >>>>>> have always been on the fence personally about calling >>>>>> collection and evaluation results "content". I agree 100% that >>>>>> we need to be >>> crystal >>>>>> clear about what we mean when we use the terms "content" and >>> "content >>>>>> repository". If we choose to lump all of this together as >>> "content", >>>>> we >>>>>> will need to include some discussion in the use case document >>>>>> contrasting different types of content to drive discussion of >>> content >>>>>> type-specific requirements. >>>>>> >>>>>> I also personally like Ira's feedback on using a more specific >>>>> term(s) >>>>>> instead of the more general "content". >>>>>> >>>>>> I also share the same personal view around interacting with >>>>>> stores >>> of >>>>>> collected posture attribute values and evaluation results. The >>> larger >>>>>> data volumes and rate of change will likely require different >>>>>> approaches. I also believe that the temporal nature of this >>>>>> data, >>> the >>>>>> need to persist historic information, will be more significant >>>>>> than other types of data that we may call "content". >>>>>> >>>>>> Are there other opinions on this? Does anyone feel strongly that >>>>>> collected posture attribute values and evaluation results SHOULD >>> NOT >>>>> be >>>>>> considered content? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Dave >>>>>> >>>>>> *From:*Stephen Hanna [mailto:shanna@juniper.net] >>>>>> *Sent:* Wednesday, February 05, 2014 6:10 PM >>>>>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; >>>>> sacm@ietf.org >>>>>> *Subject:* RE: Types of content >>>>>> >>>>>> Would "dictionaries of posture attributes" include attribute >>>>>> values >>>>> that >>>>>> have been collected from endpoints? >>>>>> >>>>>> We want to have the ability to collect attribute values from >>>>> endpoints >>>>>> and "persist" them, as described in section 2.1.3. So we'll need >>>>>> to >>>>> have >>>>>> a repository for collected and persisted attribute values. >>>>>> >>>>>> If collected endpoint attribute values are considered content, >>> let's >>>>> say >>>>>> so. If not, let's say that explicitly. >>>>>> >>>>>> My personal view is that collected endpoint attribute values >>>>>> should >>>>> be >>>>>> considered content. They may be a different kind of content from >>> the >>>>>> others due to larger volume and higher change rate. For that >>> reason, >>>>>> people may choose to put them into a different repository and >>>>>> maybe >>>>> even >>>>>> use a different query protocol for that repository to munge the >>> large >>>>>> quantities of data. But they're still content. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve >>>>>> >>>>>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos >>>>>> Kampanakis (pkampana) >>>>>> *Sent:* Wednesday, February 05, 2014 5:25 PM >>>>>> *To:* Waltermire, David A.; sacm@ietf.org >>>>>> *Subject:* Re: [sacm] Types of content >>>>>> >>>>>> Sounds like a good summary of what "content" could mean. >>>>>> >>>>>> Panos >>>>>> >>>>>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of >>> *Waltermire, >>>>>> David A. >>>>>> *Sent:* Wednesday, February 05, 2014 10:38 PM >>>>>> *To:* sacm@ietf.org >>>>>> *Subject:* [sacm] Types of content >>>>>> >>>>>> I'm working through the UC draft addressing discussion items >>>>>> from yesterday and the previous comments we have received on the >>>>>> list on >>> - >>>>> 05. >>>>>> >>>>>> Related to section 2.1.1, we have had many previous discussions >>>>> around >>>>>> the notional idea of content. There has been general agreement >>>>>> that >>>>> we >>>>>> need to be more specific. Please find below an attempt to put >>>>>> some "bounds" around different types of content. >>>>>> >>>>>> Is this hitting the mark, or do we need to say something >>>>> more/different? >>>>>> >>>>>> The following is a snippet from a possible update to section >>>>>> 2.1.1 >>>>> with >>>>>> some additional description: >>>>>> >>>>>> I'd appreciate any thoughts, concerns, objections before I >>>>>> include >>>>> the >>>>>> changes in the draft. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Dave >>>>>> >>>>>> 2.1.1. Define, Publish, Query and Retrieve Content >>>>>> >>>>>> This use case describes the need for content to be defined >>>>>> and >>>>>> >>>>>> published to a data store, as well as queried and retrieved >>> from >>>>> the >>>>>> >>>>>> data store for the explicit use of posture collection and >>>>> evaluation. >>>>>> >>>>>> The term "content" is a general concept that refers to any >>> data >>>>>> >>>>>> expression that may be used as part of the process of >>> collecting >>>>> and >>>>>> >>>>>> evaluating endpoint posture. Typical types of content >>> include: >>>>>> >>>>>> o Dictionaries of posture attributes (e.g. software >>>>> installation, >>>>>> >>>>>> configuration, privileges) that may be collected from a >>> given >>>>>> >>>>>> endpoint type that relate to installed hardware, >>>>>> installed >>>>>> >>>>>> software, software configurations, accounts, privileges, >>> and >>>>> other >>>>>> >>>>>> operational state. >>>>>> >>>>>> o Expressions that provide instructions for using a >>>>>> specific >>>>> API, >>>>>> >>>>>> management protocol, or other mechanisms to collect >>> specific >>>>>> >>>>>> posture attributes from specific device types. >>>>>> >>>>>> o Policies that define the selected posture attributes for >>> which >>>>>> >>>>>> values must be collected to support one or more posture >>>>>> >>>>>> assessments. This may include information that targets >>>>> collection >>>>>> >>>>>> to a specific set of endpoints and instructions on the >>>>> frequency >>>>>> >>>>>> and/or change events (e.g., configuration changes, >>>>>> software >>>>>> >>>>>> installation/uninstallation, account/privilege >>> modifications) >>>>> that >>>>>> >>>>>> will trigger collection of one or more posture attributes. >>>>>> >>>>>> o Policies that define the logical criteria to evaluate >>>>> collected >>>>>> >>>>>> posture attribute values to determine if they meet >>>>> organizational >>>>>> >>>>>> requirements. This may include information that targets >>>>>> >>>>>> evaluation to a specific set of endpoints. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>> >>>> >>> >> > > > From ietfdbh@comcast.net Wed Feb 12 21:24:28 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57661A0107 for ; Wed, 12 Feb 2014 21:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxm-SA4rLpuO for ; Wed, 12 Feb 2014 21:24:23 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 15EA01A00F5 for ; Wed, 12 Feb 2014 21:24:22 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id RhJl1n0021swQuc5ChQMN2; Thu, 13 Feb 2014 05:24:21 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id RhQL1n00j2yZEBF3bhQMqS; Thu, 13 Feb 2014 05:24:21 +0000 From: "ietfdbh" To: "'Waltermire, David A.'" , "'Stephen Hanna'" , "'Gunnar Engelbach'" , "'Panos Kampanakis \(pkampana\)'" , References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Date: Thu, 13 Feb 2014 00:24:19 -0500 Message-ID: <016e01cf287b$d8ab30e0$8a0192a0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNuuUHmYgO7EmgtI0dW46iXjEXXQJ2D50FAeTwTYACEcwlmgE+SePfAtyMz64BqJ2SNAIJMTe1AXofYDWZNgQH0A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392269061; bh=yuA8OmsX/zlDgdQl5FefCQRiS+rLXAhHtXZ+2Wq87PM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rjfpf8EgstvQdQ1sVMGZFuWws+8jPbAZuUh8Y5pbrGQwUOjE6e1vU9sDk+I21Xg32 zL70+MAwpZneDs25XbbYA/Bohvta8CJkIfpDH3WkzOeSN17zKVvk4/MkwhmyOzn3p7 lafm2deZxXzvg38qwQ0KkXysiBh/x7OzNxu4o3zmnGg6cImwL0nM0FFnSBgbc43g4F QUK6AFa4JEtt8Vnd36Ib/xOw6qdMBRt6NPjrTve5hrKAmIi0p27yG22aAZK0O3bT14 a/dwkNfNs8zckksxiiMU16/DAGt47+/1qiZHAJTMfQ/QfEoXPAgNURPURDd0riF7Ab Xj+MVWAjSOY+g== Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 05:24:28 -0000 Hi, I am concerned about lumping both characterization/metadata and attribute values together. In my view of the world, the metadata/characterization is determined during discovery and then doesn't change much unless the endpoint is physically modified. The attribute values, however, would include operational state, which can be short lived and changes dynamically. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David > A. > Sent: Tuesday, February 11, 2014 7:13 PM > To: Stephen Hanna; Gunnar Engelbach; Panos Kampanakis (pkampana); > sacm@ietf.org > Subject: Re: [sacm] Types of content > > I'd like to get the discussion around this topic to a point where I have clear > editorial direction on what text we want included in the updated use case > draft for this Friday's submission cutoff deadline. > > Based on the mailing list discussions to date, I'd like to propose the following > categories of security automation data for inclusion in the use cases draft: > Guidance, Endpoint/Asset Attribute Data, and Processing Artifacts. > > The following sections roughly define each of the proposed categories. For > each section some insights are provided into the how the data might be > sourced and how often it may change. I have also included examples of the > classes of information for each category with mappings to the use cases and > building blocks they support to insure we have the necessary coverage. > > To move forward I need answers to the following questions: > > 1) Do you like these groupings? If not, is there a better set of groupings? > 2) Do you like the labels for each of the groups? If not, do you have a better > label(s)? > 3) Are there other types of content that should be included? > 4) What level of detail should be included in the use cases draft regarding this > discussion? What I have below is likely too much detail. > > Thanks, > Dave > > Guidance: > ------------ > The term "guidance" was proposed by Steve Hanna and was supported by > Gunnar Engelbach on the list. Steve proposed that this concept encompasses > "attribute identifiers, lists of attributes that are to be collected and when and > perhaps how, and policies about what attribute values are acceptable for > different kinds or groups of endpoints. This indicates that these things (and > maybe others to be added later) guide the attribute collection and evaluation > process." I would also add that this should include instructions supporting > data-driven evaluation processes. > > This data tends to change in units of months and days. In cases where > assessments are made more dynamic, it may be necessary to handle changes > in the scope of hours or minutes. This data will typically be provided by large > organizations, product vendors, and some 3rd-parties. Thus, it will tend to be > shared across large enterprises and customer communities. In some cases > access may be controlled to specific authenticated users. In other cases, the > data may be provided broadly with little to no access control. > > This would include: > > - Applicability Statements: Data the identifies the conditional applicability of > an assessment (and related assessment "guidance") based on automated > collection of endpoint posture attribute values and other endpoint > characterizations. > + Endpoint Identification and Assessment Planning BB: Identify Endpoint > Targets - This supports the targeting concept allowing characterizations and > collected posture attribute values to be evaluated to determine what set of > endpoints should be assessed. > > - Collection Instructions: Data that drives the identification of the set of > posture attributes needed to perform an assessment and the collection of > posture attributes. > + Endpoint Identification and Assessment Planning BB: Posture Attribute > Identification - Used to determine the set of posture attributes for which > values must be collected (or retrieved) to support the evaluation. > + Endpoint Posture Attribute Value Collection BB: Collection Content > Acquisition - Data is retrieved based on its relationship to the assessment and > other applicability concepts to drive collection activities. > + Endpoint Posture Attribute Value Collection BB: Posture Attribute Value > Collection - Directives on how the posture attributes should be collected. This > may include: events to monitor, scheduling info, instructions for using > specific models/protocols, etc. > > - Evaluation instructions: Data the identifies what endpoint posture attribute > values are to be evaluated and how this evaluation should be performed. > + Endpoint Identification and Assessment Planning BB: Posture Attribute > Identification - Use to determine the set of posture attributes for which > values are required for evaluation. > + Posture Evaluation BB: Evaluation Content Acquisition - Data is retrieved > based on its relationship to the assessment and other applicability concepts > to drive evaluation activities. > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs the > evaluation of collected endpoint posture attribute values. This will likely > include comparison operators and logical constructs. Additional instructions > might indicate the required result output format. > > Our information model will need to relate the concepts of applicability > statements, collection instructions, and evaluation instructions in support of > assessment activities. > > Endpoint/Asset Attribute Data: > -------------------------------------- > > This category includes contextual metadata pertaining to endpoints and the > assets that they are composed of (e.g., hardware, software, accounts), and > collected endpoint posture attributes, their associated values, and related > context. > > This data tends to change in units of days, minutes, a seconds with posture > attribute values typically changing more frequently than endpoint > characterizations. This data tends to be organizationally and endpoint > specific, with specific operational groups of endpoints tending to exhibit > similar attribute profiles. This data will generally not be shared outside an > organizational boundary and will generally require authentication with > specific access controls. > > This would include: > > - Characterizations of endpoints: Endpoint metadata that describes the > endpoint type, organizationally expected function/role, etc. > + Endpoint Identification and Assessment Planning BB: Endpoint > Characterization - Gathered through automated posture attribute collection, > manual data entry/query, and interactions with other data stores. > > - Collected Posture Attributes: Posture attributes and associated values > collected from endpoints representing hardware, software inventory, > configurations, accounts/privileges, and other aspects of endpoint state. > + Endpoint Identification and Assessment Planning BB: Endpoint > Component Inventory - This provides context to identify what posture > attributes should be collected as part of the assessment based on the > current endpoint posture (e.g., what software is installed). > + Endpoint Posture Attribute Value Collection BB: Posture Attribute Value > Collection - For each targeted endpoint, the set of collected posture > attributes and associated values. The result of collection. > + Posture Evaluation BB: Posture Attribute Value Query - The retrieval of a > set of previously collected posture attributes and associated values. This may > not be required if collected data is fed directly to an evaluator after > collection. > > An important dimension here may be the separation between actual and > expected posture attribute values. It may be possible to express guidance in > a way that allows expected values to parameterized. In this case it will be > necessary to allow for organizationally expected values to be associated with > defined guidance (perhaps provided by a different party). > > Our information model will need to relate the concepts of endpoint > characterizations and collected posture information to the types of guidance > data. > > Processing Artifacts: > ------------------------- > > This type of data is generated by and is specific to an individual assessment > process. This data may be used as part of the interactions between SACM > architectural components to drive and coordinate collection and evaluation > activities. Its lifespan will be bounded by the lifespan of the assessment. It > may also be exchanged and stored to provide historic context around an > assessment activity. > > This would include: > > - Endpoint Targets: An identified set of endpoints for which an assessment > should be performed. > + Endpoint Identification and Assessment Planning BB: Identify Endpoint > Targets - The endpoints targeted for an assessment. > > - Identified Posture Attributes > + Endpoint Identification and Assessment Planning BB: Posture Attribute > Identification - The required posture attributes that need to be collected to > perform the evaluation. > > - Assessment Results: The resulting output generated by the evaluation > process. > + Posture Evaluation BB: Posture Attribute Evaluation - The results > produced through the comparison of actual collected posture attribute > values against their expected state. The specific output an evaluation > criteria may be specified by the required evaluation instructions. > > Our information model will need to relate these concepts to those provided > in the other two categories. I know this is not saying much, but I am tired and > ready to end this email. ;-) > > > -----Original Message----- > > From: Stephen Hanna [mailto:shanna@juniper.net] > > Sent: Wednesday, February 05, 2014 10:48 PM > > To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis > (pkampana); > > sacm@ietf.org > > Subject: RE: [sacm] Types of content > > > > Gunnar Engelbach wrote: > > > So "Guidance" is input and "collected attributes" is the immediate > > > product? > > > > Right. At least, that's one way of describing it. > > I'm thinking that guidance would include all the things that Dave was > > previously calling "content". > > > > > That works. And is line with common usage. > > > > Good! I'm glad to hear that it makes sense to you. > > > > > And for the final result of applying the collected attributes to the > > > guidance, how about "assessment results?" > > > > Yes, I like that also. > > > > > Is there a need for anything more granular? > > > > Probably eventually. But there also seems to be a need for broad terms > since > > people want to be able to put all the "guidance" into one repository > > (perhaps) and have a different kind of repository for "collected attributes" > > and maybe also "assessment results". > > > > > Mention of other terms commonly used for the same thing? > > > > Maybe. Listing alternative terms in common usage today can be confusing > > since different people may use those terms differently. > > > > Thanks, > > > > Steve > > > > > > > > > > > What I frequently see: > > > > > > Input: > > > Guidance > > > Content > > > Checklist > > > Questionnaire > > > Data stream > > > Benchmark > > > Definitions > > > > > > > > > Product: > > > Collected Attributes > > > System Characteristics > > > Assessment Results > > > Posture > > > > > > > > > > > > > > > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > > > > The terms "content" and "data" are just too general. "SA content" > > > > isn't much better. It seems to include any kind of data related to > > > > security automation. In the long run, that might include lots of > > > > things like vulnerability reports and alerts that an intrusion has > > > > been detected and remediation or mitigation instructions. > > > > Also reports on endpoint compliance and attributes that have been > > > > collected from endpoints and maybe persisted. It's just not useful > > > > to use one term for all those kinds of things. > > > > > > > > I think that we need a new, more specific term for the things that > > > > Dave described below: attribute identifiers, lists of attributes > > > > that are to be collected and when and perhaps how, and policies > > > > about what attribute values are acceptable for different kinds or > > > > groups of endpoints. I suggest that we use the collective term > > > > "guidance" for these things. This indicates that these things (and > > > > maybe others to be added > > > > later) guide the attribute collection and evaluation process. > > > > > > > > We also need to have a term for attribute values that have been > > > > collected from endpoints. I vote for "collected attributes". > > > > These attributes might be persisted (stored) or maybe not. > > > > Either way, they are attribute values that have been collected from > > > > endpoints. > > > > > > > > Thanks, > > > > > > > > Steve > > > > > > > >> -----Original Message----- > > > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > > > Engelbach > > > >> Sent: Wednesday, February 05, 2014 7:37 PM > > > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > > > (pkampana); > > > >> sacm@ietf.org > > > >> Subject: Re: [sacm] Types of content > > > >> > > > >> > > > >> I would prefer to reserve the term "content" for the instructional > > > >> documentation. That is, the documents that cause an action, be it > > > >> legislation, prose guidance, or a set of machine instructions that > > > >> implement that guidance. > > > >> > > > >> We typically use "system characteristics" when referring to > > > collected > > > >> items, and variations on "endpoint attributes" has been used > > > frequently > > > >> on this list. System characteristics are the product of applying > > > >> content to an endpoint. > > > >> > > > >> Collectively it's all data. Is there a desire to have a general > > > term > > > >> for all data that could flow through a SACM implementation but is > > > >> specific to SACM? > > > >> > > > >> > > > >> Also, while I agree with the need to allow the ability to persist > > > >> collected data items (and the results of posture evaluations), I > > > don't > > > >> see that as a requirement. > > > >> > > > >> > > > >> > > > >> > > > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > > > >>> Dictionaries of posture attributes was not intended to include > > > >> attribute > > > >>> values. IETF examples of this concept might include attributes in > > > >>> a > > > >> MIB > > > >>> or a NETMOD model. > > > >>> > > > >>> I agree that we need to "persist" posture attribute values. I have > > > >>> always been on the fence personally about calling collection and > > > >>> evaluation results "content". I agree 100% that we need to be > > > crystal > > > >>> clear about what we mean when we use the terms "content" and > > > "content > > > >>> repository". If we choose to lump all of this together as > > > "content", > > > >> we > > > >>> will need to include some discussion in the use case document > > > >>> contrasting different types of content to drive discussion of > > > content > > > >>> type-specific requirements. > > > >>> > > > >>> I also personally like Ira's feedback on using a more specific > > > >> term(s) > > > >>> instead of the more general "content". > > > >>> > > > >>> I also share the same personal view around interacting with stores > > > of > > > >>> collected posture attribute values and evaluation results. The > > > larger > > > >>> data volumes and rate of change will likely require different > > > >>> approaches. I also believe that the temporal nature of this data, > > > the > > > >>> need to persist historic information, will be more significant > > > >>> than other types of data that we may call "content". > > > >>> > > > >>> Are there other opinions on this? Does anyone feel strongly that > > > >>> collected posture attribute values and evaluation results SHOULD > > > NOT > > > >> be > > > >>> considered content? > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Dave > > > >>> > > > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > > > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > > > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > > > >> sacm@ietf.org > > > >>> *Subject:* RE: Types of content > > > >>> > > > >>> Would "dictionaries of posture attributes" include attribute > > > >>> values > > > >> that > > > >>> have been collected from endpoints? > > > >>> > > > >>> We want to have the ability to collect attribute values from > > > >> endpoints > > > >>> and "persist" them, as described in section 2.1.3. So we'll need > > > >>> to > > > >> have > > > >>> a repository for collected and persisted attribute values. > > > >>> > > > >>> If collected endpoint attribute values are considered content, > > > let's > > > >> say > > > >>> so. If not, let's say that explicitly. > > > >>> > > > >>> My personal view is that collected endpoint attribute values > > > >>> should > > > >> be > > > >>> considered content. They may be a different kind of content from > > > the > > > >>> others due to larger volume and higher change rate. For that > > > reason, > > > >>> people may choose to put them into a different repository and > > > >>> maybe > > > >> even > > > >>> use a different query protocol for that repository to munge the > > > large > > > >>> quantities of data. But they're still content. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Steve > > > >>> > > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > > > >>> Kampanakis (pkampana) > > > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > > > >>> *To:* Waltermire, David A.; sacm@ietf.org > > > >>> *Subject:* Re: [sacm] Types of content > > > >>> > > > >>> Sounds like a good summary of what "content" could mean. > > > >>> > > > >>> Panos > > > >>> > > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > > > *Waltermire, > > > >>> David A. > > > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > > > >>> *To:* sacm@ietf.org > > > >>> *Subject:* [sacm] Types of content > > > >>> > > > >>> I'm working through the UC draft addressing discussion items from > > > >>> yesterday and the previous comments we have received on the list > > > >>> on > > > - > > > >> 05. > > > >>> > > > >>> Related to section 2.1.1, we have had many previous discussions > > > >> around > > > >>> the notional idea of content. There has been general agreement > > > >>> that > > > >> we > > > >>> need to be more specific. Please find below an attempt to put some > > > >>> "bounds" around different types of content. > > > >>> > > > >>> Is this hitting the mark, or do we need to say something > > > >> more/different? > > > >>> > > > >>> The following is a snippet from a possible update to section 2.1.1 > > > >> with > > > >>> some additional description: > > > >>> > > > >>> I'd appreciate any thoughts, concerns, objections before I include > > > >> the > > > >>> changes in the draft. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Dave > > > >>> > > > >>> 2.1.1. Define, Publish, Query and Retrieve Content > > > >>> > > > >>> This use case describes the need for content to be defined > > > >>> and > > > >>> > > > >>> published to a data store, as well as queried and retrieved > > > from > > > >> the > > > >>> > > > >>> data store for the explicit use of posture collection and > > > >> evaluation. > > > >>> > > > >>> The term "content" is a general concept that refers to any > > > data > > > >>> > > > >>> expression that may be used as part of the process of > > > collecting > > > >> and > > > >>> > > > >>> evaluating endpoint posture. Typical types of content > > > include: > > > >>> > > > >>> o Dictionaries of posture attributes (e.g. software > > > >> installation, > > > >>> > > > >>> configuration, privileges) that may be collected from a > > > given > > > >>> > > > >>> endpoint type that relate to installed hardware, installed > > > >>> > > > >>> software, software configurations, accounts, privileges, > > > and > > > >> other > > > >>> > > > >>> operational state. > > > >>> > > > >>> o Expressions that provide instructions for using a specific > > > >> API, > > > >>> > > > >>> management protocol, or other mechanisms to collect > > > specific > > > >>> > > > >>> posture attributes from specific device types. > > > >>> > > > >>> o Policies that define the selected posture attributes for > > > which > > > >>> > > > >>> values must be collected to support one or more posture > > > >>> > > > >>> assessments. This may include information that targets > > > >> collection > > > >>> > > > >>> to a specific set of endpoints and instructions on the > > > >> frequency > > > >>> > > > >>> and/or change events (e.g., configuration changes, > > > >>> software > > > >>> > > > >>> installation/uninstallation, account/privilege > > > modifications) > > > >> that > > > >>> > > > >>> will trigger collection of one or more posture attributes. > > > >>> > > > >>> o Policies that define the logical criteria to evaluate > > > >> collected > > > >>> > > > >>> posture attribute values to determine if they meet > > > >> organizational > > > >>> > > > >>> requirements. This may include information that targets > > > >>> > > > >>> evaluation to a specific set of endpoints. > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> sacm mailing list > > > >>> sacm@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/sacm > > > >>> > > > >> _______________________________________________ > > > >> sacm mailing list > > > >> sacm@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sacm > > > >> > > > > > > > > > > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Thu Feb 13 05:57:19 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB031A0259 for ; Thu, 13 Feb 2014 05:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9tg4jYOtHk2 for ; Thu, 13 Feb 2014 05:57:15 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2541A025D for ; Thu, 13 Feb 2014 05:57:12 -0800 (PST) Received: from mail125-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 13:57:11 +0000 Received: from mail125-tx2 (localhost [127.0.0.1]) by mail125-tx2-R.bigfish.com (Postfix) with ESMTP id 5700C400170; Thu, 13 Feb 2014 13:57:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I148cI542I1432I1418I4015I11fbI168aJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail125-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(979002)(6009001)(57704003)(164054003)(51444003)(24454002)(13464003)(199002)(189002)(51704005)(46034005)(52604005)(377454003)(479174003)(85306002)(65816001)(95416001)(19580395003)(79102001)(80976001)(19580405001)(56776001)(54316002)(59766001)(77982001)(54356001)(53806001)(51856001)(80022001)(66066001)(76482001)(63696002)(46102001)(94316002)(47446002)(83322001)(86362001)(74662001)(93516002)(74502001)(31966008)(33646001)(47736001)(94946001)(47976001)(50986001)(15975445006)(81816001)(81686001)(49866001)(93136001)(83072002)(69226001)(92566001)(74366001)(90146001)(74316001)(74876001)(2656002)(87266001)(81342001)(87936001)(81542001)(74706001)(4396001)(95666001)(56816005)(85852003)(76786001)(76576001)(76796001)(24736002)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB739; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.10; FPR:EE7CF115.ABF2A142.B8D3F16B.82E4C941.208B2; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2 (MessageSwitch) id 1392299827689516_31892; Thu, 13 Feb 2014 13:57:07 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.230]) by mail125-tx2.bigfish.com (Postfix) with ESMTP id 9941E4E0049; Thu, 13 Feb 2014 13:57:07 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 13:57:05 +0000 Received: from BLUPR05MB739.namprd05.prod.outlook.com (10.141.208.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 13:57:04 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB739.namprd05.prod.outlook.com (10.141.208.24) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 13:57:02 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 13:57:02 +0000 From: Stephen Hanna To: "Waltermire, David A." , Gunnar Engelbach , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVAAAzOpAAAARPnQARgzlgAAXNxL0A== Date: Thu, 13 Feb 2014 13:57:01 +0000 Message-ID: <8ce976b1d5334d48bcecda35fa222fa6@BLUPR05MB737.namprd05.prod.outlook.com> References: <69135153be4642ad825a32c45fa3b439@BLUPR09MB038.namprd09.prod.outlook.com> <1C9F17D1873AFA47A969C4DD98F98A750FAC73D9@xmb-rcd-x10.cisco.com> <656401fabeb54cb1a205e9712bbe55f3@BLUPR05MB737.namprd05.prod.outlook.com> <52F2D93A.5020308@ThreatGuard.com> <2dd85bb0eb85413fb67b67942882a601@BLUPR05MB737.namprd05.prod.outlook.com> <52F302BC.30501@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.10] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:57:19 -0000 Sorry for being late in responding. Very busy this week! Still, I want to answer Dave's questions briefly: > 1) Do you like these groupings? I'm pleased with these groupings. Very good! > 2) Do you like the labels for each of the groups? The labels are fine. I'm not delighted with all of them but I don't have any better suggestions. Let's go with them. They are the right concepts. If someone comes up with a better label later, we can switch to it. > 3) Are there other types of content that should be included? No new groupings. As we've seen in the last few days, there will probably be more bits of information that will need to be added to the groupings. More kinds of info will probably be thought of as time goes on, extending out for years or even decades. Let's not make the system so rigid that it can't accommodate new types of content being added, both proprietary or (preferably) using a standard format. > 4) What level of detail should be included in the > use cases draft regarding this discussion? > What I have below is likely too much detail. Clearly, opinions differ on this topic. I believe that for the Use Cases document, this is too much detail. In that document, you just need to lay out what the categories are and give some salient examples of content that will be in each category. Other documents can list and describe the content in more detail. I'd say that a good guideline would be that if you need to mention a kind of content in the use cases, it should be mentioned in the list earlier in the document. If some content isn't mentioned in the rest of the document, it can be omitted. Thanks for figuring this out, Steve > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Tuesday, February 11, 2014 7:13 PM > To: Stephen Hanna; Gunnar Engelbach; Panos Kampanakis (pkampana); > sacm@ietf.org > Subject: RE: [sacm] Types of content >=20 > I'd like to get the discussion around this topic to a point where I > have clear editorial direction on what text we want included in the > updated use case draft for this Friday's submission cutoff deadline. >=20 > Based on the mailing list discussions to date, I'd like to propose the > following categories of security automation data for inclusion in the > use cases draft: Guidance, Endpoint/Asset Attribute Data, and > Processing Artifacts. >=20 > The following sections roughly define each of the proposed categories. > For each section some insights are provided into the how the data might > be sourced and how often it may change. I have also included examples > of the classes of information for each category with mappings to the > use cases and building blocks they support to insure we have the > necessary coverage. >=20 > To move forward I need answers to the following questions: >=20 > 1) Do you like these groupings? If not, is there a better set of > groupings? > 2) Do you like the labels for each of the groups? If not, do you have a > better label(s)? > 3) Are there other types of content that should be included? > 4) What level of detail should be included in the use cases draft > regarding this discussion? What I have below is likely too much detail. >=20 > Thanks, > Dave >=20 > Guidance: > ------------ > The term "guidance" was proposed by Steve Hanna and was supported by > Gunnar Engelbach on the list. Steve proposed that this concept > encompasses "attribute identifiers, lists of attributes that are to be > collected and when and perhaps how, and policies about what attribute > values are acceptable for different kinds or groups of endpoints. This > indicates that these things (and maybe others to be added later) guide > the attribute collection and evaluation process." I would also add that > this should include instructions supporting data-driven evaluation > processes. >=20 > This data tends to change in units of months and days. In cases where > assessments are made more dynamic, it may be necessary to handle > changes in the scope of hours or minutes. This data will typically be > provided by large organizations, product vendors, and some 3rd-parties. > Thus, it will tend to be shared across large enterprises and customer > communities. In some cases access may be controlled to specific > authenticated users. In other cases, the data may be provided broadly > with little to no access control. >=20 > This would include: >=20 > - Applicability Statements: Data the identifies the conditional > applicability of an assessment (and related assessment "guidance") > based on automated collection of endpoint posture attribute values and > other endpoint characterizations. > + Endpoint Identification and Assessment Planning BB: Identify > Endpoint Targets - This supports the targeting concept allowing > characterizations and collected posture attribute values to be > evaluated to determine what set of endpoints should be assessed. >=20 > - Collection Instructions: Data that drives the identification of the > set of posture attributes needed to perform an assessment and the > collection of posture attributes. > + Endpoint Identification and Assessment Planning BB: Posture > Attribute Identification - Used to determine the set of posture > attributes for which values must be collected (or retrieved) to support > the evaluation. > + Endpoint Posture Attribute Value Collection BB: Collection > Content Acquisition - Data is retrieved based on its relationship to > the assessment and other applicability concepts to drive collection > activities. > + Endpoint Posture Attribute Value Collection BB: Posture Attribute > Value Collection - Directives on how the posture attributes should be > collected. This may include: events to monitor, scheduling info, > instructions for using specific models/protocols, etc. >=20 > - Evaluation instructions: Data the identifies what endpoint posture > attribute values are to be evaluated and how this evaluation should be > performed. > + Endpoint Identification and Assessment Planning BB: Posture > Attribute Identification - Use to determine the set of posture > attributes for which values are required for evaluation. > + Posture Evaluation BB: Evaluation Content Acquisition - Data is > retrieved based on its relationship to the assessment and other > applicability concepts to drive evaluation activities. > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs > the evaluation of collected endpoint posture attribute values. This > will likely include comparison operators and logical constructs. > Additional instructions might indicate the required result output > format. >=20 > Our information model will need to relate the concepts of applicability > statements, collection instructions, and evaluation instructions in > support of assessment activities. >=20 > Endpoint/Asset Attribute Data: > -------------------------------------- >=20 > This category includes contextual metadata pertaining to endpoints and > the assets that they are composed of (e.g., hardware, software, > accounts), and collected endpoint posture attributes, their associated > values, and related context. >=20 > This data tends to change in units of days, minutes, a seconds with > posture attribute values typically changing more frequently than > endpoint characterizations. This data tends to be organizationally and > endpoint specific, with specific operational groups of endpoints > tending to exhibit similar attribute profiles. This data will generally > not be shared outside an organizational boundary and will generally > require authentication with specific access controls. >=20 > This would include: >=20 > - Characterizations of endpoints: Endpoint metadata that describes the > endpoint type, organizationally expected function/role, etc. > + Endpoint Identification and Assessment Planning BB: Endpoint > Characterization - Gathered through automated posture attribute > collection, manual data entry/query, and interactions with other data > stores. >=20 > - Collected Posture Attributes: Posture attributes and associated > values collected from endpoints representing hardware, software > inventory, configurations, accounts/privileges, and other aspects of > endpoint state. > + Endpoint Identification and Assessment Planning BB: Endpoint > Component Inventory - This provides context to identify what posture > attributes should be collected as part of the assessment based on the > current endpoint posture (e.g., what software is installed). > + Endpoint Posture Attribute Value Collection BB: Posture Attribute > Value Collection - For each targeted endpoint, the set of collected > posture attributes and associated values. The result of collection. > + Posture Evaluation BB: Posture Attribute Value Query - The > retrieval of a set of previously collected posture attributes and > associated values. This may not be required if collected data is fed > directly to an evaluator after collection. >=20 > An important dimension here may be the separation between actual and > expected posture attribute values. It may be possible to express > guidance in a way that allows expected values to parameterized. In this > case it will be necessary to allow for organizationally expected values > to be associated with defined guidance (perhaps provided by a different > party). >=20 > Our information model will need to relate the concepts of endpoint > characterizations and collected posture information to the types of > guidance data. >=20 > Processing Artifacts: > ------------------------- >=20 > This type of data is generated by and is specific to an individual > assessment process. This data may be used as part of the interactions > between SACM architectural components to drive and coordinate > collection and evaluation activities. Its lifespan will be bounded by > the lifespan of the assessment. It may also be exchanged and stored to > provide historic context around an assessment activity. >=20 > This would include: >=20 > - Endpoint Targets: An identified set of endpoints for which an > assessment should be performed. > + Endpoint Identification and Assessment Planning BB: Identify > Endpoint Targets - The endpoints targeted for an assessment. >=20 > - Identified Posture Attributes > + Endpoint Identification and Assessment Planning BB: Posture > Attribute Identification - The required posture attributes that need to > be collected to perform the evaluation. >=20 > - Assessment Results: The resulting output generated by the evaluation > process. > + Posture Evaluation BB: Posture Attribute Evaluation - The results > produced through the comparison of actual collected posture attribute > values against their expected state. The specific output an > evaluation criteria may be specified by the required evaluation > instructions. >=20 > Our information model will need to relate these concepts to those > provided in the other two categories. I know this is not saying much, > but I am tired and ready to end this email. ;-) >=20 > > -----Original Message----- > > From: Stephen Hanna [mailto:shanna@juniper.net] > > Sent: Wednesday, February 05, 2014 10:48 PM > > To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis > (pkampana); > > sacm@ietf.org > > Subject: RE: [sacm] Types of content > > > > Gunnar Engelbach wrote: > > > So "Guidance" is input and "collected attributes" is the immediate > > > product? > > > > Right. At least, that's one way of describing it. > > I'm thinking that guidance would include all the things that Dave was > > previously calling "content". > > > > > That works. And is line with common usage. > > > > Good! I'm glad to hear that it makes sense to you. > > > > > And for the final result of applying the collected attributes to > the > > > guidance, how about "assessment results?" > > > > Yes, I like that also. > > > > > Is there a need for anything more granular? > > > > Probably eventually. But there also seems to be a need for broad > terms since > > people want to be able to put all the "guidance" into one repository > > (perhaps) and have a different kind of repository for "collected > attributes" > > and maybe also "assessment results". > > > > > Mention of other terms commonly used for the same thing? > > > > Maybe. Listing alternative terms in common usage today can be > confusing > > since different people may use those terms differently. > > > > Thanks, > > > > Steve > > > > > > > > > > > What I frequently see: > > > > > > Input: > > > Guidance > > > Content > > > Checklist > > > Questionnaire > > > Data stream > > > Benchmark > > > Definitions > > > > > > > > > Product: > > > Collected Attributes > > > System Characteristics > > > Assessment Results > > > Posture > > > > > > > > > > > > > > > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > > > > The terms "content" and "data" are just too general. "SA content" > > > > isn't much better. It seems to include any kind of data related > to > > > > security automation. In the long run, that might include lots of > > > > things like vulnerability reports and alerts that an intrusion > has > > > > been detected and remediation or mitigation instructions. > > > > Also reports on endpoint compliance and attributes that have been > > > > collected from endpoints and maybe persisted. It's just not > useful > > > > to use one term for all those kinds of things. > > > > > > > > I think that we need a new, more specific term for the things > that > > > > Dave described below: attribute identifiers, lists of attributes > > > > that are to be collected and when and perhaps how, and policies > > > > about what attribute values are acceptable for different kinds or > > > > groups of endpoints. I suggest that we use the collective term > > > > "guidance" for these things. This indicates that these things > (and > > > > maybe others to be added > > > > later) guide the attribute collection and evaluation process. > > > > > > > > We also need to have a term for attribute values that have been > > > > collected from endpoints. I vote for "collected attributes". > > > > These attributes might be persisted (stored) or maybe not. > > > > Either way, they are attribute values that have been collected > from > > > > endpoints. > > > > > > > > Thanks, > > > > > > > > Steve > > > > > > > >> -----Original Message----- > > > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > > > Engelbach > > > >> Sent: Wednesday, February 05, 2014 7:37 PM > > > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > > > (pkampana); > > > >> sacm@ietf.org > > > >> Subject: Re: [sacm] Types of content > > > >> > > > >> > > > >> I would prefer to reserve the term "content" for the > instructional > > > >> documentation. That is, the documents that cause an action, be > it > > > >> legislation, prose guidance, or a set of machine instructions > that > > > >> implement that guidance. > > > >> > > > >> We typically use "system characteristics" when referring to > > > collected > > > >> items, and variations on "endpoint attributes" has been used > > > frequently > > > >> on this list. System characteristics are the product of > applying > > > >> content to an endpoint. > > > >> > > > >> Collectively it's all data. Is there a desire to have a general > > > term > > > >> for all data that could flow through a SACM implementation but > is > > > >> specific to SACM? > > > >> > > > >> > > > >> Also, while I agree with the need to allow the ability to > persist > > > >> collected data items (and the results of posture evaluations), I > > > don't > > > >> see that as a requirement. > > > >> > > > >> > > > >> > > > >> > > > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > > > >>> Dictionaries of posture attributes was not intended to include > > > >> attribute > > > >>> values. IETF examples of this concept might include attributes > in > > > >>> a > > > >> MIB > > > >>> or a NETMOD model. > > > >>> > > > >>> I agree that we need to "persist" posture attribute values. I > have > > > >>> always been on the fence personally about calling collection > and > > > >>> evaluation results "content". I agree 100% that we need to be > > > crystal > > > >>> clear about what we mean when we use the terms "content" and > > > "content > > > >>> repository". If we choose to lump all of this together as > > > "content", > > > >> we > > > >>> will need to include some discussion in the use case document > > > >>> contrasting different types of content to drive discussion of > > > content > > > >>> type-specific requirements. > > > >>> > > > >>> I also personally like Ira's feedback on using a more specific > > > >> term(s) > > > >>> instead of the more general "content". > > > >>> > > > >>> I also share the same personal view around interacting with > stores > > > of > > > >>> collected posture attribute values and evaluation results. The > > > larger > > > >>> data volumes and rate of change will likely require different > > > >>> approaches. I also believe that the temporal nature of this > data, > > > the > > > >>> need to persist historic information, will be more significant > > > >>> than other types of data that we may call "content". > > > >>> > > > >>> Are there other opinions on this? Does anyone feel strongly > that > > > >>> collected posture attribute values and evaluation results > SHOULD > > > NOT > > > >> be > > > >>> considered content? > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Dave > > > >>> > > > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > > > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > > > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > > > >> sacm@ietf.org > > > >>> *Subject:* RE: Types of content > > > >>> > > > >>> Would "dictionaries of posture attributes" include attribute > > > >>> values > > > >> that > > > >>> have been collected from endpoints? > > > >>> > > > >>> We want to have the ability to collect attribute values from > > > >> endpoints > > > >>> and "persist" them, as described in section 2.1.3. So we'll > need > > > >>> to > > > >> have > > > >>> a repository for collected and persisted attribute values. > > > >>> > > > >>> If collected endpoint attribute values are considered content, > > > let's > > > >> say > > > >>> so. If not, let's say that explicitly. > > > >>> > > > >>> My personal view is that collected endpoint attribute values > > > >>> should > > > >> be > > > >>> considered content. They may be a different kind of content > from > > > the > > > >>> others due to larger volume and higher change rate. For that > > > reason, > > > >>> people may choose to put them into a different repository and > > > >>> maybe > > > >> even > > > >>> use a different query protocol for that repository to munge the > > > large > > > >>> quantities of data. But they're still content. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Steve > > > >>> > > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos > > > >>> Kampanakis (pkampana) > > > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > > > >>> *To:* Waltermire, David A.; sacm@ietf.org > > > > >>> *Subject:* Re: [sacm] Types of content > > > >>> > > > >>> Sounds like a good summary of what "content" could mean. > > > >>> > > > >>> Panos > > > >>> > > > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > > > *Waltermire, > > > >>> David A. > > > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > > > >>> *To:* sacm@ietf.org > > > >>> *Subject:* [sacm] Types of content > > > >>> > > > >>> I'm working through the UC draft addressing discussion items > from > > > >>> yesterday and the previous comments we have received on the > list > > > >>> on > > > - > > > >> 05. > > > >>> > > > >>> Related to section 2.1.1, we have had many previous discussions > > > >> around > > > >>> the notional idea of content. There has been general agreement > > > >>> that > > > >> we > > > >>> need to be more specific. Please find below an attempt to put > some > > > >>> "bounds" around different types of content. > > > >>> > > > >>> Is this hitting the mark, or do we need to say something > > > >> more/different? > > > >>> > > > >>> The following is a snippet from a possible update to section > 2.1.1 > > > >> with > > > >>> some additional description: > > > >>> > > > >>> I'd appreciate any thoughts, concerns, objections before I > include > > > >> the > > > >>> changes in the draft. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Dave > > > >>> > > > >>> 2.1.1. Define, Publish, Query and Retrieve Content > > > >>> > > > >>> This use case describes the need for content to be defined > > > >>> and > > > >>> > > > >>> published to a data store, as well as queried and > retrieved > > > from > > > >> the > > > >>> > > > >>> data store for the explicit use of posture collection and > > > >> evaluation. > > > >>> > > > >>> The term "content" is a general concept that refers to any > > > data > > > >>> > > > >>> expression that may be used as part of the process of > > > collecting > > > >> and > > > >>> > > > >>> evaluating endpoint posture. Typical types of content > > > include: > > > >>> > > > >>> o Dictionaries of posture attributes (e.g. software > > > >> installation, > > > >>> > > > >>> configuration, privileges) that may be collected from a > > > given > > > >>> > > > >>> endpoint type that relate to installed hardware, > installed > > > >>> > > > >>> software, software configurations, accounts, > privileges, > > > and > > > >> other > > > >>> > > > >>> operational state. > > > >>> > > > >>> o Expressions that provide instructions for using a > specific > > > >> API, > > > >>> > > > >>> management protocol, or other mechanisms to collect > > > specific > > > >>> > > > >>> posture attributes from specific device types. > > > >>> > > > >>> o Policies that define the selected posture attributes > for > > > which > > > >>> > > > >>> values must be collected to support one or more posture > > > >>> > > > >>> assessments. This may include information that targets > > > >> collection > > > >>> > > > >>> to a specific set of endpoints and instructions on the > > > >> frequency > > > >>> > > > >>> and/or change events (e.g., configuration changes, > > > >>> software > > > >>> > > > >>> installation/uninstallation, account/privilege > > > modifications) > > > >> that > > > >>> > > > >>> will trigger collection of one or more posture > attributes. > > > >>> > > > >>> o Policies that define the logical criteria to evaluate > > > >> collected > > > >>> > > > >>> posture attribute values to determine if they meet > > > >> organizational > > > >>> > > > >>> requirements. This may include information that > targets > > > >>> > > > >>> evaluation to a specific set of endpoints. > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> sacm mailing list > > > >>> sacm@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/sacm > > > >>> > > > >> _______________________________________________ > > > >> sacm mailing list > > > >> sacm@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sacm > > > >> > > > > > > > > > > > > > >=20 >=20 From dromasca@avaya.com Thu Feb 13 09:14:33 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ED51A037A for ; Thu, 13 Feb 2014 09:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_zyDi07g-bi for ; Thu, 13 Feb 2014 09:14:29 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6DB1A036B for ; Thu, 13 Feb 2014 09:14:26 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwOAN78/FKHCzI1/2dsb2JhbABZgkIjIThXqCkIlxuBGBZ0gicBAQMSG14BDAkVViYBBBsBGYdjAQyWP4RSrGYXjkiCZw9mgRQEnxuLNIMtgio X-IronPort-AV: E=Sophos;i="4.95,839,1384318800"; d="scan'208,217";a="49343486" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Feb 2014 12:14:24 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 13 Feb 2014 12:01:30 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 18:14:23 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: preliminary agenda for the ietf-89 sacm wg meeting Thread-Index: Ac8o3wnBaKsMgkgyTcqiFQm5k7IQUA== Date: Thu, 13 Feb 2014 17:14:22 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E40AF35@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AF35AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [sacm] preliminary agenda for the ietf-89 sacm wg meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:14:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AF35AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have uploaded a preliminary agenda for the sacm wg meeting at ietf-89 at = http://www.ietf.org/proceedings/89/agenda/agenda-89-sacm. We are scheduled = to meet on Thursday 3/6, 0900-1130. If there are comments on the agenda or = other items which would benefit from discussions at the meeting please let = Adam and me know. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AF35AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have uploaded a preliminary agenda for the sacm wg= meeting at ietf-89 at http://www.ietf.org/proceedings/89/agenda/agenda-89-= sacm. We are scheduled to meet on Thursday 3/6, 0900-1130. If there are com= ments on the agenda or other items which would benefit from discussions at the meeting please let Adam and me= know.

 

Thanks and Regards,


Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AF35AZFFEXMB04globa_-- From nobody Thu Feb 13 12:18:40 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04051A04B5 for ; Thu, 13 Feb 2014 12:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZeK1RjQDTGv for ; Thu, 13 Feb 2014 12:18:35 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 701431A0434 for ; Thu, 13 Feb 2014 12:18:35 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id RpwF1n0041HzFnQ5FwJaPy; Thu, 13 Feb 2014 20:18:34 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta14.westchester.pa.mail.comcast.net with comcast id RwJZ1n0062yZEBF3awJZZ2; Thu, 13 Feb 2014 20:18:34 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "Adam Montville" References: <9904FB1B0159DA42B0B887B7FA8119CA2E40AF35@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E40AF35@AZ-FFEXMB04.global.avaya.com> Date: Thu, 13 Feb 2014 15:18:31 -0500 Message-ID: <007c01cf28f8$c3e8fb60$4bbaf220$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01CF28CE.DB1452F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFx7HsdwAuCx2qVFCDGguo1+wrWZ5tuFTPw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392322714; bh=DkMk+o+EMzmoeTLqNxvwzaCMWGr1o33x3wY7WHgmRO4=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=tKqac/gSpEGKtPyeoIIFHnZmir3p4ryWhPIeCzGySsmzaE1XEnfTxS/+iAQvMG0AE pxJKE8kr3OSq5P1RQsQfru4yEN2umPBtE1iV4aoOZzPWIcxweyHJh5pnxIC7M/93Jc hcb0GsE6546+AFjOfqyH6I1RL1YtbS6ZAAGZyWljGlDJjxRk3T3NlMIKzKA76BcqZ3 BnBEkmD6SD8I0a1Tl18HUs77VPQZ6icYQsqVz62wPbqLOv6npSqHoZQIJ9mXk1JY9n w6U4JFKvOIBg/F1hSFGFBIW9BsxhFq9DuxqRdgIgUVTHperl/PZxfNl/30K8hoTIWX WA2OoqCQzvcgw== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/pzy9Xo6uI_XGOIy1K8GdbyapU7A Cc: sacm@ietf.org Subject: Re: [sacm] preliminary agenda for the ietf-89 sacm wg meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:18:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007D_01CF28CE.DB1452F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I will not attend the London IETF meeting. When we split terminology from the other drafts, we discussed that terms used in multiple drafts should be included in -terminology- draft. Individual documents could use/define terms specific to that document, without including the term in the -terminology- draft. The authors of the various drafts would have responsibility for bringing the new term into the -terminology- draft. The only change performed on the latest terminology draft was done by Adam. He added a large number of terms found in various individual sacm-related documents. I realize this is just a work-in-progress thing, to consider whether we need to provide a cross-document definition for some of the terms. I suggest Adam discuss the terminology draft during the meeting. David Harrington dbharrington@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, February 13, 2014 12:14 PM To: sacm@ietf.org Subject: [sacm] preliminary agenda for the ietf-89 sacm wg meeting I have uploaded a preliminary agenda for the sacm wg meeting at ietf-89 at http://www.ietf.org/proceedings/89/agenda/agenda-89-sacm. We are scheduled to meet on Thursday 3/6, 0900-1130. If there are comments on the agenda or other items which would benefit from discussions at the meeting please let Adam and me know. Thanks and Regards, Dan ------=_NextPart_000_007D_01CF28CE.DB1452F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I will not attend the = London IETF meeting.

 

When we split = terminology from the other drafts, we discussed that terms used in = multiple drafts should be included in –terminology- = draft.

Individual documents could use/define terms = specific to that document, without including the term in the = –terminology- draft.

The authors of the = various drafts would have responsibility for bringing the new term into = the –terminology- draft.

 

The only change = performed on the latest terminology draft was done by Adam. =

He added a large number of terms found in = various individual sacm-related documents.

I realize this is just a = work-in-progress thing, to consider whether we need to provide a = cross-document definition for some of the terms.

I suggest Adam discuss = the terminology draft during the meeting.

 

+1-603-828-1401

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Thursday, February 13, 2014 12:14 PM
To: = sacm@ietf.org
Subject: [sacm] preliminary agenda for the = ietf-89 sacm wg meeting

 

I have = uploaded a preliminary agenda for the sacm wg meeting at ietf-89 at http://= www.ietf.org/proceedings/89/agenda/agenda-89-sacm. We are scheduled = to meet on Thursday 3/6, 0900-1130. If there are comments on the agenda = or other items which would benefit from discussions at the meeting = please let Adam and me know.

 

Thanks and = Regards,


Dan

 

------=_NextPart_000_007D_01CF28CE.DB1452F0-- From nobody Fri Feb 14 10:54:53 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FECD1A02E4 for ; Fri, 14 Feb 2014 10:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8hmwLOlDoz9 for ; Fri, 14 Feb 2014 10:54:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 86FDF1A02D0 for ; Fri, 14 Feb 2014 10:54:15 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.878.16; Fri, 14 Feb 2014 18:54:06 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.27]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.27]) with mapi id 15.00.0878.008; Fri, 14 Feb 2014 18:54:06 +0000 From: "Waltermire, David A." To: David Harrington , "'Romascanu, Dan (Dan)'" , Adam Montville Thread-Topic: [sacm] preliminary agenda for the ietf-89 sacm wg meeting Thread-Index: Ac8o3wnBaKsMgkgyTcqiFQm5k7IQUAAGbmCAAC8nkpA= Date: Fri, 14 Feb 2014 18:54:05 +0000 Message-ID: <328b889b9a5142998bdaee28bb667573@BLUPR09MB038.namprd09.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E40AF35@AZ-FFEXMB04.global.avaya.com> <007c01cf28f8$c3e8fb60$4bbaf220$@comcast.net> In-Reply-To: <007c01cf28f8$c3e8fb60$4bbaf220$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(189002)(199002)(2656002)(15975445006)(69226001)(74706001)(87266001)(56776001)(90146001)(95666001)(93516002)(56816005)(81342001)(81686001)(74366001)(76482001)(87936001)(74316001)(95416001)(81816001)(54356001)(85852003)(83072002)(46102001)(80022001)(54316002)(74502001)(47446002)(76576001)(65816001)(77096001)(74876001)(86362001)(31966008)(83322001)(74662001)(76796001)(19580405001)(59766001)(49866001)(51856001)(63696002)(77982001)(19300405004)(66066001)(76786001)(19609705001)(19580395003)(85306002)(81542001)(15202345003)(79102001)(93136001)(47736001)(16236675002)(94316002)(92566001)(53806001)(50986001)(80976001)(47976001)(94946001)(4396001)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:B6A2F1D9.1EB247D1.70D3BD7F.80E199CD.2031B; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_328b889b9a5142998bdaee28bb667573BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/lfhAfj_ksqk58v3GJVYl8C2w7M8 Cc: "sacm@ietf.org" Subject: Re: [sacm] preliminary agenda for the ietf-89 sacm wg meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:54:47 -0000 --_000_328b889b9a5142998bdaee28bb667573BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I concur with David's thoughts on the terminology draft. Adam has been work= ing on the latest. This does represent an area where we need to focus some = work on going forward. I'm happy to lead the Use Cases discussion. I'll focus the discussion aroun= d the remaining open questions in the draft I plan to post today. Tone wise= I like to keep an eye towards wrapping up the current use cases efforts sh= ortly after the meeting. Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington Sent: Thursday, February 13, 2014 3:19 PM To: 'Romascanu, Dan (Dan)'; Adam Montville Cc: sacm@ietf.org Subject: Re: [sacm] preliminary agenda for the ietf-89 sacm wg meeting Hi, I will not attend the London IETF meeting. When we split terminology from the other drafts, we discussed that terms us= ed in multiple drafts should be included in -terminology- draft. Individual documents could use/define terms specific to that document, with= out including the term in the -terminology- draft. The authors of the various drafts would have responsibility for bringing th= e new term into the -terminology- draft. The only change performed on the latest terminology draft was done by Adam. He added a large number of terms found in various individual sacm-related d= ocuments. I realize this is just a work-in-progress thing, to consider whether we nee= d to provide a cross-document definition for some of the terms. I suggest Adam discuss the terminology draft during the meeting. David Harrington dbharrington@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, February 13, 2014 12:14 PM To: sacm@ietf.org Subject: [sacm] preliminary agenda for the ietf-89 sacm wg meeting I have uploaded a preliminary agenda for the sacm wg meeting at ietf-89 at = http://www.ietf.org/proceedings/89/agenda/agenda-89-sacm. We are scheduled = to meet on Thursday 3/6, 0900-1130. If there are comments on the agenda or = other items which would benefit from discussions at the meeting please let = Adam and me know. Thanks and Regards, Dan --_000_328b889b9a5142998bdaee28bb667573BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I concur with David= 217;s thoughts on the terminology draft. Adam has been working on the lates= t. This does represent an area where we need to focus some work on going fo= rward.

 

I’m happy to lea= d the Use Cases discussion. I’ll focus the discussion around the rema= ining open questions in the draft I plan to post today. Tone wise I like to= keep an eye towards wrapping up the current use cases efforts shortly after the meeting.

 

Dave=

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Thursday, February 13, 2014 3:19 PM
To: 'Romascanu, Dan (Dan)'; Adam Montville
Cc: sacm@ietf.org
Subject: Re: [sacm] preliminary agenda for the ietf-89 sacm wg meeti= ng

 

Hi,

 

I will not attend the = London IETF meeting.

 

When we split terminol= ogy from the other drafts, we discussed that terms used in multiple drafts = should be included in –terminology- draft.

Individual documents c= ould use/define terms specific to that document, without including the term= in the –terminology- draft.

The authors of the var= ious drafts would have responsibility for bringing the new term into the &#= 8211;terminology- draft.

 

The only change perfor= med on the latest terminology draft was done by Adam.

He added a large numbe= r of terms found in various individual sacm-related documents.

I realize this is just= a work-in-progress thing, to consider whether we need to provide a cross-d= ocument definition for some of the terms.

I suggest Adam discuss= the terminology draft during the meeting.

 

David Harrington

dbharrington@comcast.net

+1-603-828-1401<= span style=3D"color:#1F497D">

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, February 13, 2014 12:14 PM
To: sacm@ietf.org
Subject: [sacm] preliminary agenda for the ietf-89 sacm wg meeting

 

I have uploaded a preliminary agenda for the sacm wg= meeting at ietf-89 at http:/= /www.ietf.org/proceedings/89/agenda/agenda-89-sacm. We are scheduled to= meet on Thursday 3/6, 0900-1130. If there are comments on the agenda or ot= her items which would benefit from discussions at the meeting please let Adam and me know.

 

Thanks and Regards,


Dan

 

--_000_328b889b9a5142998bdaee28bb667573BLUPR09MB038namprd09pro_-- From nobody Fri Feb 14 16:11:20 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D351A01E0 for ; Fri, 14 Feb 2014 16:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZNCPFQdGakt for ; Fri, 14 Feb 2014 16:11:06 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 4F45D1A0140 for ; Fri, 14 Feb 2014 16:11:06 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 00:11:03 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.27]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.27]) with mapi id 15.00.0878.008; Sat, 15 Feb 2014 00:11:03 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: Updated Use Cases Thread-Index: Ac8p4fT33qt60T/0SjCsZI0/ykvEjQ== Date: Sat, 15 Feb 2014 00:11:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(199002)(189002)(54316002)(50986001)(2656002)(79102001)(94316002)(87936001)(59766001)(83072002)(65816001)(31966008)(47446002)(47976001)(74316001)(74662001)(15202345003)(81816001)(56776001)(19609705001)(85306002)(74366001)(92566001)(74502001)(66066001)(74876001)(94946001)(51856001)(33646001)(16236675002)(80022001)(74706001)(49866001)(46102001)(85852003)(93516002)(77982001)(63696002)(87266001)(86362001)(4396001)(93136001)(47736001)(76796001)(54356001)(19580395003)(90146001)(81342001)(76576001)(95416001)(81542001)(83322001)(69226001)(76482001)(19300405004)(80976001)(76786001)(76176001)(77096001)(558084003)(53806001)(56816005)(81686001)(15975445006)(95666001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:762E575A.17D1E43A.42FDB279.F0FC8C00.20094; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_004_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/HeEBTxEIPR64Rv2LMhfD5Ui8d2A Subject: [sacm] Updated Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:11:18 -0000 --_004_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_ Content-Type: multipart/alternative; boundary="_000_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_" --_000_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just missed the I/D cutoff by a couple minutes. Please find the updated use cases draft attached. I'll be using this for di= scussion at the meeting. I'll post it when the data tracker reopens on 3/3/= 2014. Thanks, Dave --_000_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just missed the I/D cutoff by a couple minutes.

 

Please find the updated use cases draft attached. I&= #8217;ll be using this for discussion at the meeting. I’ll post it wh= en the data tracker reopens on 3/3/2014.

 

Thanks,

Dave

--_000_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_-- --_004_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_ Content-Type: text/plain; name="draft-ietf-sacm-use-cases-06.txt" Content-Description: draft-ietf-sacm-use-cases-06.txt Content-Disposition: attachment; filename="draft-ietf-sacm-use-cases-06.txt"; size=64367; creation-date="Sat, 15 Feb 2014 00:08:31 GMT"; modification-date="Sat, 15 Feb 2014 00:04:07 GMT" Content-Transfer-Encoding: base64 CgoKClNlY3VyaXR5IEF1dG9tYXRpb24gYW5kIENvbnRpbnVvdXMgTW9uaXRvcmluZyBXRyAgICAg ICAgICAgRC4gV2FsdGVybWlyZQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5JU1QKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBIYXJyaW5ndG9uCkV4cGly ZXM6IEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVmZmVjdGl2 ZSBTb2Z0d2FyZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmVicnVhcnkgMTUsIDIwMTQKCgogICAgICBFbmRwb2ludCBTZWN1cml0eSBQb3N0 dXJlIEFzc2Vzc21lbnQgLSBFbnRlcnByaXNlIFVzZSBDYXNlcwogICAgICAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi1zYWNtLXVzZS1jYXNlcy0wNgoKQWJzdHJhY3QKCiAgIFRoaXMgbWVtbyBk b2N1bWVudHMgYSBzYW1wbGluZyBvZiB1c2UgY2FzZXMgZm9yIHNlY3VyZWx5IGFnZ3JlZ2F0aW5n CiAgIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIGRhdGEgYW5kIGV2YWx1YXRpbmcgdGhh dCBkYXRhIHRvCiAgIGRldGVybWluZSBhbiBvcmdhbml6YXRpb24ncyBzZWN1cml0eSBwb3N0dXJl LiAgRnJvbSB0aGVzZSBvcGVyYXRpb25hbAogICB1c2UgY2FzZXMsIHdlIGNhbiBkZXJpdmUgY29t bW9uIGZ1bmN0aW9uYWwgY2FwYWJpbGl0aWVzIGFuZAogICByZXF1aXJlbWVudHMgdG8gZ3VpZGUg ZGV2ZWxvcG1lbnQgb2YgdmVuZG9yLW5ldXRyYWwsIGludGVyb3BlcmFibGUKICAgc3RhbmRhcmRz IGZvciBhZ2dyZWdhdGluZyBhbmQgZXZhbHVhdGluZyBkYXRhIHJlbGV2YW50IHRvIHNlY3VyaXR5 CiAgIHBvc3R1cmUuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0 IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMg b2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJy ZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCAxOSwgMjAxNC4KCkNvcHly aWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNCBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyBy ZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJ RVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50 cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24g dGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZp ZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJp Z2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAg Q29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAoKCgpXYWx0 ZXJtaXJlICYgSGFycmluZ3RvbiAgRXhwaXJlcyBBdWd1c3QgMTksIDIwMTQgICAgICAgICAgICAg ICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdEVudGVycHJpc2UgVXNlIENhc2VzIGZvciBTZWN1 cml0eSBBc3Nlc3NtZW50IEZlYnJ1YXJ5IDIwMTQKCgogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0 IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRl bnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIEVuZHBvaW50IFBvc3R1cmUgQXNzZXNzbWVudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMi4xLiAgVXNlIENhc2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAg ICAgMi4xLjEuICBEZWZpbmUsIFB1Ymxpc2gsIFF1ZXJ5IGFuZCBSZXRyaWV2ZSBTZWN1cml0eQog ICAgICAgICAgICAgICBBdXRvbWF0aW9uIERhdGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDUKICAgICAgIDIuMS4yLiAgRW5kcG9pbnQgSWRlbnRpZmljYXRpb24gYW5k IEFzc2Vzc21lbnQgUGxhbm5pbmcgLiAuIC4gICA5CiAgICAgICAyLjEuMy4gIEVuZHBvaW50IFBv c3R1cmUgQXR0cmlidXRlIFZhbHVlIENvbGxlY3Rpb24gLiAuIC4gLiAuICAxMAogICAgICAgMi4x LjQuICBQb3N0dXJlIEV2YWx1YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTEKICAgICAgIDIuMS41LiAgTWluaW5nIHRoZSBEYXRhYmFzZSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgMi4yLiAgVXNhZ2UgU2NlbmFyaW9zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICAgICAgMi4yLjEuICBEZWZp bml0aW9uIGFuZCBQdWJsaWNhdGlvbiBvZiBBdXRvbWF0YWJsZQogICAgICAgICAgICAgICBDb25m aWd1cmF0aW9uIENoZWNrbGlzdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAg ICAgIDIuMi4yLiAgQXV0b21hdGVkIENoZWNrbGlzdCBWZXJpZmljYXRpb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE0CiAgICAgICAyLjIuMy4gIERldGVjdGlvbiBvZiBQb3N0dXJlIERldmlhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNgogICAgICAgMi4yLjQuICBFbmRwb2ludCBJbmZv cm1hdGlvbiBBbmFseXNpcyBhbmQgUmVwb3J0aW5nIC4gLiAuIC4gLiAgMTcKICAgICAgIDIuMi41 LiAgQXN5bmNocm9ub3VzIENvbXBsaWFuY2UvVnVsbmVyYWJpbGl0eSBBc3Nlc3NtZW50IGF0CiAg ICAgICAgICAgICAgIEljZSBTdGF0aW9uIFplYnJhIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxOAogICAgICAgMi4yLjYuICBJZGVudGlmaWNhdGlvbiBhbmQgUmV0cmlldmFs IG9mIEd1aWRhbmNlICAuIC4gLiAuIC4gLiAgMjAKICAgICAgIDIuMi43LiAgR3VpZGFuY2UgQ2hh bmdlIERldGVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxCiAgICAgICAyLjIu OC4gIE90aGVycy4uLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAyMQogICAzLiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjEKICAgNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxCiAgIDUuICBBY2tub3dsZWRnZW1l bnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMQogICA2 LiAgQ2hhbmdlIExvZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjIKICAgICA2LjEuICAtMDUtIHRvIC0wNi0gIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIyCiAgICAgNi4yLiAgLTA0LSB0byAtMDUtICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMgogICAgIDYuMy4gIC0w My0gdG8gLTA0LSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MjMKICAgICA2LjQuICAtMDItIHRvIC0wMy0gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDIzCiAgICAgNi41LiAgLTAxLSB0byAtMDItICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNAogICAgIDYuNi4gIC0wMC0gdG8gLTAx LSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjQKICAgICA2 LjcuICBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTA1IHRvIGRyYWZ0LWlldGYtc2Fj bS0KICAgICAgICAgICB1c2UtY2FzZXMtMDAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDI1CiAgICAgNi44LiAgd2FsdGVybWlyZSAtMDQtIHRvIC0wNS0gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNgogICA3LiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjcKICAgQXV0 aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDI3CgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgY29yZSBzZXQgb2YgdXNlIGNhc2VzIGZvciBlbmRwb2ludAogICBwb3N0dXJlIGFzc2Vzc21l bnQgZm9yIGVudGVycHJpc2VzLiAgSXQgcHJvdmlkZXMgYSBkaXNjdXNzaW9uIG9mCiAgIHRoZXNl IHVzZSBjYXNlcyBhbmQgYXNzb2NpYXRlZCBidWlsZGluZyBibG9jayBjYXBhYmlsaXRpZXMgdGhh dAogICBzdXBwb3J0IHNlY3VyZWx5IGFnZ3JlZ2F0aW5nIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJh dGlvbmFsIGRhdGEgYW5kCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBpcmVzIEF1Z3Vz dCAxOSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0RW50ZXJw cmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVhcnkgMjAxNAoKCiAg IGV2YWx1YXRpbmcgdGhhdCBkYXRhIHRvIGRldGVybWluZSB0aGUgc2VjdXJpdHkgcG9zdHVyZSBv ZiBpbmRpdmlkdWFsCiAgIGVuZHBvaW50cywgYW5kLCBpbiB0aGUgYWdncmVnYXRlLCB0aGUgc2Vj dXJpdHkgcG9zdHVyZSBvZiBhbgogICBlbnRlcnByaXNlLiAgQWRkaXRpb25hbGx5LCB0aGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhIHNldCBvZiB1c2FnZQogICBzY2VuYXJpb3MgdGhhdCBwcm92aWRl IGV4YW1wbGVzIGZvciB1c2luZyB0aGUgdXNlIGNhc2VzIGFuZAogICBhc3NvY2lhdGVkIGJ1aWxk aW5nIGJsb2NrcyB0byBhZGRyZXNzIGEgdmFyaWV0eSBvZiBvcGVyYXRpb25hbAogICBmdW5jdGlv bnMuCgogICBUaGVzZSB1c2UgY2FzZXMgYW5kIHVzYWdlIHNjZW5lcmllcyBjcm9zcyBtYW55IElU IHNlY3VyaXR5CiAgIGluZm9ybWF0aW9uIGRvbWFpbnMuICBGcm9tIHRoZXNlIG9wZXJhdGlvbmFs IHVzZSBjYXNlcywgd2UgY2FuIGRlcml2ZQogICBjb21tb24gY29uY2VwdHMsIGNvbW1vbiBpbmZv cm1hdGlvbiBleHByZXNzaW9ucywgZnVuY3Rpb25hbAogICBjYXBhYmlsaXRpZXMgYW5kIHJlcXVp cmVtZW50cyB0byBndWlkZSBkZXZlbG9wbWVudCBvZiB2ZW5kb3ItbmV1dHJhbCwKICAgaW50ZXJv cGVyYWJsZSBzdGFuZGFyZHMgZm9yIGFnZ3JlZ2F0aW5nIGFuZCBldmFsdWF0aW5nIGRhdGEgcmVs ZXZhbnQKICAgdG8gc2VjdXJpdHkgcG9zdHVyZS4KCiAgIFVzaW5nIHRoaXMgc3RhbmRhcmQgZGF0 YSwgdG9vbHMgY2FuIGFuYWx5emUgdGhlIHN0YXRlIG9mIGVuZHBvaW50cywKICAgdXNlciBhY3Rp dml0aWVzIGFuZCBiZWhhdmlvdXIsIGFuZCBldmFsdWF0ZSB0aGUgc2VjdXJpdHkgcG9zdHVyZSBv ZgogICBhbiBvcmdhbml6YXRpb24uICBDb21tb24gZXhwcmVzc2lvbiBvZiBpbmZvcm1hdGlvbiBz aG91bGQgZW5hYmxlCiAgIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0b29scyAod2hldGhlciBj dXN0b21pemVkLCBjb21tZXJjaWFsLCBvcgogICBmcmVlbHkgYXZhaWxhYmxlKSwgYW5kIHRoZSBh YmlsaXR5IHRvIGF1dG9tYXRlIHBvcnRpb25zIG9mIHNlY3VyaXR5CiAgIHByb2Nlc3NlcyB0byBn YWluIGVmZmljaWVuY3ksIHJlYWN0IHRvIG5ldyB0aHJlYXRzIGluIGEgdGltZWx5CiAgIG1hbm5l ciwgYW5kIGZyZWUgdXAgc2VjdXJpdHkgcGVyc29ubmVsIHRvIHdvcmsgb24gbW9yZSBhZHZhbmNl ZAogICBwcm9ibGVtcy4KCiAgIFRoZSBnb2FsIGlzIHRvIGVuYWJsZSBvcmdhbml6YXRpb25zIHRv IG1ha2UgaW5mb3JtZWQgZGVjaXNpb25zIHRoYXQKICAgc3VwcG9ydCBvcmdhbml6YXRpb25hbCBv YmplY3RpdmVzLCB0byBlbmZvcmNlIHBvbGljaWVzIGZvciBoYXJkZW5pbmcKICAgc3lzdGVtcywg dG8gcHJldmVudCBuZXR3b3JrIG1pc3VzZSwgdG8gcXVhbnRpZnkgYnVzaW5lc3MgcmlzaywgYW5k IHRvCiAgIGNvbGxhYm9yYXRlIHdpdGggcGFydG5lcnMgdG8gaWRlbnRpZnkgYW5kIG1pdGlnYXRl IHRocmVhdHMuCgogICBJdCBpcyBleHBlY3RlZCB0aGF0IHVzZSBjYXNlcyBmb3IgZW50ZXJwcmlz ZXMgYW5kIGZvciBzZXJ2aWNlCiAgIHByb3ZpZGVycyB3aWxsIGxhcmdlbHkgb3ZlcmxhcCwgYnV0 IHRoZXJlIGFyZSBhZGRpdGlvbmFsCiAgIGNvbXBsaWNhdGlvbnMgZm9yIHNlcnZpY2UgcHJvdmlk ZXJzLCBlc3BlY2lhbGx5IGluIGhhbmRsaW5nCiAgIGluZm9ybWF0aW9uIHRoYXQgY3Jvc3NlcyBh ZG1pbmlzdHJhdGl2ZSBkb21haW5zLgoKICAgVGhlIG91dHB1dCBvZiBlbmRwb2ludCBwb3N0dXJl IGFzc2Vzc21lbnQgaXMgZXhwZWN0ZWQgdG8gZmVlZCBpbnRvCiAgIGFkZGl0aW9uYWwgcHJvY2Vz c2VzLCBzdWNoIGFzIHBvbGljeS1iYXNlZCBlbmZvcmNlbWVudCBvZiBhY2NlcHRhYmxlCiAgIHN0 YXRlLCB2ZXJpZmljYXRpb24gYW5kIG1vbml0b3Jpbmcgb2Ygc2VjdXJpdHkgY29udHJvbHMsIGFu ZAogICBjb21wbGlhbmNlIHRvIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzLgoKMi4gIEVuZHBvaW50 IFBvc3R1cmUgQXNzZXNzbWVudAoKICAgRW5kcG9pbnQgcG9zdHVyZSBhc3Nlc3NtZW50IGludm9s dmVzIG9yY2hlc3RyYXRpbmcgYW5kIHBlcmZvcm1pbmcKICAgZGF0YSBjb2xsZWN0aW9uIGFuZCBl dmFsdWF0aW5nIHRoZSBwb3N0dXJlIG9mIGEgZ2l2ZW4gZW5kcG9pbnQuCiAgIFR5cGljYWxseSwg ZW5kcG9pbnQgcG9zdHVyZSBpbmZvcm1hdGlvbiBpcyBnYXRoZXJlZCBhbmQgdGhlbgogICBwdWJs aXNoZWQgdG8gYXBwcm9wcmlhdGUgZGF0YSByZXBvc2l0b3JpZXMgdG8gbWFrZSBjb2xsZWN0ZWQK ICAgaW5mb3JtYXRpb24gYXZhaWxhYmxlIGZvciBmdXJ0aGVyIGFuYWx5c2lzIHN1cHBvcnRpbmcg b3JnYW5pemF0aW9uYWwKICAgc2VjdXJpdHkgcHJvY2Vzc2VzLgoKICAgRW5kcG9pbnQgcG9zdHVy ZSBhc3Nlc3NtZW50IHR5cGljYWxseSBpbmNsdWRlczoKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0 b24gIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50 ZXJuZXQtRHJhZnRFbnRlcnByaXNlIFVzZSBDYXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBG ZWJydWFyeSAyMDE0CgoKICAgbyAgQ29sbGVjdGluZyB0aGUgYXR0cmlidXRlcyBvZiBhIGdpdmVu IGVuZHBvaW50OwoKICAgbyAgTWFraW5nIHRoZSBhdHRyaWJ1dGVzIGF2YWlsYWJsZSBmb3IgZXZh bHVhdGlvbiBhbmQgYWN0aW9uOyBhbmQKCiAgIG8gIFZlcmlmeWluZyB0aGF0IHRoZSBlbmRwb2lu dCdzIHBvc3R1cmUgaXMgaW4gY29tcGxpYW5jZSB3aXRoCiAgICAgIGVudGVycHJpc2Ugc3RhbmRh cmRzIGFuZCBwb2xpY3kuCgogICBBcyBwYXJ0IG9mIHRoZXNlIGFjdGl2aXRpZXMgaXQgaXMgb2Z0 ZW4gbmVjZXNzYXJ5IHRvIGlkZW50aWZ5IGFuZAogICBhY3F1aXJlIGFueSBzdXBwb3J0aW5nIHNl Y3VyaXR5IGF1dG9tYXRpb24gZGF0YSB0aGF0IGlzIG5lZWRlZCB0bwogICBkcml2ZSBhbmQgZmVl ZCBkYXRhIGNvbGxlY3Rpb24gYW5kIGV2YWx1YXRpb24gcHJvY2Vzc2VzLgoKICAgVGhlIGZvbGxv d2luZyBpcyBhIHR5cGljYWwgd29ya2Zsb3cgc2NlbmFyaW8gZm9yIGFzc2Vzc2luZyBlbmRwb2lu dAogICBwb3N0dXJlOgoKICAgMS4gIFNvbWUgdHlwZSBvZiB0cmlnZ2VyIGluaXRpYXRlcyB0aGUg d29ya2Zsb3cuICBGb3IgZXhhbXBsZSwgYW4KICAgICAgIG9wZXJhdG9yIG9yIGFuIGFwcGxpY2F0 aW9uIG1pZ2h0IHRyaWdnZXIgdGhlIHByb2Nlc3Mgd2l0aCBhCiAgICAgICByZXF1ZXN0LCBvciB0 aGUgZW5kcG9pbnQgbWlnaHQgdHJpZ2dlciB0aGUgcHJvY2VzcyB1c2luZyBhbgogICAgICAgZXZl bnQtZHJpdmVuIG5vdGlmaWNhdGlvbi4KCiAgIDIuICBBbiBvcGVyYXRvci9hcHBsaWNhdGlvbiBz ZWxlY3RzIG9uZSBvciBtb3JlIHRhcmdldCBlbmRwb2ludHMgdG8KICAgICAgIGJlIGFzc2Vzc2Vk LgoKICAgMy4gIEFuIG9wZXJhdG9yL2FwcGxpY2F0aW9uIHNlbGVjdHMgd2hpY2ggcG9saWNpZXMg YXJlIGFwcGxpY2FibGUgdG8KICAgICAgIHRoZSB0YXJnZXRzLgoKICAgNC4gIEZvciBlYWNoIHRh cmdldDoKCiAgICAgICBBLiAgVGhlIGFwcGxpY2F0aW9uIGRldGVybWluZXMgd2hpY2ggKHNldHMg b2YpIHBvc3R1cmUgYXR0cmlidXRlcwogICAgICAgICAgIG5lZWQgdG8gYmUgY29sbGVjdGVkIGZv ciBldmFsdWF0aW9uLiAgSW1wbGVtZW50YXRpb25zIHNob3VsZAogICAgICAgICAgIGJlIGFibGUg dG8gc3VwcG9ydCAocG9zc2libHkgbWl4ZWQpIHNldHMgb2Ygc3RhbmRhcmRpemVkIGFuZAogICAg ICAgICAgIHByb3ByaWV0YXJ5IGF0dHJpYnV0ZXMuCgogICAgICAgQi4gIFRoZSBhcHBsaWNhdGlv biBtaWdodCByZXRyaWV2ZSBwcmV2aW91c2x5IGNvbGxlY3RlZAogICAgICAgICAgIGluZm9ybWF0 aW9uIGZyb20gYSBjYWNoZSBvciBkYXRhIHN0b3JlLCBzdWNoIGFzIGEgZGF0YSBzdG9yZQogICAg ICAgICAgIHBvcHVsYXRlZCBieSBhbiBhc3NldCBtYW5hZ2VtZW50IHN5c3RlbS4KCiAgICAgICBD LiAgVGhlIGFwcGxpY2F0aW9uIG1pZ2h0IGVzdGFibGlzaCBjb21tdW5pY2F0aW9uIHdpdGggdGhl CiAgICAgICAgICAgdGFyZ2V0LCBtdXR1YWxseSBhdXRoZW50aWNhdGUgaWRlbnRpdGllcyBhbmQg YXV0aG9yaXphdGlvbnMsCiAgICAgICAgICAgYW5kIGNvbGxlY3QgcG9zdHVyZSBhdHRyaWJ1dGVz IGZyb20gdGhlIHRhcmdldC4KCiAgICAgICBELiAgVGhlIGFwcGxpY2F0aW9uIG1pZ2h0IGVzdGFi bGlzaCBjb21tdW5pY2F0aW9uIHdpdGggb25lIG9yCiAgICAgICAgICAgbW9yZSBpbnRlcm1lZGlh cnkvYWdlbnRzLCBtdXR1YWxseSBhdXRoZW50aWNhdGUgdGhlaXIKICAgICAgICAgICBpZGVudGl0 aWVzIGFuZCBkZXRlcm1pbmUgYXV0aG9yaXphdGlvbnMsIGFuZCBjb2xsZWN0IHBvc3R1cmUKICAg ICAgICAgICBhdHRyaWJ1dGVzIGFib3V0IHRoZSB0YXJnZXQgZnJvbSB0aGUgaW50ZXJtZWRpYXJ5 L2FnZW50cy4KICAgICAgICAgICBTdWNoIGFnZW50cyBtaWdodCBiZSBsb2NhbCBvciBleHRlcm5h bC4KCgoKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0 ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnRFbnRlcnByaXNlIFVzZSBD YXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0CgoKICAgICAgIEUuICBU aGUgYXBwbGljYXRpb24gY29tbXVuaWNhdGVzIHRhcmdldCBpZGVudGl0eSBhbmQgKHNldHMgb2Yp CiAgICAgICAgICAgY29sbGVjdGVkIGF0dHJpYnV0ZXMgdG8gYW4gZXZhbHVhdG9yLCBwb3NzaWJs eSBhbiBleHRlcm5hbAogICAgICAgICAgIHByb2Nlc3Mgb3IgZXh0ZXJuYWwgc3lzdGVtLgoKICAg ICAgIEYuICBUaGUgZXZhbHVhdG9yIGNvbXBhcmVzIHRoZSBjb2xsZWN0ZWQgcG9zdHVyZSBhdHRy aWJ1dGVzIHdpdGgKICAgICAgICAgICBleHBlY3RlZCB2YWx1ZXMgYXMgZXhwcmVzc2VkIGluIHBv bGljaWVzLgoKICAgICAgIEcuICBUaGUgZXZhbHVhdG9yIHJlcG9ydHMgdGhlIGV2YWx1YXRpb24g cmVzdWx0IGZvciB0aGUgcmVxdWVzdGVkCiAgICAgICAgICAgYXNzZXNzbWVudCwgaW4gYSBzdGFu ZGFyZGl6ZWQgb3IgcHJvcHJpZXRhcnkgZm9ybWF0LCBzdWNoIGFzCiAgICAgICAgICAgYSByZXBv cnQsIGEgbG9nIGVudHJ5LCBhIGRhdGFiYXNlIGVudHJ5LCBvciBhIG5vdGlmaWNhdGlvbi4KCjIu MS4gIFVzZSBDYXNlcwoKICAgVGhlIGZvbGxvd2luZyBzdWJzZWN0aW9ucyBkZXRhaWwgc3BlY2lm aWMgdXNlIGNhc2VzIGZvciBhc3Nlc3NtZW50CiAgIHBsYW5uaW5nLCBkYXRhIGNvbGxlY3Rpb24s IGFuYWx5c2lzLCBhbmQgcmVsYXRlZCBvcGVyYXRpb25zCiAgIHBlcnRhaW5pbmcgdG8gdGhlIHB1 YmxpY2F0aW9uIGFuZCB1c2Ugb2Ygc3VwcG9ydGluZyBkYXRhLiAgRWFjaCB1c2UKICAgY2FzZSBp cyBkZWZpbmVkIGJ5IGEgc2hvcnQgc3VtbWFyeSBjb250YWluaW5nIGEgc2ltcGxlIHByb2JsZW0K ICAgc3RhdGVtZW50LCBmb2xsb3dlZCBieSBhIGRpc2N1c3Npb24gb2YgcmVsYXRlZCBjb25jZXB0 cywgYW5kIGEKICAgbGlzdGluZyBvZiBhc3NvY2lhdGVkIGJ1aWxkaW5nIGJsb2NrcyB3aGljaCBy ZXByZXNlbnQgdGhlCiAgIGNhcGFiaWxpdGllcyBuZWVkZWQgdG8gc3VwcG9ydCB0aGUgdXNlIGNh c2UuICBUaGVzZSB1c2UgY2FzZXMgYW5kCiAgIGJ1aWxkaW5nIGJsb2NrcyBpZGVudGlmeSBzZXBh cmF0ZSB1bml0cyBvZiBmdW5jdGlvbmFsaXR5IHRoYXQgbWF5IGJlCiAgIHN1cHBvcnRlZCBieSBk aWZmZXJlbnQgY29tcG9uZW50cyBvZiBhbiBhcmNoaXRlY3R1cmFsIG1vZGVsLgoKMi4xLjEuICBE ZWZpbmUsIFB1Ymxpc2gsIFF1ZXJ5IGFuZCBSZXRyaWV2ZSBTZWN1cml0eSBBdXRvbWF0aW9uIERh dGEKCiAgIFRoaXMgdXNlIGNhc2UgZGVzY3JpYmVzIHRoZSBuZWVkIGZvciBzZWN1cml0eSBhdXRv bWF0aW9uIGRhdGEgdG8gYmUKICAgZGVmaW5lZCBhbmQgcHVibGlzaGVkIHRvIG9uZSBvciBtb3Jl IGRhdGEgc3RvcmVzLCBhcyB3ZWxsIGFzIHF1ZXJpZWQKICAgYW5kIHJldHJpZXZlZCBmcm9tIHRo ZXNlIGRhdGEgc3RvcmVzIGZvciB0aGUgZXhwbGljaXQgdXNlIG9mIHBvc3R1cmUKICAgY29sbGVj dGlvbiBhbmQgZXZhbHVhdGlvbi4KCiAgIFNlY3VyaXR5IGF1dG9tYXRpb24gZGF0YSBpcyBhIGdl bmVyYWwgY29uY2VwdCB0aGF0IHJlZmVycyB0byBhbnkgZGF0YQogICBleHByZXNzaW9uIHRoYXQg bWF5IGJlIGdlbmVyYXRlZCBhbmQvb3IgdXNlZCBhcyBwYXJ0IG9mIHRoZSBwcm9jZXNzCiAgIG9m IGNvbGxlY3RpbmcgYW5kIGV2YWx1YXRpbmcgZW5kcG9pbnQgcG9zdHVyZS4gIERpZmZlcmVudCB0 eXBlcyBvZgogICBzZWN1cml0eSBhdXRvbWF0aW9uIGRhdGEgd2lsbCBnZW5lcmFsbHkgZmFsbCBp bnRvIG9uZSBvZiB0aHJlZQogICBjYXRlZ29yaWVzOgoKICAgR3VpZGFuY2U6ICBJbnN0cnVjdGlv bnMgYW5kIHJlbGF0ZWQgbWV0YWRhdGEgdGhhdCBndWlkZSB0aGUgYXR0cmlidXRlCiAgICAgICAg IGNvbGxlY3Rpb24gYW5kIGV2YWx1YXRpb24gcHJvY2Vzc2VzLiAgVGhlIHB1cnBvc2Ugb2YgdGhp cyBkYXRhCiAgICAgICAgIGlzIHRvIGFsbG93IGltcGxlbWVudGF0aW9ucyB0byBiZSBkYXRhLWRy aXZlbiBlbmFibGluZyB0aGVpcgogICAgICAgICBiZWhhdmlvciB0byBiZSBjdXN0b21pemVkIHdp dGhvdXQgcmVxdWlyaW5nIGNoYW5nZXMgdG8gZGVwbG95ZWQKICAgICAgICAgc29mdHdhcmUuCgog ICAgICAgICBUaGlzIHR5cGUgb2YgZGF0YSB0ZW5kcyB0byBjaGFuZ2UgaW4gdW5pdHMgb2YgbW9u dGhzIGFuZCBkYXlzLgogICAgICAgICBJbiBjYXNlcyB3aGVyZSBhc3Nlc3NtZW50cyBhcmUgbWFk ZSBtb3JlIGR5bmFtaWMsIGl0IG1heSBiZQogICAgICAgICBuZWNlc3NhcnkgdG8gaGFuZGxlIGNo YW5nZXMgaW4gdGhlIHNjb3BlIG9mIGhvdXJzIG9yIG1pbnV0ZXMuCiAgICAgICAgIFRoaXMgZGF0 YSB3aWxsIHR5cGljYWxseSBiZSBwcm92aWRlZCBieSBsYXJnZSBvcmdhbml6YXRpb25zLAogICAg ICAgICBwcm9kdWN0IHZlbmRvcnMsIGFuZCBzb21lIDNyZC1wYXJ0aWVzLiAgVGh1cywgaXQgd2ls bCB0ZW5kIHRvCiAgICAgICAgIGJlIHNoYXJlZCBhY3Jvc3MgbGFyZ2UgZW50ZXJwcmlzZXMgYW5k IGN1c3RvbWVyIGNvbW11bml0aWVzLgoKCgpXYWx0ZXJtaXJlICYgSGFycmluZ3RvbiAgRXhwaXJl cyBBdWd1c3QgMTksIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFm dEVudGVycHJpc2UgVXNlIENhc2VzIGZvciBTZWN1cml0eSBBc3Nlc3NtZW50IEZlYnJ1YXJ5IDIw MTQKCgogICAgICAgICBJbiBzb21lIGNhc2VzIGFjY2VzcyBtYXkgYmUgY29udHJvbGxlZCB0byBz cGVjaWZpYwogICAgICAgICBhdXRoZW50aWNhdGVkIHVzZXJzLiAgSW4gb3RoZXIgY2FzZXMsIHRo ZSBkYXRhIG1heSBiZSBwcm92aWRlZAogICAgICAgICBicm9hZGx5IHdpdGggbGl0dGxlIHRvIG5v IGFjY2VzcyBjb250cm9sLgoKICAgICAgICAgVGhpcyBpbmNsdWRlczoKCiAgICAgICAgICogIExp c3RpbmdzIG9mIGF0dHJpYnV0ZSBpZGVudGlmaWVycyBmb3Igd2hpY2ggdmFsdWVzIG1heSBiZQog ICAgICAgICAgICBjb2xsZWN0ZWQgYW5kIGV2YWx1YXRlZAoKICAgICAgICAgKiAgTGlzdHMgb2Yg YXR0cmlidXRlcyB0aGF0IGFyZSB0byBiZSBjb2xsZWN0ZWQgYWxvbmcgd2l0aAogICAgICAgICAg ICBtZXRhZGF0YSB0aGF0IGluY2x1ZGVzOiB3aGVuIHRvIGNvbGxlY3QgYSBzZXQgb2YgYXR0cmli dXRlcwogICAgICAgICAgICBiYXNlZCBvbiBhIGRlZmluZWQgaW50ZXJ2YWwgb3IgZXZlbnQsIHRo ZSBkdXJhdGlvbiBvZgogICAgICAgICAgICBjb2xsZWN0aW9uLCBhbmQgaG93IHRvIGdvIGFib3V0 IGNvbGxlY3RpbmcgYSBzZXQgb2YKICAgICAgICAgICAgYXR0cmlidXRlcy4KCiAgICAgICAgICog IEd1aWRhbmNlIHRoYXQgc3BlY2lmaWVzIGhvdyBvbGQgY29sbGVjdGVkIGRhdGEgY2FuIGJlIHRv IGJlCiAgICAgICAgICAgIHVzZWQgZm9yIGV2YWx1YXRpb24uCgogICAgICAgICAqICBQb2xpY2ll cyB0aGF0IGRlZmluZSBob3cgdG8gdGFyZ2V0IGFuZCBwZXJmb3JtIHRoZQogICAgICAgICAgICBl dmFsdWF0aW9uIG9mIGEgc2V0IG9mIGF0dHJpYnV0ZXMgZm9yIGRpZmZlcmVudCBraW5kcyBvcgog ICAgICAgICAgICBncm91cHMgb2YgZW5kcG9pbnRzIGFuZCB0aGUgYXNzZXRzIHRoZXkgYXJlIGNv bXBvc2VkIG9mLiAgSW4KICAgICAgICAgICAgc29tZSBjYXNlcyBpdCBtYXkgYmUgZGVzaXJhYmxl IHRvIG1haW50YWluIGhpZXJhcmNoaWVzIG9mCiAgICAgICAgICAgIHBvbGljaWVzIGFzIHdlbGwu CgogICAgICAgICAqICBSZWZlcmVuY2VzIHRvIGh1bWFuIG9yaWVudGVkLWRhdGEgdGhhdCBwcm92 aWRlIHRlY2huaWNhbCwKICAgICAgICAgICAgb3JnYW5pemF0aW9uYWwsIGFuZC9vciBwb2xpY3kg Y29udGV4dC4gIFRoaXMgbWlnaHQgaW5jbHVkZQogICAgICAgICAgICByZWZlcmVuY2VzIHRvOiBi ZXN0IHByYWN0aWNlcyBkb2N1bWVudHMsIGxlZ2FsIGd1aWRhbmNlIGFuZAogICAgICAgICAgICBs ZWdpc2xhdGlvbiwgYW5kIGluc3RydWN0aW9uYWwgbWF0ZXJpYWxzIHJlbGF0ZWQgdG8gdGhlCiAg ICAgICAgICAgIGF1dG9tYXRpb24gZGF0YSBpbiBxdWVzdGlvbi4KCiAgIEF0dHJpYnV0ZSBEYXRh OiAgRGF0YSBjb2xsZWN0ZWQgdGhyb3VnaCBhdXRvbWF0ZWQgYW5kIG1hbnVhbAogICAgICAgICBt ZWNoYW5pc21zIGRlc2NyaWJpbmcgb3JnYW5pemF0aW9uYWwgYW5kIHBvc3R1cmUgZGV0YWlscwog ICAgICAgICBwZXJ0YWluaW5nIHRvIHNwZWNpZmljIGVuZHBvaW50cyBhbmQgdGhlIGFzc2V0cyB0 aGF0IHRoZXkgYXJlCiAgICAgICAgIGNvbXBvc2VkIG9mIChlLmcuLCBoYXJkd2FyZSwgc29mdHdh cmUsIGFjY291bnRzKS4gIFRoZSBwdXJwb3NlCiAgICAgICAgIG9mIHRoaXMgdHlwZSBvZiBkYXRh IGlzIHRvIGNoYXJhY3Rlcml6ZSBhbiBlbmRwb2ludCAoZS5nLiwKICAgICAgICAgZW5kcG9pbnQg dHlwZSwgb3JnYW5pemF0aW9uYWxseSBleHBlY3RlZCBmdW5jdGlvbi9yb2xlKSBhbmQgdG8KICAg ICAgICAgcHJvdmlkZSBhY3R1YWwgYW5kIGV4cGVjdGVkIHN0YXRlIGRhdGEgcGVydGFpbmluZyB0 byBvbmUgb3IKICAgICAgICAgbW9yZSBlbmRwb2ludHMuICBUaGlzIGRhdGEgaXMgdXNlZCB0byBk ZXRlcm1pbmUgd2hhdCBwb3N0dXJlCiAgICAgICAgIGF0dHJpYnV0ZXMgdG8gY29sbGVjdCBmcm9t IHdoaWNoIGVuZHBvaW50cyBhbmQgdG8gZmVlZCBvbmUgb3IKICAgICAgICAgbW9yZSBldmFsdWF0 aW9ucy4KCiAgICAgICAgIFRoaXMgdHlwZSBvZiBkYXRhIHRlbmRzIHRvIGNoYW5nZSBpbiB1bml0 cyBvZiBkYXlzLCBtaW51dGVzLCBhCiAgICAgICAgIHNlY29uZHMgd2l0aCBwb3N0dXJlIGF0dHJp YnV0ZSB2YWx1ZXMgdHlwaWNhbGx5IGNoYW5naW5nIG1vcmUKICAgICAgICAgZnJlcXVlbnRseSB0 aGFuIGVuZHBvaW50IGNoYXJhY3Rlcml6YXRpb25zLiAgVGhpcyBkYXRhIHRlbmRzIHRvCiAgICAg ICAgIGJlIG9yZ2FuaXphdGlvbmFsbHkgYW5kIGVuZHBvaW50IHNwZWNpZmljLCB3aXRoIHNwZWNp ZmljCiAgICAgICAgIG9wZXJhdGlvbmFsIGdyb3VwcyBvZiBlbmRwb2ludHMgdGVuZGluZyB0byBl eGhpYml0IHNpbWlsYXIKICAgICAgICAgYXR0cmlidXRlIHByb2ZpbGVzLiAgVGhpcyBkYXRhIHdp bGwgZ2VuZXJhbGx5IG5vdCBiZSBzaGFyZWQKCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBF eHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0 LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVh cnkgMjAxNAoKCiAgICAgICAgIG91dHNpZGUgYW4gb3JnYW5pemF0aW9uYWwgYm91bmRhcnkgYW5k IHdpbGwgZ2VuZXJhbGx5IHJlcXVpcmUKICAgICAgICAgYXV0aGVudGljYXRpb24gd2l0aCBzcGVj aWZpYyBhY2Nlc3MgY29udHJvbHMuCgogICAgICAgICBUaGlzIGluY2x1ZGVzOgoKICAgICAgICAg KiAgRW5kcG9pbnQgY2hhcmFjdGVyaXphdGlvbiBkYXRhIHRoYXQgZGVzY3JpYmVzIHRoZSBlbmRw b2ludAogICAgICAgICAgICB0eXBlLCBvcmdhbml6YXRpb25hbGx5IGV4cGVjdGVkIGZ1bmN0aW9u L3JvbGUsIGV0Yy4KCiAgICAgICAgICogIENvbGxlY3RlZCBlbmRwb2ludCBwb3N0dXJlIGF0dHJp YnV0ZSB2YWx1ZXMgYW5kIHJlbGF0ZWQKICAgICAgICAgICAgY29udGV4dCBpbmNsdWRpbmc6IHRp bWUgb2YgY29sbGVjdGlvbiwgdG9vbHMgdXNlZCBmb3IKICAgICAgICAgICAgY29sbGVjdGlvbiwg ZXRjLgoKICAgICAgICAgKiAgT3JnYW5pemF0aW9uYWxseSBkZWZpbmVkIGV4cGVjdGVkIHBvc3R1 cmUgYXR0cmlidXRlIHZhbHVlcwogICAgICAgICAgICB0YXJnZXRlZCB0byBzcGVjaWZpYyBldmFs dWF0aW9uIGd1aWRhbmNlIGFuZCBlbmRwb2ludAogICAgICAgICAgICBjaGFyYWN0ZXJpc3RpY3Mu ICBUaGlzIGFsbG93cyBhIGNvbW1vbiBzZXQgb2YgZ3VpZGFuY2UgdG8gYmUKICAgICAgICAgICAg cGFyYW1ldGVyaXplZCBmb3IgdXNlIHdpdGggZGlmZmVyZW50IGdyb3VwcyBvZiBlbmRwb2ludHMu CgogICBQcm9jZXNzaW5nIEFydGlmYWN0czogIERhdGEgdGhhdCBpcyBnZW5lcmF0ZWQgYnkgYW5k IGlzIHNwZWNpZmljIHRvCiAgICAgICAgIGFuIGluZGl2aWR1YWwgYXNzZXNzbWVudCBwcm9jZXNz LiAgVGhpcyBkYXRhIG1heSBiZSB1c2VkIGFzCiAgICAgICAgIHBhcnQgb2YgdGhlIGludGVyYWN0 aW9ucyBiZXR3ZWVuIGFyY2hpdGVjdHVyYWwgY29tcG9uZW50cyB0bwogICAgICAgICBkcml2ZSBh bmQgY29vcmRpbmF0ZSBjb2xsZWN0aW9uIGFuZCBldmFsdWF0aW9uIGFjdGl2aXRpZXMuICBJdHMK ICAgICAgICAgbGlmZXNwYW4gd2lsbCBiZSBib3VuZGVkIGJ5IHRoZSBsaWZlc3BhbiBvZiB0aGUg YXNzZXNzbWVudC4gIEl0CiAgICAgICAgIG1heSBhbHNvIGJlIGV4Y2hhbmdlZCBhbmQgc3RvcmVk IHRvIHByb3ZpZGUgaGlzdG9yaWMgY29udGV4dAogICAgICAgICBhcm91bmQgYW4gYXNzZXNzbWVu dCBhY3Rpdml0eSBzbyB0aGF0IGluZGl2aWR1YWwgYXNzZXNzbWVudHMKICAgICAgICAgY2FuIGJl IGdyb3VwZWQsIGV2YWx1YXRlZCwgYW5kIHJlcG9ydGVkIGluIGFuIGVudGVycHJpc2UKICAgICAg ICAgY29udGV4dC4KCiAgICAgICAgIFRoaXMgaW5jbHVkZXM6CgogICAgICAgICAqICBUaGUgaWRl bnRpZmllZCBzZXQgb2YgZW5kcG9pbnRzIGZvciB3aGljaCBhbiBhc3Nlc3NtZW50CiAgICAgICAg ICAgIHNob3VsZCBiZSBwZXJmb3JtZWQuCgogICAgICAgICAqICBUaGUgaWRlbnRpZmllZCBzZXQg b2YgcG9zdHVyZSBhdHRyaWJ1dGVzIHRoYXQgbmVlZCB0byBiZQogICAgICAgICAgICBjb2xsZWN0 ZWQgZnJvbSBzcGVjaWZpYyBlbmRwb2ludHMgdG8gcGVyZm9ybSBhbiBldmFsdWF0aW9uLgoKICAg ICAgICAgKiAgVGhlIHJlc3VsdGluZyBkYXRhIGdlbmVyYXRlZCBieSBhbiBldmFsdWF0aW9uIHBy b2Nlc3MKICAgICAgICAgICAgaW5jbHVkaW5nIHRoZSBjb250ZXh0IG9mIHdoYXQgd2FzIGFzc2Vz c2VkLCB3aGF0IGl0IHdhcwogICAgICAgICAgICBhc3Nlc3NlZCBhZ2FpbnN0LCB3aGF0IGNvbGxl Y3RlZCBkYXRhIHdhcyB1c2VkLCB3aGVuIGl0IHdhcwogICAgICAgICAgICBjb2xsZWN0ZWQsIGFu ZCB3aGVuIHRoZSBldmFsdWF0aW9uIHdhcyBwZXJmb3JtZWQuCgogICBUaGUgaW5mb3JtYXRpb24g bW9kZWwgZm9yIHNlY3VyaXR5IGF1dG9tYXRpb24gZGF0YSBtdXN0IHN1cHBvcnQgYQogICB2YXJp ZXR5IG9mIGRpZmZlcmVudCBkYXRhIHR5cGVzIGFzIGRlc2NyaWJlZCBhYm92ZSwgYWxvbmcgd2l0 aCB0aGUKICAgYXNzb2NpYXRlZCBtZXRhZGF0YSB0aGF0IGlzIG5lZWRlZCB0byBzdXBwb3J0IHB1 YmxpY2F0aW9uLCBxdWVyeSwgYW5kCiAgIHJldHJpZXZhbCBvcGVyYXRpb25zLiAgSXQgaXMgZXhw ZWN0ZWQgdGhhdCBtdWx0aXBsZSBkYXRhIG1vZGVscyB3aWxsCiAgIGJlIHVzZWQgdG8gZXhwcmVz cyBzcGVjaWZpYyBkYXRhIHR5cGVzIHJlcXVpcmluZyBzcGVjaWFsaXplZCBvcgogICBleHRlbnNp YmxlIHNlY3VyaXR5IGF1dG9tYXRpb24gZGF0YSByZXBvc2l0b3JpZXMuICBUaGUgZGlmZmVyZW50 CiAgIHRlbXBvcmFsIGNoYXJhY3RlcmlzdGljcywgYWNjZXNzIHBhdHRlcm5zLCBhbmQgYWNjZXNz IGNvbnRyb2wKICAgZGltZW5zaW9ucyBvZiBlYWNoIGRhdGEgdHlwZSBtYXkgYWxzbyByZXF1aXJl IGRpZmZlcmVudCBwcm90b2NvbHMgYW5kCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBp cmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURy YWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVhcnkg MjAxNAoKCiAgIGRhdGEgbW9kZWxzIHRvIGJlIHN1cHBvcnRlZCBmdXJ0aGVyaW5nIHRoZSBwb3Rl bnRpYWwgcmVxdWlyZW1lbnQgZm9yCiAgIHNwZWNpYWxpemVkIGRhdGEgcmVwb3NpdG9yaWVzLiAg U2VlIFtSRkMzNDQ0XSBmb3IgYSBkZXNjcmlwdGlvbiBhbmQKICAgZGlzY3Vzc2lvbiBvZiBkaXN0 aW5jdGlvbnMgYmV0d2VlbiBhbiBpbmZvcm1hdGlvbiBhbmQgZGF0YSBtb2RlbC4gIEl0CiAgIGlz IGxpa2VseSB0aGF0IGFkZGl0aW9uYWwga2luZHMgb2YgZGF0YSB3aWxsIGJlIGlkZW50aWZpZWQg dGhyb3VnaAogICB0aGUgcHJvY2VzcyBvZiBkZWZpbmluZyByZXF1aXJlbWVudHMgYW5kIGFuIGFy Y2hpdGVjdHVyYWwgbW9kZWwuCiAgIEltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nIHRoaXMgYnVp bGRpbmcgYmxvY2sgd2lsbCBuZWVkIHRvIGJlCiAgIGV4dGVuc2libGUgdG8gYWNjb21tb2RhdGUg dGhlIGFkZGl0aW9uIG9mIG5ldyB0eXBlcyBvZiBkYXRhLCBib3RoCiAgIHByb3ByaWV0YXJ5IG9y IChwcmVmZXJhYmx5KSB1c2luZyBhIHN0YW5kYXJkIGZvcm1hdC4KCiAgIFRoZSBidWlsZGluZyBi bG9ja3Mgb2YgdGhpcyB1c2UgY2FzZSBhcmU6CgogICBEYXRhIERlZmluaXRpb246ICBTZWN1cml0 eSBhdXRvbWF0aW9uIGRhdGEgd2lsbCBndWlkZSBhbmQgaW5mb3JtCiAgICAgICAgIGNvbGxlY3Rp b24gYW5kIGV2YWx1YXRpb24gcHJvY2Vzc2VzLiAgVGhpcyBkYXRhIG1heSBiZSBkZXNpZ25lZAog ICAgICAgICBieSBhIHZhcmlldHkgb2Ygcm9sZXMgLSBhcHBsaWNhdGlvbiBpbXBsZW1lbnRlcnMg bWF5IGJ1aWxkCiAgICAgICAgIHNlY3VyaXR5IGF1dG9tYXRpb24gZGF0YSBpbnRvIHRoZWlyIGFw cGxpY2F0aW9uczsKICAgICAgICAgYWRtaW5pc3RyYXRvcnMgbWF5IGRlZmluZSBndWlkYW5jZSBi YXNlZCBvbiBvcmdhbml6YXRpb25hbAogICAgICAgICBwb2xpY2llczsgb3BlcmF0b3JzIG1heSBk ZWZpbmUgZ3VpZGFuY2UgYW5kIGF0dHJpYnV0ZSBkYXRhIGFzCiAgICAgICAgIG5lZWRlZCBmb3Ig ZXZhbHVhdGlvbiBhdCBydW50aW1lLCBhbmQgc28gb24uICBEYXRhIHByb2R1Y2VycwogICAgICAg ICBtYXkgY2hvb3NlIHRvIHJldXNlIGRhdGEgZnJvbSBleGlzdGluZyBzdG9yZXMgb2Ygc2VjdXJp dHkKICAgICAgICAgYXV0b21hdGlvbiBkYXRhIGFuZCBtYXkgY3JlYXRlIG5ldyBkYXRhLiAgRGF0 YSBwcm9kdWNlcnMgbWF5CiAgICAgICAgIGRldmVsb3AgZGF0YSBiYXNlZCBvbiBhdmFpbGFibGUg c3RhbmRhcmRpemVkIG9yIHByb3ByaWV0YXJ5CiAgICAgICAgIGRhdGEgbW9kZWxzLCBzdWNoIGFz IHRob3NlIHVzZWQgZm9yIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQvb3IKICAgICAgICAgaG9zdCBt YW5hZ2VtZW50LgoKICAgRGF0YSBQdWJsaWNhdGlvbjogIFRoZSBjYXBhYmlsaXR5IHRvIGVuYWJs ZSBkYXRhIHByb2R1Y2VycyB0byBwdWJsaXNoCiAgICAgICAgIGRhdGEgdG8gYSBzZWN1cml0eSBh dXRvbWF0aW9uIGRhdGEgc3RvcmUgZm9yIGZ1cnRoZXIgdXNlLgogICAgICAgICBQdWJsaXNoZWQg ZGF0YSBtYXkgYmUgbWFkZSBwdWJsaWNseSBhdmFpbGFibGUgb3IgYWNjZXNzIG1heSBiZQogICAg ICAgICBiYXNlZCBvbiBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIHVzaW5nIGF1dGhlbnRpY2F0 ZWQKICAgICAgICAgY3JlZGVudGlhbHMuICBBcyBhIHJlc3VsdCwgdGhlIHZpc2liaWxpdHkgb2Yg c3BlY2lmaWMgc2VjdXJpdHkKICAgICAgICAgYXV0b21hdGlvbiBkYXRhIHRvIGFuIG9wZXJhdG9y IG9yIGFwcGxpY2F0aW9uIG1heSBiZSBwdWJsaWMsCiAgICAgICAgIGVudGVycHJpc2Utc2NvcGVk LCBwcml2YXRlLCBvciBjb250cm9sbGVkIHdpdGhpbiBhbnkgb3RoZXIKICAgICAgICAgc2NvcGUu CgogICBEYXRhIFF1ZXJ5OiAgQW4gb3BlcmF0b3Igb3IgYXBwbGljYXRpb24gc2hvdWxkIGJlIGFi bGUgdG8gcXVlcnkgYQogICAgICAgICBzZWN1cml0eSBhdXRvbWF0aW9uIGRhdGEgc3RvcmUgdXNp bmcgYSBzZXQgb2Ygc3BlY2lmaWVkCiAgICAgICAgIGNyaXRlcmlhLiAgVGhlIHJlc3VsdCBvZiB0 aGUgcXVlcnkgd2lsbCBiZSBhIGxpc3RpbmcgbWF0Y2hpbmcKICAgICAgICAgdGhlIHF1ZXJ5LiAg VGhlIHF1ZXJ5IHJlc3VsdCBsaXN0aW5nIG1heSBjb250YWluIHB1YmxpY2F0aW9uCiAgICAgICAg IG1ldGFkYXRhIChlLmcuLCBjcmVhdGUgZGF0ZSwgbW9kaWZpZWQgZGF0ZSwgcHVibGlzaGVyLCBl dGMuKQogICAgICAgICBhbmQvb3IgdGhlIGZ1bGwgZGF0YSwgYSBzdW1tYXJ5LCBzbmlwcGV0LCBv ciB0aGUgbG9jYXRpb24gdG8KICAgICAgICAgcmV0cmlldmUgdGhlIGRhdGEuCgogICBEYXRhIFJl dHJpZXZhbDogIEFuIHVzZXIsIG9wZXJhdG9yLCBvciBhcHBsaWNhdGlvbiBhY3F1aXJlcyBvbmUg b3IKICAgICAgICAgbW9yZSBzcGVjaWZpYyBzZWN1cml0eSBhdXRvbWF0aW9uIGRhdGEgZW50cmll cy4gIFRoZSBsb2NhdGlvbgogICAgICAgICBvZiB0aGUgZGF0YSBtYXkgYmUga25vd24gYSBwcmlv cmksIG9yIG1heSBiZSBkZXRlcm1pbmVkIGJhc2VkCiAgICAgICAgIG9uIGRlY2lzaW9ucyBtYWRl IHVzaW5nIGluZm9ybWF0aW9uIGZyb20gYSBwcmV2aW91cyBxdWVyeS4KCiAgIERhdGEgQ2hhbmdl IERldGVjdGlvbjogIEFuIG9wZXJhdG9yIG9yIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGtub3cgd2hl bgogICAgICAgICBzZWN1cml0eSBhdXRvbWF0aW9uIGRhdGEgdGhleSBpbnRlcmVzdGVkIGluIGhh cyBiZWVuIHB1Ymxpc2hlZAoKCgpXYWx0ZXJtaXJlICYgSGFycmluZ3RvbiAgRXhwaXJlcyBBdWd1 c3QgMTksIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdEVudGVy cHJpc2UgVXNlIENhc2VzIGZvciBTZWN1cml0eSBBc3Nlc3NtZW50IEZlYnJ1YXJ5IDIwMTQKCgog ICAgICAgICB0bywgdXBkYXRlZCBpbiwgb3IgZGVsZXRlZCBmcm9tIGEgc2VjdXJpdHkgYXV0b21h dGlvbiBkYXRhCiAgICAgICAgIHN0b3JlIHdoaWNoIHRoZXkgaGF2ZSBiZWVuIGF1dGhvcml6ZWQg dG8gYWNjZXNzLgoKICAgVGhlc2UgYnVpbGRpbmcgYmxvY2tzIGFyZSB1c2VkIHRvIGVuYWJsZSBh Y3F1aXNpdGlvbiBvZiB2YXJpb3VzCiAgIGluc3RhbmNlcyBvZiBzZWN1cml0eSBhdXRvbWF0aW9u IGRhdGEgYmFzZWQgb24gc3BlY2lmaWMgZGF0YSBtb2RlbHMKICAgdGhhdCBhcmUgdXNlZCB0byBk cml2ZSBhc3Nlc3NtZW50IHBsYW5uaW5nIChzZWUgc2VjdGlvbiAyLjEuMiksCiAgIHBvc3R1cmUg YXR0cmlidXRlIHZhbHVlIGNvbGxlY3Rpb24gKHNlZSBzZWN0aW9uIDIuMS4zKSwgYW5kIHBvc3R1 cmUKICAgZXZhbHVhdGlvbiAoc2VlIHNlY3Rpb24gMi4xLjQpLgoKMi4xLjIuICBFbmRwb2ludCBJ ZGVudGlmaWNhdGlvbiBhbmQgQXNzZXNzbWVudCBQbGFubmluZwoKICAgVGhpcyB1c2UgY2FzZSBk ZXNjcmliZXMgdGhlIHByb2Nlc3Mgb2YgZGlzY292ZXJpbmcgZW5kcG9pbnRzLAogICB1bmRlcnN0 YW5kaW5nIHRoZWlyIGNvbXBvc2l0aW9uLCBpZGVudGlmeWluZyB0aGUgZGVzaXJlZCBzdGF0ZSB0 bwogICBhc3Nlc3MgYWdhaW5zdCwgYW5kIGNhbGN1bGF0aW5nIHdoYXQgcG9zdHVyZSBhdHRyaWJ1 dGVzIHRvIGNvbGxlY3QgdG8KICAgZW5hYmxlIGV2YWx1YXRpb24uICBUaGlzIHByb2Nlc3MgbWF5 IGJlIGEgc2V0IG9mIG1hbnVhbCwgYXV0b21hdGVkLAogICBvciBoeWJyaWQgc3RlcHMgdGhhdCBh cmUgcGVyZm9ybWVkIGZvciBlYWNoIGFzc2Vzc21lbnQuCgogICBUaGUgYnVpbGRpbmcgYmxvY2tz IG9mIHRoaXMgdXNlIGNhc2UgYXJlOgoKICAgRW5kcG9pbnQgRGlzY292ZXJ5OiAgVG8gZGV0ZXJt aW5lIHRoZSBjdXJyZW50IG9yIGhpc3RvcmljIHByZXNlbmNlIG9mCiAgICAgICAgIGVuZHBvaW50 cyBpbiB0aGUgZW52aXJvbm1lbnQgdGhhdCBhcmUgYXZhaWxhYmxlIGZvciBwb3N0dXJlCiAgICAg ICAgIGFzc2Vzc21lbnQuCgogICBFbmRwb2ludCBDaGFyYWN0ZXJpemF0aW9uOiAgVGhlIGFjdCBv ZiBhY3F1aXJpbmcsIHRocm91Z2ggYXV0b21hdGVkCiAgICAgICAgIGNvbGxlY3Rpb24gb3IgbWFu dWFsIGlucHV0LCBhbmQgb3JnYW5pemluZyBhdHRyaWJ1dGVzCiAgICAgICAgIGFzc29jaWF0ZWQg d2l0aCBhbiBlbmRwb2ludCAoZS5nLiwgdHlwZSwgb3JnYW5pemF0aW9uYWxseQogICAgICAgICBl eHBlY3RlZCBmdW5jdGlvbi9yb2xlLCBoYXJkd2FyZS9zb2Z0d2FyZSB2ZXJzaW9ucykuCgogICBJ ZGVudGlmeSBFbmRwb2ludCBUYXJnZXRzOiAgRGV0ZXJtaW5lIHRoZSBjYW5kaWRhdGUgZW5kcG9p bnQKICAgICAgICAgdGFyZ2V0KHMpIGFnYWluc3Qgd2hpY2ggdG8gcGVyZm9ybSB0aGUgYXNzZXNz bWVudC4gIERlcGVuZGluZwogICAgICAgICBvbiB0aGUgYXNzZXNzbWVudCB0cmlnZ2VyLCBhIHNp bmdsZSBlbmRwb2ludCBvciBtdWx0aXBsZQogICAgICAgICBlbmRwb2ludHMgbWF5IGJlIHRhcmdl dGVkIGJhc2VkIG9uIGNoYXJhY3Rlcml6ZWQgZW5kcG9pbnQKICAgICAgICAgYXR0cmlidXRlcy4g IEd1aWRhbmNlIGRlc2NyaWJpbmcgdGhlIGFzc2Vzc21lbnQgdG8gYmUgcGVyZm9ybWVkCiAgICAg ICAgIG1heSBjb250YWluIGluc3RydWN0aW9ucyBvciByZWZlcmVuY2VzIHVzZWQgdG8gZGV0ZXJt aW5lIHRoZQogICAgICAgICBhcHBsaWNhYmxlIGFzc2Vzc21lbnQgdGFyZ2V0cy4gIEluIHRoaXMg Y2FzZSB0aGUgRGF0YSBRdWVyeSBhbmQKICAgICAgICAgL29yIERhdGEgUmV0cmlldmFsIGJ1aWxk aW5nIGJsb2NrcyAoc2VlIHNlY3Rpb24gMi4xLjEpIG1heSBiZQogICAgICAgICB1c2VkIHRvIGFj cXVpcmUgdGhpcyBkYXRhLgoKICAgICAgICAgUVVFU1RJT046IFNob3VsZCB0aGlzIGluY2x1ZGUg YXV0aGVudGljYXRpb24gb2YgdGhlIHRhcmdldD8KCiAgIEVuZHBvaW50IENvbXBvbmVudCBJbnZl bnRvcnk6ICBUbyBkZXRlcm1pbmUgd2hhdCBhcHBsaWNhYmxlIGRlc2lyZWQKICAgICAgICAgc3Rh dGVzIHNob3VsZCBiZSBhc3Nlc3NlZCwgaXQgaXMgZmlyc3QgbmVjZXNzYXJ5IHRvIGFjcXVpcmUg dGhlCiAgICAgICAgIGludmVudG9yeSBvZiBzb2Z0d2FyZSwgaGFyZHdhcmUsIGFuZCBhY2NvdW50 cyBhc3NvY2lhdGVkIHdpdGgKICAgICAgICAgdGhlIHRhcmdldGVkIGVuZHBvaW50KHMpLiAgSWYg dGhlIGFzc2Vzc21lbnQgb2YgdGhlIGVuZHBvaW50IGlzCiAgICAgICAgIG5vdCBkZXBlbmRhbnQg b24gdGhlIGNvbXBvbmVudCBpbnZlbnRvcnksIHRoZW4gdGhpcyBjYXBhYmlsaXR5CiAgICAgICAg IGlzIG5vdCByZXF1aXJlZCBmb3IgdXNlIGluIHBlcmZvcm1pbmcgdGhlIGFzc2Vzc21lbnQuICBU aGlzCiAgICAgICAgIHByb2Nlc3MgY2FuIGJlIHRyZWF0ZWQgYXMgYSBjb2xsZWN0aW9uIHVzZSBj YXNlIGZvciBzcGVjaWZpYwogICAgICAgICBwb3N0dXJlIGF0dHJpYnV0ZXMuICBJbiB0aGlzIGNh c2UgdGhlIGJ1aWxkaW5nIGJsb2NrcyBmb3IKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4 cGlyZXMgQXVndXN0IDE5LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQt RHJhZnRFbnRlcnByaXNlIFVzZSBDYXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFy eSAyMDE0CgoKICAgICAgICAgRW5kcG9pbnQgUG9zdHVyZSBBdHRyaWJ1dGUgVmFsdWUgQ29sbGVj dGlvbiAoc2VlIHNlY3Rpb24gMi4xLjMpCiAgICAgICAgIGNhbiBiZSB1c2VkLgoKICAgUG9zdHVy ZSBBdHRyaWJ1dGUgSWRlbnRpZmljYXRpb246ICBPbmNlIHRoZSBlbmRwb2ludCB0YXJnZXRzIGFu ZAogICAgICAgICBjb21wb25lbnQgaW52ZW50b3J5IGlzIGtub3duLCBpdCBpcyB0aGVuIG5lY2Vz c2FyeSB0byBjYWxjdWxhdGUKICAgICAgICAgd2hhdCBwb3N0dXJlIGF0dHJpYnV0ZXMgYXJlIHJl cXVpcmVkIHRvIGJlIGNvbGxlY3RlZCB0byBwZXJmb3JtCiAgICAgICAgIHRoZSBldmFsdWF0aW9u LiAgSWYgdGhpcyBpcyBkcml2ZW4gYnkgZ3VpZGFuY2UsIHRoZW4gdGhlIERhdGEKICAgICAgICAg UXVlcnkgYW5kL29yIERhdGEgUmV0cmlldmFsIGJ1aWxkaW5nIGJsb2NrcyAoc2VlIHNlY3Rpb24g Mi4xLjEpCiAgICAgICAgIG1heSBiZSB1c2VkIHRvIGFjcXVpcmUgdGhpcyBkYXRhLgoKICAgUVVF U1RJT046IEFyZSB3ZSBtaXNzaW5nIGEgYnVpbGRpbmcgYmxvY2sgdGhhdCBkZXRlcm1pbmVzIHdo YXQKICAgcHJldmlvdXNseSBjb2xsZWN0ZWQgZGF0YSwgaWYgYW55LCBpcyBzdWl0YWJsZSBmb3Ig ZXZhbHVhdGlvbiBhbmQKICAgd2hhdCBkYXRhIG5lZWRzIHRvIGJlIGFjdHVhbGx5IGNvbGxlY3Rl ZD8gIFNob3VsZCBhIGJ1aWxkaW5nIGJsb2NrIGJlCiAgIGlkZW50aWZpZWQgdGhhdCBldmFsdWF0 ZXMgZXhpc3RpbmcgZGF0YSB0byBkZXRlcm1pbmUgaWYgaXQgaXMgY3VycmVudAogICBlbm91Z2gg Zm9yIHVzZSBpbiB0aGUgZXZhbHVhdGlvbiBvciBpZiBjdXJyZW50IGRhdGEgc2hvdWxkIGJlCiAg IGNvbGxlY3RlZCBhbnl3YXkgYWNjb3JkaW5nIHRvIGEgcG9saWN5PwoKICAgQ09NTUVOVChEUik6 IFByb2JhYmx5IHllcywgdGFraW5nIGludG8gYWNjb3VudCB1c2FnZSBzY2VuYXJpb3MgbGlrZQog ICAyLjIuMiwgMi4yLjMgd2hpY2ggcmVseSBvbiBoaXN0b3JpY2FsIGRhdGEuCgogICBBdCB0aGlz IHBvaW50IHRoZSBzZXQgb2YgcG9zdHVyZSBhdHRyaWJ1dGUgdmFsdWVzIHRvIHVzZSBmb3IKICAg ZXZhbHVhdGlvbiBhcmUga25vd24gYW5kIHRoZXkgY2FuIGJlIGNvbGxlY3RlZCBpZiBuZWNlc3Nh cnkgKHNlZQogICBzZWN0aW9uIDIuMS4zKS4KCjIuMS4zLiAgRW5kcG9pbnQgUG9zdHVyZSBBdHRy aWJ1dGUgVmFsdWUgQ29sbGVjdGlvbgoKICAgVGhpcyB1c2UgY2FzZSBkZXNjcmliZXMgdGhlIHBy b2Nlc3Mgb2YgY29sbGVjdGluZyBhIHNldCBvZiBwb3N0dXJlCiAgIGF0dHJpYnV0ZSB2YWx1ZXMg cmVsYXRlZCB0byBvbmUgb3IgbW9yZSBlbmRwb2ludHMuICBUaGlzIHVzZSBjYXNlIGNhbgogICBi ZSBpbml0aWF0ZWQgYnkgYSB2YXJpZXR5IG9mIHRyaWdnZXJzIGluY2x1ZGluZzoKCiAgIDEuICBB IHBvc3R1cmUgY2hhbmdlIG9yIHNpZ25pZmljYW50IGV2ZW50IG9uIHRoZSBlbmRwb2ludC4KCiAg IDIuICBBIG5ldHdvcmsgZXZlbnQgKGUuZy4sIGVuZHBvaW50IGNvbm5lY3RzIHRvIGEgbmV0d29y ay9WUE4sCiAgICAgICBzcGVjaWZpYyBuZXRmbG93IGlzIGRldGVjdGVkKS4KCiAgIDMuICBEdWUg dG8gYSBzY2hlZHVsZWQgb3IgYWQgaG9jIGNvbGxlY3Rpb24gdGFzay4KCiAgIFRoZSBidWlsZGlu ZyBibG9ja3Mgb2YgdGhpcyB1c2UgY2FzZSBhcmU6CgogICBDb2xsZWN0aW9uIEd1aWRhbmNlIEFj cXVpc2l0aW9uOiAgSWYgZ3VpZGFuY2UgaXMgcmVxdWlyZWQgdG8gZHJpdmUKICAgICAgICAgdGhl IGNvbGxlY3Rpb24gb2YgcG9zdHVyZSBhdHRyaWJ1dGVzIHZhbHVlcywgdGhpcyBjYXBhYmlsaXR5 IGlzCiAgICAgICAgIHVzZWQgdG8gYWNxdWlyZSB0aGlzIGRhdGEgZnJvbSBvbmUgb3IgbW9yZSBz ZWN1cml0eSBhdXRvbWF0aW9uCiAgICAgICAgIGRhdGEgc3RvcmVzLiAgRGVwZW5kaW5nIG9uIHRo ZSB0cmlnZ2VyLCB0aGUgc3BlY2lmaWMgZ3VpZGFuY2UKICAgICAgICAgdG8gYWNxdWlyZSBtaWdo dCBiZSBrbm93bi4gIElmIG5vdCwgaXQgbWF5IGJlIG5lY2Vzc2FyeSB0bwogICAgICAgICBkZXRl cm1pbmUgdGhlIGd1aWRhbmNlIHRvIHVzZSBiYXNlZCBvbiB0aGUgY29tcG9uZW50IGludmVudG9y eQogICAgICAgICBvciBvdGhlciBhc3Nlc3NtZW50IGNyaXRlcmlhLiAgVGhlIERhdGEgUXVlcnkg YW5kL29yIERhdGEKICAgICAgICAgUmV0cmlldmFsIGJ1aWxkaW5nIGJsb2NrcyAoc2VlIHNlY3Rp b24gMi4xLjEpIG1heSBiZSB1c2VkIHRvCiAgICAgICAgIGFjcXVpcmUgdGhpcyBndWlkYW5jZS4K CgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0ICAgICAg ICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnRFbnRlcnByaXNlIFVzZSBDYXNlcyBm b3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0CgoKICAgUG9zdHVyZSBBdHRyaWJ1 dGUgVmFsdWUgQ29sbGVjdGlvbjogIFRoZSBhY2N1bXVsYXRpb24gb2YgcG9zdHVyZQogICAgICAg ICBhdHRyaWJ1dGUgdmFsdWVzLiAgVGhpcyBtYXkgYmUgYmFzZWQgb24gY29sbGVjdGlvbiBndWlk YW5jZQogICAgICAgICB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcG9zdHVyZSBhdHRyaWJ1 dGVzLgoKICAgT25jZSB0aGUgcG9zdHVyZSBhdHRyaWJ1dGUgdmFsdWVzIGFyZSBjb2xsZWN0ZWQs IHRoZXkgbWF5IGJlCiAgIHBlcnNpc3RlZCBmb3IgbGF0ZXIgdXNlIG9yIHRoZXkgbWF5IGJlIGlt bWVkaWF0ZWx5IHVzZWQgZm9yIHBvc3R1cmUKICAgZXZhbHVhdGlvbi4KCjIuMS40LiAgUG9zdHVy ZSBFdmFsdWF0aW9uCgogICBUaGlzIHVzZSBjYXNlIGRlc2NyaWJlcyB0aGUgcHJvY2VzcyBvZiBl dmFsdWF0aW5nIGNvbGxlY3RlZCBwb3N0dXJlCiAgIGF0dHJpYnV0ZSB2YWx1ZXMgcmVwcmVzZW50 aW5nIGFjdHVhbCBlbmRwb2ludCBzdGF0ZSBhZ2FpbnN0IHRoZQogICBleHBlY3RlZCBzdGF0ZSBz ZWxlY3RlZCBmb3IgdGhlIGFzc2Vzc21lbnQuICBUaGlzIHVzZSBjYXNlIGNhbiBiZQogICBpbml0 aWF0ZWQgYnkgYSB2YXJpZXR5IG9mIHRyaWdnZXJzIGluY2x1ZGluZzoKCiAgIDEuICBBIHBvc3R1 cmUgY2hhbmdlIG9yIHNpZ25pZmljYW50IGV2ZW50IG9uIHRoZSBlbmRwb2ludC4KCiAgIDIuICBB IG5ldHdvcmsgZXZlbnQgKGUuZy4sIGVuZHBvaW50IGNvbm5lY3RzIHRvIGEgbmV0d29yay9WUE4s CiAgICAgICBzcGVjaWZpYyBuZXRmbG93IGlzIGRldGVjdGVkKS4KCiAgIDMuICBEdWUgdG8gYSBz Y2hlZHVsZWQgb3IgYWQgaG9jIGV2YWx1YXRpb24gdGFzay4KCiAgIFRoZSBidWlsZGluZyBibG9j a3Mgb2YgdGhpcyB1c2UgY2FzZSBhcmU6CgogICBQb3N0dXJlIEF0dHJpYnV0ZSBWYWx1ZSBRdWVy eTogIElmIHByZXZpb3VzbHkgY29sbGVjdGVkIHBvc3R1cmUKICAgICAgICAgYXR0cmlidXRlIHZh bHVlcyBhcmUgbmVlZGVkLCB0aGUgYXBwcm9wcmlhdGUgZGF0YSBzdG9yZXMgYXJlCiAgICAgICAg IHF1ZXJpZWQgdG8gcmV0cmlldmUgdGhlbS4gIElmIGFsbCBwb3N0dXJlIGF0dHJpYnV0ZSB2YWx1 ZXMgYXJlCiAgICAgICAgIHByb3ZpZGVkIGRpcmVjdGx5IGZvciBldmFsdWF0aW9uLCB0aGVuIHRo aXMgY2FwYWJpbGl0eSBtYXkgbm90CiAgICAgICAgIGJlIG5lZWRlZC4KCiAgIEV2YWx1YXRpb24g R3VpZGFuY2UgQWNxdWlzaXRpb246ICBJZiBndWlkYW5jZSBpcyByZXF1aXJlZCB0byBkcml2ZQog ICAgICAgICB0aGUgZXZhbHVhdGlvbiBvZiBwb3N0dXJlIGF0dHJpYnV0ZXMgdmFsdWVzLCB0aGlz IGNhcGFiaWxpdHkgaXMKICAgICAgICAgdXNlZCB0byBhY3F1aXJlIHRoaXMgZGF0YSBmcm9tIG9u ZSBvciBtb3JlIHNlY3VyaXR5IGF1dG9tYXRpb24KICAgICAgICAgZGF0YSBzdG9yZXMuICBEZXBl bmRpbmcgb24gdGhlIHRyaWdnZXIsIHRoZSBzcGVjaWZpYyBndWlkYW5jZQogICAgICAgICB0byBh Y3F1aXJlIG1pZ2h0IGJlIGtub3duLiAgSWYgbm90LCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRvCiAg ICAgICAgIGRldGVybWluZSB0aGUgZ3VpZGFuY2UgdG8gdXNlIGJhc2VkIG9uIHRoZSBjb21wb25l bnQgaW52ZW50b3J5CiAgICAgICAgIG9yIG90aGVyIGFzc2Vzc21lbnQgY3JpdGVyaWEuICBUaGUg RGF0YSBRdWVyeSBhbmQvb3IgRGF0YQogICAgICAgICBSZXRyaWV2YWwgYnVpbGRpbmcgYmxvY2tz IChzZWUgc2VjdGlvbiAyLjEuMSkgbWF5IGJlIHVzZWQgdG8KICAgICAgICAgYWNxdWlyZSB0aGlz IGd1aWRhbmNlLgoKICAgUG9zdHVyZSBBdHRyaWJ1dGUgRXZhbHVhdGlvbjogIFRoZSBjb21wYXJp c29uIG9mIHBvc3R1cmUgYXR0cmlidXRlCiAgICAgICAgIHZhbHVlcyBhZ2FpbnN0IHRoZWlyIGV4 cGVjdGVkIHJlc3VsdHMgYXMgZXhwcmVzc2VkIGluIHRoZQogICAgICAgICBzcGVjaWZpZWQgZ3Vp ZGFuY2UuICBUaGUgcmVzdWx0IG9mIHRoaXMgY29tcGFyaXNvbiBpcyBvdXRwdXQgYXMKICAgICAg ICAgYSBzZXQgb2YgcG9zdHVyZSBldmFsdWF0aW9uIHJlc3VsdHMuCgogICAgICAgICBRVUVTVElP TjogV2hhdCBpZiBkYXRhIGlzIHVuYXZhaWxhYmxlIG9yIGlzIG5vdCBjdXJyZW50IGVub3VnaAog ICAgICAgICB0byBzdXBwb3J0IHRoZSBldmFsdWF0aW9uPyAgVGhpcyBjb3VsZCBiZSBjYXVzZWQg aWYgY29sbGVjdGlvbgoKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMgQXVndXN0 IDE5LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnRFbnRlcnBy aXNlIFVzZSBDYXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0CgoKICAg ICAgICAgZGlkIG5vdCBvY2N1ciAoZm9yIHNvbWUgcmVhc29uKSBhbmQgcHJldmlvdXMgY29sbGVj dGlvbiB3YXMgdG9vCiAgICAgICAgIG9sZC4KCiAgIENvbXBsZXRpb24gb2YgdGhpcyBwcm9jZXNz IHJlcHJlc2VudHMgYSBjb21wbGV0ZSBhc3Nlc3NtZW50IGN5Y2xlIGFzCiAgIGRlZmluZWQgaW4g U2VjdGlvbiAyLgoKICAgUVVFU1RJT046IFNpbmNlIHRoaXMgaW5kaWNhdGVzIGNvbXBsZXRpb24g b2YgdGhlIHNlY3Rpb24gMiBwcm9jZXNzLCBJCiAgIHdvdWxkIGV4cGVjdCBzZWN0aW9uIDMgdG8g Zm9sbG93LiAgQnV0IHNlY3Rpb24gY29udGludWVzIHdpdGggMi4xLjU/CgoyLjEuNS4gIE1pbmlu ZyB0aGUgRGF0YWJhc2UKCiAgIFRoaXMgdXNlIGNhc2UgZGVzY3JpYmVzIHRoZSBuZWVkIHRvIGFu YWx5emUgcHJldmlvdXNseSBjb2xsZWN0ZWQKICAgcG9zdHVyZSBhdHRyaWJ1dGUgdmFsdWVzIGZy b20gb25lIG9yIG1vcmUgZW5kcG9pbnRzLiAgVGhpcyBpcyBhbgogICBhbHRlcm5hdGUgdXNlIGNh c2UgdG8gUG9zdHVyZSBFdmFsdWF0aW9uIChzZWUgc2VjdGlvbiAyLjEuNCkgdGhhdAogICB1c2Vz IGNvbGxlY3RlZCBwb3N0dXJlIGF0dHJpYnV0ZXMgdmFsdWVzIGZvciBhbmFseXNpcyBwcm9jZXNz ZXMgdGhhdAogICBtYXkgZG8gbW9yZSB0aGFuIGV2YWx1YXRpbmcgZXhwZWN0ZWQgdnMuICBhY3R1 YWwgc3RhdGUocykuCgogICBUaGUgYnVpbGRpbmcgYmxvY2tzIG9mIHRoaXMgdXNlIGNhc2UgYXJl OgoKICAgUXVlcnk6ICBRdWVyeSBhIGRhdGEgc3RvcmUgZm9yIHNwZWNpZmljIHBvc3R1cmUgYXR0 cmlidXRlIHZhbHVlcy4KCiAgIENoYW5nZSBEZXRlY3Rpb246ICBBbiBvcGVyYXRvciBzaG91bGQg aGF2ZSBhIG1lY2hhbmlzbSB0byBkZXRlY3QgdGhlCiAgICAgICAgIGF2YWlsYWJpbGl0eSBvZiBu ZXcgb3IgY2hhbmdlcyB0byBleGlzdGluZyBwb3N0dXJlIGF0dHJpYnV0ZQogICAgICAgICB2YWx1 ZXMuICBUaGUgdGltZWxpbmVzcyBvZiBkZXRlY3Rpb24gbWF5IHZhcnkgZnJvbSBpbW1lZGlhdGUg dG8KICAgICAgICAgb24gZGVtYW5kLiAgSGF2aW5nIHRoZSBhYmlsaXR5IHRvIGZpbHRlciB3aGF0 IGNoYW5nZXMgYXJlCiAgICAgICAgIGRldGVjdGVkIHdpbGwgYWxsb3cgdGhlIG9wZXJhdG9yIHRv IGZvY3VzIG9uIHRoZSBjaGFuZ2VzIHRoYXQKICAgICAgICAgYXJlIHJlbGV2YW50IHRvIHRoZWly IHVzZS4KCiAgIFFVRVNUSU9OOiBEb2VzIHRoaXMgd2FycmFudCBhIHNlcGFyYXRlIHVzZSBjYXNl LCBvciBzaG91bGQgdGhpcyBiZQogICBpbmNvcnBvcmF0ZWQgaW50byB0aGUgcHJldmlvdXMgdXNl IGNhc2U/CgogICBDT01NRU5UKERCSCk6IEkgdGhpbmsgdGhlIDIuMS41IHVzZSBjYXNlIGlzIGEg c3Vic2V0IG9mIDIuMS40IHVzZQogICBjYXNlLCBzcGVjaWZpY2FsbHksIHRoZSBxdWVyeSBvZiBl eGlzdGluZyBkYXRhIGlzIGNvdmVyZWQgaW4gUG9zdHVyZQogICBBdHRyaWJ1dGUgVmFsdWUgUXVl cnksIGNvbmRpdGlvbiAxLiAgSSB0aGluayBQb3N0dXJlIEF0dHJpYnV0ZSBWYWx1ZQogICBRdWVy eSBzaG91bGQgYmUgbW9kaWZpZWQgdG8gaW5jbHVkZSB0aGUgY2hhbmdlIGRldGVjdGlvbiwgYXMg cGFydCBvZgogICBlc3RhYmxpc2hpbmcgd2hhdCBuZWVkcyB0byBiZSBxdWVyaWVkLgoKMi4yLiAg VXNhZ2UgU2NlbmFyaW9zCgogICBJbiB0aGlzIHNlY3Rpb24sIHdlIGRlc2NyaWJlIGEgbnVtYmVy IG9mIHVzYWdlIHNjZW5hcmlvcyB0aGF0IHV0aWxpemUKICAgYXNwZWN0cyBvZiBlbmRwb2ludCBw b3N0dXJlIGFzc2Vzc21lbnQuICBUaGVzZSBhcmUgZXhhbXBsZXMgb2YgY29tbW9uCiAgIHByb2Js ZW1zIHRoYXQgY2FuIGJlIHNvbHZlZCB3aXRoIHRoZSBidWlsZGluZyBibG9ja3MgZGVmaW5lZCBh Ym92ZS4KCiAgIENPTU1FTlQoREJIKTogSSBkb24ndCBzZWUgIlNlYXJjaCBmb3Igc2lnbnMgb2Yg SW5mZWN0aW9uIiwKICAgIlZ1bG5lcmFiaWxpdHkgRW5kcG9pbnQgSWRlbnRpZmljYXRpb24iLCAi Q29tcHJvbWlzZWQgRW5kcG9pbnQKICAgSWRlbnRpZmljYXRpb24iLCBhbmQgIlN1c3BpY2lvdXMg RW5kcG9pbnQgYmVoYXZpb3IiLCB3aGljaCB3ZXJlIGluCiAgIC0wNC0uIFRoZXkgd2VyZSBtb3Zl ZCBpbnRvICJBdXRvbWF0ZWQgQ2hlY2tsaXN0IFZlcmlmaWNhdGlvbiIuICBCdXQKICAgdGhlIG9y aWdpbmFsIHVzYWdlIHNjZW5hcmlvcyBkaWQgbm90IG1lbnRpb24gY2hlY2tsaXN0cy4gIEFyZSB3 ZSBub3cKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0 ICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnRFbnRlcnByaXNlIFVzZSBD YXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0CgoKICAgbGltaXRpbmcg U0FDTSB0byBhIGNoZWNrbGlzdC1kcml2ZW4gYXBwcm9hY2hlcz8gIERvIHRoZSBhdXRob3JzIG9m CiAgIHRoZSB0ZXh0IGluIC0wNC0gYWdyZWUgdGhhdCB0aGVpciB1c2UgY2FzZXMvdXNhZ2Ugc2Nl bmFyaW9zIGFyZQogICBhZGVxdWF0ZWx5IGNhcHR1cmVkIGluIC0wNS0/CgoyLjIuMS4gIERlZmlu aXRpb24gYW5kIFB1YmxpY2F0aW9uIG9mIEF1dG9tYXRhYmxlIENvbmZpZ3VyYXRpb24KICAgICAg ICBDaGVja2xpc3RzCgogICBBIHZlbmRvciBtYW51ZmFjdHVyZXMgYSBudW1iZXIgb2Ygc3BlY2lh bGl6ZWQgZW5kcG9pbnQgZGV2aWNlcy4gIFRoZXkKICAgYWxzbyBkZXZlbG9wIGFuZCBtYWludGFp biBhbiBvcGVyYXRpbmcgc3lzdGVtIGZvciB0aGVzZSBkZXZpY2VzIHRoYXQKICAgZW5hYmxlcyBl bmQtdXNlciBvcmdhbml6YXRpb25zIHRvIGNvbmZpZ3VyZSBhIG51bWJlciBvZiBzZWN1cml0eSBh bmQKICAgb3BlcmF0aW9uYWwgc2V0dGluZ3MuICBBcyBwYXJ0IG9mIHRoZWlyIGN1c3RvbWVyIHN1 cHBvcnQgYWN0aXZpdGllcywKICAgdGhleSBwdWJsaXNoIGEgbnVtYmVyIG9mIHNlY3VyZSBjb25m aWd1cmF0aW9uIGd1aWRlcyB0aGF0IHByb3ZpZGUKICAgbWluaW11bSBzZWN1cml0eSBndWlkZWxp bmVzIGZvciBjb25maWd1cmluZyB0aGVpciBkZXZpY2VzLgoKICAgRWFjaCBndWlkZSB0aGV5IHBy b2R1Y2UgYXBwbGllcyB0byBhIHNwZWNpZmljIG1vZGVsIG9mIGRldmljZSBhbmQKICAgdmVyc2lv biBvZiB0aGUgb3BlcmF0aW5nIHN5c3RlbSBhbmQgcHJvdmlkZXMgYSBudW1iZXIgb2Ygc3BlY2lh bGl6ZWQKICAgY29uZmlndXJhdGlvbnMgZGVwZW5kaW5nIG9uIHRoZSBkZXZpY2VzIGludGVuZGVk IGZ1bmN0aW9uIGFuZCB3aGF0CiAgIGFkZC1vbiBoYXJkd2FyZSBtb2R1bGVzIGFuZCBzb2Z0d2Fy ZSBsaWNlbnNlcyBhcmUgaW5zdGFsbGVkIG9uIHRoZQogICBkZXZpY2UuICBUbyBlbmFibGUgdGhl aXIgY3VzdG9tZXJzIHRvIGV2YWx1YXRlIHRoZSBzZWN1cml0eSBwb3N0dXJlCiAgIG9mIHRoZWly IGRldmljZXMgdG8gZW5zdXJlIHRoYXQgYWxsIGFwcHJvcHJpYXRlIG1pbmltYWwgc2VjdXJpdHkK ICAgc2V0dGluZ3MgYXJlIGVuYWJsZWQsIHRoZXkgcHVibGlzaCBhbiBhdXRvbWF0YWJsZSBjb25m aWd1cmF0aW9uCiAgIGNoZWNrbGlzdHMgdXNpbmcgYSBwb3B1bGFyIGRhdGEgZm9ybWF0IHRoYXQg ZGVmaW5lcyB3aGF0IHNldHRpbmdzIHRvCiAgIGNvbGxlY3QgdXNpbmcgYSBuZXR3b3JrIG1hbmFn ZW1lbnQgcHJvdG9jb2wgYW5kIGFwcHJvcHJpYXRlIHZhbHVlcwogICBmb3IgZWFjaCBzZXR0aW5n LiAgVGhleSBwdWJsaXNoIHRoZXNlIGNoZWNrbGlzdCB0byBhIHB1YmxpYyBzZWN1cml0eQogICBh dXRvbWF0aW9uIGRhdGEgc3RvcmUgdGhhdCBjdXN0b21lcnMgY2FuIHF1ZXJ5IHRvIHJldHJpZXZl IGFwcGxpY2FibGUKICAgY2hlY2tsaXN0IGZvciB0aGVpciBkZXBsb3llZCBzcGVjaWFsaXplZCBl bmRwb2ludCBkZXZpY2VzLgoKICAgQXV0b21hdGFibGUgY29uZmlndXJhdGlvbiBjaGVja2xpc3Qg Y291bGQgYWxzbyBjb21lIGZyb20gc291cmNlcwogICBvdGhlciB0aGFuIGEgZGV2aWNlIHZlbmRv ciwgc3VjaCBhcyBpbmR1c3RyeSBncm91cHMgb3IgcmVndWxhdG9yeQogICBhdXRob3JpdGllcywg b3IgZW50ZXJwcmlzZXMgY291bGQgZGV2ZWxvcCB0aGVpciBvd24gY2hlY2tsaXN0cy4KCiAgIFRo aXMgdXNhZ2Ugc2NlbmFyaW8gZW1wbG95cyB0aGUgZm9sbG93aW5nIGJ1aWxkaW5nIGJsb2NrcyBk ZWZpbmVkIGluCiAgIFNlY3Rpb24gMi4xLjEgYWJvdmU6CgogICBEYXRhIERlZmluaXRpb246ICBU byBhbGxvdyBndWlkYW5jZSB0byBiZSBkZWZpbmVkIHVzaW5nIHN0YW5kYXJkaXplZAogICAgICAg ICBvciBwcm9wcmlldGFyeSBkYXRhIG1vZGVscyB0aGF0IHdpbGwgZHJpdmUgQ29sbGVjdGlvbiBh bmQKICAgICAgICAgRXZhbHVhdGlvbi4KCiAgIERhdGEgUHVibGljYXRpb246ICBQcm92aWRpbmcg YSBtZWNoYW5pc20gdG8gcHVibGlzaCBjcmVhdGVkIGd1aWRhbmNlCiAgICAgICAgIHRvIGEgc2Vj dXJpdHkgYXV0b21hdGlvbiBkYXRhIHN0b3JlLgoKICAgRGF0YSBRdWVyeTogIFRvIGxvY2F0ZSBh bmQgc2VsZWN0IGV4aXN0aW5nIGd1aWRhbmNlIHRoYXQgbWF5IGJlCiAgICAgICAgIHJldXNlZC4K CiAgIERhdGEgUmV0cmlldmFsICBUbyByZXRyaWV2ZSBzcGVjaWZpYyBndWlkYW5jZSBmcm9tIGEg c2VjdXJpdHkKICAgICAgICAgYXV0b21hdGlvbiBkYXRhIHN0b3JlIGZvciBlZGl0aW5nLgoKCgoK CldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAg ICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9y IFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVhcnkgMjAxNAoKCiAgIFdoaWxlIGVhY2ggYnVpbGRp bmcgYmxvY2sgY2FuIGJlIHVzZWQgaW4gYSBtYW51YWwgZmFzaGlvbiBieSBhIGh1bWFuCiAgIG9w ZXJhdG9yLCBpdCBpcyBhbHNvIGxpa2VseSB0aGF0IHRoZXNlIGNhcGFiaWxpdGllcyB3aWxsIGJl CiAgIGltcGxlbWVudGVkIHRvZ2V0aGVyIGluIHNvbWUgZm9ybSBvZiBhIGd1aWRhbmNlIGVkaXRv ciBvciBnZW5lcmF0b3IKICAgYXBwbGljYXRpb24uCgoyLjIuMi4gIEF1dG9tYXRlZCBDaGVja2xp c3QgVmVyaWZpY2F0aW9uCgogICBBIGZpbmFuY2lhbCBzZXJ2aWNlcyBjb21wYW55IG9wZXJhdGVz IGEgaGV0ZXJvZ2VuZW91cyBJVCBlbnZpcm9ubWVudC4KICAgSW4gc3VwcG9ydCBvZiB0aGVpciBy aXNrIG1hbmFnZW1lbnQgcHJvZ3JhbSwgdGhleSB1dGlsaXplIHZlbmRvcgogICBwcm92aWRlZCBh dXRvbWF0YWJsZSBzZWN1cml0eSBjb25maWd1cmF0aW9uIGNoZWNrbGlzdHMgZm9yIGVhY2gKICAg b3BlcmF0aW5nIHN5c3RlbSBhbmQgYXBwbGljYXRpb24gdXNlZCB3aXRoaW4gdGhlaXIgSVQgZW52 aXJvbm1lbnQuCiAgIE11bHRpcGxlIGNoZWNrbGlzdHMgYXJlIHVzZWQgZnJvbSBkaWZmZXJlbnQg dmVuZG9ycyB0byBpbnN1cmUKICAgYWRlcXVhdGUgY292ZXJhZ2Ugb2YgYWxsIElUIGFzc2V0cy4K CiAgIFRvIGlkZW50aWZ5IHdoYXQgY2hlY2tsaXN0cyBhcmUgbmVlZGVkLCB0aGV5IHVzZSBhdXRv bWF0aW9uIHRvIGdhdGhlcgogICBhbiBpbnZlbnRvcnkgb2YgdGhlIHNvZnR3YXJlIHZlcnNpb25z IHV0aWxpemVkIGJ5IGFsbCBJVCBhc3NldHMgaW4KICAgdGhlIGVudGVycHJpc2UuICBUaGlzIGRh dGEgZ2F0aGVyaW5nIHdpbGwgaW52b2x2ZSBxdWVyeWluZyBleGlzdGluZwogICBkYXRhIHN0b3Jl cyBvZiBwcmV2aW91c2x5IGNvbGxlY3RlZCBlbmRwb2ludCBzb2Z0d2FyZSBpbnZlbnRvcnkKICAg cG9zdHVyZSBkYXRhIGFuZCBhY3RpdmVseSBjb2xsZWN0aW5nIGRhdGEgZnJvbSByZWFjaGFibGUg ZW5kcG9pbnRzIGFzCiAgIG5lZWRlZCB1dGlsaXppbmcgbmV0d29yayBhbmQgc3lzdGVtcyBtYW5h Z2VtZW50IHByb3RvY29scy4KICAgUHJldmlvdXNseSBjb2xsZWN0ZWQgZGF0YSBtYXkgYmUgcHJv dmlkZWQgYnkgcGVyaW9kaWMgZGF0YQogICBjb2xsZWN0aW9uLCBuZXR3b3JrIGNvbm5lY3Rpb24t ZHJpdmVuIGRhdGEgY29sbGVjdGlvbiwgb3Igb25nb2luZwogICBldmVudC1kcml2ZW4gbW9uaXRv cmluZyBvZiBlbmRwb2ludCBwb3N0dXJlIGNoYW5nZXMuCgogICBVc2luZyB0aGUgY29sbGVjdGVk IGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSBpbnZlbnRvcnkgZGF0YSBhbmQKICAgYXNzb2NpYXRlZCBh c3NldCBjaGFyYWN0ZXJpemF0aW9uIGRhdGEgdGhhdCBtYXkgaW5kaWNhdGUgdGhlCiAgIG9yZ2Fu aXphdGlvbmFsIGRlZmluZWQgZnVuY3Rpb25zIG9mIGVhY2ggZW5kcG9pbnQsIGNoZWNrbGlzdCBn dWlkYW5jZQogICBpcyBxdWVyaWVkLCBsb2NhdGVkIGFuZCBkb3dubG9hZGVkIGZyb20gdGhlIGFw cHJvcHJpYXRlIHZlbmRvciBhbmQKICAgM3JkLXBhcnR5IHNlY3VyaXR5IGF1dG9tYXRpb24gZGF0 YSBzdG9yZSBmb3IgdGhlIGFwcHJvcHJpYXRlCiAgIGNoZWNrbGlzdHMuICBUaGlzIGd1aWRhbmNl IGlzIGNhY2hlZCBsb2NhbGx5IHRvIHJlZHVjZSB0aGUgbmVlZCB0bwogICByZXRyaWV2ZSB0aGUg ZGF0YSBtdWx0aXBsZSB0aW1lcy4KCiAgIERyaXZlbiBieSB0aGUgc2V0dGluZyBkYXRhIHByb3Zp ZGVkIGluIHRoZSBjaGVja2xpc3QsIGEgY29tYmluYXRpb24KICAgb2YgZXhpc3RpbmcgY29uZmln dXJhdGlvbiBkYXRhIHN0b3JlcyBhbmQgZGF0YSBjb2xsZWN0aW9uIG1ldGhvZHMgYXJlCiAgIHVz ZWQgdG8gZ2F0aGVyIHRoZSBhcHByb3ByaWF0ZSBwb3N0dXJlIGF0dHJpYnV0ZXMgZnJvbSAob3Ig cGVydGFpbmluZwogICB0bykgZWFjaCBlbmRwb2ludC4gIFNwZWNpZmljIHBvc3R1cmUgYXR0cmli dXRlIHZhbHVlcyBhcmUgZ2F0aGVyZWQKICAgYmFzZWQgb24gdGhlIGRlZmluZWQgZW50ZXJwcmlz ZSBmdW5jdGlvbiBhbmQgc29mdHdhcmUgaW52ZW50b3J5IG9mCiAgIGVhY2ggZW5kcG9pbnQuICBU aGUgY29sbGVjdGlvbiBtZWNoYW5pc21zIHVzZWQgdG8gY29sbGVjdCBzb2Z0d2FyZQogICBpbnZl bnRvcnkgcG9zdHVyZSB3aWxsIGJlIHVzZWQgYWdhaW4gZm9yIHRoaXMgcHVycG9zZS4gIE9uY2Ug dGhlIGRhdGEKICAgaXMgZ2F0aGVyZWQsIHRoZSBhY3R1YWwgc3RhdGUgaXMgZXZhbHVhdGVkIGFn YWluc3QgdGhlIGV4cGVjdGVkIHN0YXRlCiAgIGNyaXRlcmlhIGRlZmluZWQgaW4gZWFjaCBhcHBs aWNhYmxlIGNoZWNrbGlzdC4gIFRoZSByZXN1bHRzIG9mIHRoaXMKICAgZXZhbHVhdGlvbiBhcmUg cHJvdmlkZWQgdG8gYXBwcm9wcmlhdGUgb3BlcmF0b3JzIGFuZCBhcHBsaWNhdGlvbnMgdG8KICAg ZHJpdmUgYWRkaXRpb25hbCBidXNpbmVzcyBsb2dpYy4KCiAgIENoZWNrbGlzdHMgY291bGQgaW5j bHVkZSBzZWFyY2hpbmcgZm9yIGluZGljYXRvcnMgb2YgY29tcHJvbWlzZSBvbgogICB0aGUgZW5k cG9pbnQgKGUuZy4sIGZpbGUgaGFzaGVzKTsgaWRlbnRpZnlpbmcgbWFsaWNpb3VzIGFjdGl2aXR5 CiAgIChlLmcuIGNvbW1hbmQgYW5kIGNvbnRyb2wgdHJhZmZpYyk7IGRldGVjdGluZyBwcmVzZW5j ZSBvZgoKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0 ICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnRFbnRlcnByaXNlIFVzZSBD YXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0CgoKICAgdW5hdXRob3Jp emVkL21hbGljaW91cyBzb2Z0d2FyZSwgaGFyZHdhcmUsIGFuZCBjb25maWd1cmF0aW9uIGl0ZW1z OwogICBhbmQgb3RoZXIgaW5kaWNhdG9ycy4KCiAgIEEgY2hlY2tsaXN0IGNhbiBiZSBhc3Nlc3Nl ZCBhcyBhIHdob2xlLCBvciBhIHNwZWNpZmljIHN1YnNldCBvZiB0aGUKICAgY2hlY2tsaXN0IGNh biBiZSBhc3Nlc3NlZCByZXN1bHRpbmcgaW4gcGFydGlhbCBkYXRhIGNvbGxlY3Rpb24gYW5kCiAg IGV2YWx1YXRpb24uCgogICBDaGVja2xpc3RzIGNvdWxkIGFsc28gY29tZSBmcm9tIHNvdXJjZXMg b3RoZXIgdGhhbiB0aGUgYXBwbGljYXRpb24gb3IKICAgT1MgdmVuZG9yLCBzdWNoIGFzIGluZHVz dHJ5IGdyb3VwcyBvciByZWd1bGF0b3J5IGF1dGhvcml0aWVzLCBvcgogICBlbnRlcnByaXNlcyBj b3VsZCBkZXZlbG9wIHRoZWlyIG93biBjaGVja2xpc3RzLgoKICAgV2hpbGUgc3BlY2lmaWMgYXBw bGljYXRpb25zIGZvciBjaGVja2xpc3RzIHJlc3VsdHMgYXJlIG91dC1vZi1zY29wZQogICBmb3Ig Y3VycmVudCBTQUNNIGVmZm9ydHMsIGhvdyB0aGUgZGF0YSBpcyB1c2VkIG1heSBpbGx1bWluYXRl CiAgIHNwZWNpZmljIGxhdGVuY3kgYW5kIGJhbmR3aWR0aCByZXF1aXJlbWVudHMuICBGb3IgdGhp cyBwdXJwb3NlIHVzZSBvZgogICBjaGVja2xpc3QgYXNzZXNzbWVudCByZXN1bHRzIG1heSBpbmNs dWRlLCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOgoKICAgbyAgRGV0ZWN0aW5nIGVuZHBvaW50IHBv c3R1cmUgZGV2aWF0aW9ucyBhcyBwYXJ0IG9mIGEgY2hhbmdlCiAgICAgIG1hbmFnZW1lbnQgcHJv Z3JhbSB0byBpbmNsdWRlIGNoYW5nZXMgdG8gaGFyZHdhcmUgYW5kIHNvZnR3YXJlCiAgICAgIGlu dmVudG9yeSBpbmNsdWRpbmcgcGF0Y2hlcywgY2hhbmdlcyB0byBjb25maWd1cmF0aW9uIGl0ZW1z LCBhbmQKICAgICAgb3RoZXIgcG9zdHVyZSBhc3BlY3RzLgoKICAgbyAgRGV0ZXJtaW5pbmcgY29t cGxpYW5jZSB3aXRoIG9yZ2FuaXphdGlvbmFsIHBvbGljaWVzIGdvdmVybmluZwogICAgICBlbmRw b2ludCBwb3N0dXJlLgoKICAgbyAgU2VhcmNoaW5nIGZvciBjdXJyZW50IGFuZCBoaXN0b3JpYyBz aWducyBvZiBpbmZlY3Rpb24gYnkgbWFsd2FyZQogICAgICBhbmQgZGV0ZXJtaW5pbmcgdGhlIHNj b3BlIG9mIGluZmVjdGlvbiB3aXRoaW4gYW4gZW50ZXJwcmlzZS4KCiAgIG8gIEluZm9ybWluZyBj b25maWd1cmF0aW9uIG1hbmFnZW1lbnQsIHBhdGNoIG1hbmFnZW1lbnQsIGFuZAogICAgICB2dWxu ZXJhYmlsaXR5IG1pdGlnYXRpb24gYW5kIHJlbWVkaWF0aW9uIGRlY2lzaW9ucy4KCiAgIG8gIERl dGVjdGluZyBwZXJmb3JtYW5jZSwgYXR0YWNrIGFuZCB2dWxuZXJhYmxlIGNvbmRpdGlvbnMgdGhh dAogICAgICB3YXJyYW50IGFkZGl0aW9uYWwgbmV0d29yayBkaWFnbm9zdGljcywgbW9uaXRvcmlu ZywgYW5kIGFuYWx5c2lzLgoKICAgbyAgSW5mb3JtaW5nIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wg ZGVjaXNpb24gbWFraW5nIGZvciB3aXJlZCwKICAgICAgd2lyZWxlc3MsIG9yIFZQTiBjb25uZWN0 aW9ucy4KCiAgIFRoaXMgdXNhZ2Ugc2NlbmFyaW8gZW1wbG95cyB0aGUgZm9sbG93aW5nIGJ1aWxk aW5nIGJsb2NrcyBkZWZpbmVkIGluCiAgIFNlY3Rpb24gMi4xLjEgYWJvdmU6CgogICBFbmRwb2lu dCBEaXNjb3Zlcnk6ICBUaGUgcHVycG9zZSBvZiBkaXNjb3ZlcnkgaXMgdG8gZGV0ZXJtaW5lIHRo ZQogICAgICAgICB0eXBlIG9mIGVuZHBvaW50IHRvIGJlIHBvc3R1cmUgYXNzZXNzZWQuCgogICBJ ZGVudGlmeSBFbmRwb2ludCBUYXJnZXRzOiAgVG8gaWRlbnRpZnkgd2hhdCBwb3RlbnRpYWwgZW5k cG9pbnQKICAgICAgICAgdGFyZ2V0cyB0aGUgY2hlY2tsaXN0IHNob3VsZCBhcHBseSB0byBiYXNl ZCBvbiBvcmdhbml6YXRpb25hbAogICAgICAgICBwb2xpY2llcy4KCiAgIEVuZHBvaW50IENvbXBv bmVudCBJbnZlbnRvcnk6ICBDb2xsZWN0aW5nIGFuZCBjb25zdW1pbmcgdGhlIHNvZnR3YXJlCiAg ICAgICAgIGFuZCBoYXJkd2FyZSBpbnZlbnRvcnkgZm9yIHRoZSB0YXJnZXQgZW5kcG9pbnRzLgoK CgpXYWx0ZXJtaXJlICYgSGFycmluZ3RvbiAgRXhwaXJlcyBBdWd1c3QgMTksIDIwMTQgICAgICAg ICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdEVudGVycHJpc2UgVXNlIENhc2VzIGZv ciBTZWN1cml0eSBBc3Nlc3NtZW50IEZlYnJ1YXJ5IDIwMTQKCgogICBQb3N0dXJlIEF0dHJpYnV0 ZSBJZGVudGlmaWNhdGlvbjogIFRvIGRldGVybWluZSB3aGF0IGRhdGEgbmVlZHMgdG8gYmUKICAg ICAgICAgY29sbGVjdGVkIHRvIHN1cHBvcnQgZXZhbHVhdGlvbiwgdGhlIGNoZWNrbGlzdCBpcyBl dmFsdWF0ZWQKICAgICAgICAgYWdhaW5zdCB0aGUgY29tcG9uZW50IGludmVudG9yeSBhbmQgb3Ro ZXIgZW5kcG9pbnQgbWV0YWRhdGEgdG8KICAgICAgICAgZGV0ZXJtaW5lIHRoZSBzZXQgb2YgcG9z dHVyZSBhdHRyaWJ1dGUgdmFsdWVzIHRoYXQgYXJlIG5lZWRlZC4KCiAgIENvbGxlY3Rpb24gR3Vp ZGFuY2UgQWNxdWlzaXRpb246ICBCYXNlZCBvbiB0aGUgaWRlbnRpZmllZCBwb3N0dXJlCiAgICAg ICAgIGF0dHJpYnV0ZXMsIHRoZSBhcHBsaWNhdGlvbiB3aWxsIHF1ZXJ5IGFwcHJvcHJpYXRlIHNl Y3VyaXR5CiAgICAgICAgIGF1dG9tYXRpb24gZGF0YSBzdG9yZXMgdG8gZmluZCB0aGUgImFwcGxp Y2FibGUiIGNvbGxlY3Rpb24KICAgICAgICAgZ3VpZGFuY2UgZm9yIGVhY2ggZW5kcG9pbnQgaW4g cXVlc3Rpb24uCgogICBQb3N0dXJlIEF0dHJpYnV0ZSBWYWx1ZSBDb2xsZWN0aW9uOiAgRm9yIGVh Y2ggZW5kcG9pbnQsIHRoZSB2YWx1ZXMKICAgICAgICAgZm9yIHRoZSByZXF1aXJlZCBwb3N0dXJl IGF0dHJpYnV0ZXMgYXJlIGNvbGxlY3RlZC4KCiAgIFBvc3R1cmUgQXR0cmlidXRlIFZhbHVlIFF1 ZXJ5OiAgSWYgcHJldmlvdXNseSBjb2xsZWN0ZWQgcG9zdHVyZQogICAgICAgICBhdHRyaWJ1dGUg dmFsdWVzIGFyZSB1c2VkLCB0aGV5IGFyZSBxdWVyaWVkIGZyb20gdGhlCiAgICAgICAgIGFwcHJv cHJpYXRlIGRhdGEgc3RvcmVzIGZvciB0aGUgdGFyZ2V0IGVuZHBvaW50KHMpLgoKICAgRXZhbHVh dGlvbiBHdWlkYW5jZSBBY3F1aXNpdGlvbjogIEFueSBndWlkYW5jZSB0aGF0IGlzIG5lZWRlZCB0 bwogICAgICAgICBzdXBwb3J0IGV2YWx1YXRpb24gaXMgcXVlcmllZCBhbmQgcmV0cmlldmVkLgoK ICAgUG9zdHVyZSBBdHRyaWJ1dGUgRXZhbHVhdGlvbjogIFRoZSByZXN1bHRpbmcgcG9zdHVyZSBh dHRyaWJ1dGUgdmFsdWVzCiAgICAgICAgIGZyb20gcHJldmlvdXMgQ29sbGVjdGlvbiBwcm9jZXNz ZXMgYXJlIGV2YWx1YXRlZCB1c2luZyB0aGUKICAgICAgICAgZXZhbHVhdGlvbiBndWlkYW5jZSB0 byBwcm92aWRlIGEgc2V0IG9mIHBvc3R1cmUgcmVzdWx0cy4KCjIuMi4zLiAgRGV0ZWN0aW9uIG9m IFBvc3R1cmUgRGV2aWF0aW9ucwoKICAgRXhhbXBsZSBjb3Jwb3JhdGlvbiBoYXMgZXN0YWJsaXNo ZWQgc2VjdXJlIGNvbmZpZ3VyYXRpb24gYmFzZWxpbmVzCiAgIGZvciBlYWNoIGRpZmZlcmVudCB0 eXBlIG9mIGVuZHBvaW50IHdpdGhpbiB0aGVpciBlbnRlcnByaXNlCiAgIGluY2x1ZGluZzogbmV0 d29yayBpbmZyYXN0cnVjdHVyZSwgbW9iaWxlLCBjbGllbnQsIGFuZCBzZXJ2ZXIKICAgY29tcHV0 aW5nIHBsYXRmb3Jtcy4gIFRoZXNlIGJhc2VsaW5lcyBkZWZpbmUgYW4gYXBwcm92ZWQgbGlzdCBv ZgogICBoYXJkd2FyZSwgc29mdHdhcmUgKGkuZS4sIG9wZXJhdGluZyBzeXN0ZW0sIGFwcGxpY2F0 aW9ucywgYW5kCiAgIHBhdGNoZXMpLCBhbmQgYXNzb2NpYXRlZCByZXF1aXJlZCBjb25maWd1cmF0 aW9ucy4gIFdoZW4gYW4gZW5kcG9pbnQKICAgY29ubmVjdHMgdG8gdGhlIG5ldHdvcmssIHRoZSBh cHByb3ByaWF0ZSBiYXNlbGluZSBjb25maWd1cmF0aW9uIGlzCiAgIGNvbW11bmljYXRlZCB0byB0 aGUgZW5kcG9pbnQgYmFzZWQgb24gaXRzIGxvY2F0aW9uIGluIHRoZSBuZXR3b3JrLAogICB0aGUg ZXhwZWN0ZWQgZnVuY3Rpb24gb2YgdGhlIGRldmljZSwgYW5kIG90aGVyIGFzc2V0IG1hbmFnZW1l bnQgZGF0YS4KICAgSXQgaXMgY2hlY2tlZCBmb3IgY29tcGxpYW5jZSB3aXRoIHRoZSBiYXNlbGlu ZSBpbmRpY2F0aW5nIGFueQogICBkZXZpYXRpb25zIHRvIHRoZSBkZXZpY2UncyBvcGVyYXRvcnMu ICBPbmNlIHRoZSBiYXNlbGluZSBoYXMgYmVlbgogICBlc3RhYmxpc2hlZCwgdGhlIGVuZHBvaW50 IGlzIG1vbml0b3JlZCBmb3IgYW55IGNoYW5nZSBldmVudHMKICAgcGVydGFpbmluZyB0byB0aGUg YmFzZWxpbmUgb24gYW4gb25nb2luZyBiYXNpcy4gIFdoZW4gYSBjaGFuZ2Ugb2NjdXJzCiAgIHRv IHBvc3R1cmUgZGVmaW5lZCBpbiB0aGUgYmFzZWxpbmUsIHVwZGF0ZWQgcG9zdHVyZSBpbmZvcm1h dGlvbiBpcwogICBleGNoYW5nZWQgYWxsb3dpbmcgb3BlcmF0b3JzIHRvIGJlIG5vdGlmaWVkIGFu ZC9vciBhdXRvbWF0ZWQgYWN0aW9uCiAgIHRvIGJlIHRha2VuLgoKICAgTGlrZSB0aGUgQXV0b21h dGVkIENoZWNrbGlzdCBWZXJpZmljYXRpb24gdXNhZ2Ugc2NlbmFyaW8gKHNlZSBzZWN0aW9uCiAg IDIuMi4yKSwgdGhpcyB1c2FnZSBzY2VuYXJpbyBzdXBwb3J0cyBhc3Nlc3NtZW50IGJhc2VkIG9u IGF1dG9tYXRhYmxlCiAgIGNoZWNrbGlzdHMuICBJdCBkaWZmZXJzIGZyb20gdGhhdCBzY2VuYXJp byBieSBtb25pdG9yaW5nIGZvciBzcGVjaWZpYwogICBlbmRwb2ludCBwb3N0dXJlIGNoYW5nZXMg b24gYW4gb25nb2luZyBiYXNpcy4gIFdoZW4gdGhlIGVuZHBvaW50CiAgIGRldGVjdHMgYSBwb3N0 dXJlIGNoYW5nZSwgYW4gYWxlcnQgaXMgZ2VuZXJhdGVkIGlkZW50aWZ5aW5nIHRoZQoKCgpXYWx0 ZXJtaXJlICYgSGFycmluZ3RvbiAgRXhwaXJlcyBBdWd1c3QgMTksIDIwMTQgICAgICAgICAgICAg ICBbUGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdEVudGVycHJpc2UgVXNlIENhc2VzIGZvciBTZWN1 cml0eSBBc3Nlc3NtZW50IEZlYnJ1YXJ5IDIwMTQKCgogICBzcGVjaWZpYyBjaGFuZ2VzIGluIHBv c3R1cmUgYWxsb3dpbmcgYXNzZXNzbWVudCBvZiB0aGUgZGVsdGEgdG8gYmUKICAgcGVyZm9ybWVk IGluc3RlYWQgb2YgYSBmdWxsIGFzc2Vzc21lbnQgaW4gdGhlIHByZXZpb3VzIGNhc2UuICBUaGlz CiAgIHVzYWdlIHNjZW5hcmlvIGVtcGxveXMgdGhlIHNhbWUgYnVpbGRpbmcgYmxvY2tzIGFzCiAg IEF1dG9tYXRlZCBDaGVja2xpc3QgVmVyaWZpY2F0aW9uIChzZWUgc2VjdGlvbiAyLjIuMikuICBJ dCBkaWZmZXJzCiAgIHNsaWdodGx5IGluIGhvdyBpdCB1c2VzIHRoZSBmb2xsb3dpbmcgYnVpbGRp bmcgYmxvY2tzOgoKICAgRW5kcG9pbnQgQ29tcG9uZW50IEludmVudG9yeTogIEFkZGl0aW9uYWxs eSwgY2hhbmdlcyB0byB0aGUgaGFyZHdhcmUKICAgICAgICAgYW5kIHNvZnR3YXJlIGludmVudG9y eSBhcmUgbW9uaXRvcmVkLCB3aXRoIGNoYW5nZXMgY2F1c2luZwogICAgICAgICBhbGVydHMgdG8g YmUgaXNzdWVkLgoKICAgUG9zdHVyZSBBdHRyaWJ1dGUgVmFsdWUgQ29sbGVjdGlvbjogIEFmdGVy IHRoZSBpbml0aWFsIGFzc2Vzc21lbnQsCiAgICAgICAgIHBvc3R1cmUgYXR0cmlidXRlcyBhcmUg bW9uaXRvcmVkIGZvciBjaGFuZ2VzLiAgSWYgYW55IG9mIHRoZQogICAgICAgICBzZWxlY3RlZCBw b3N0dXJlIGF0dHJpYnV0ZSB2YWx1ZXMgY2hhbmdlLCBhbiBhbGVydCBpcyBpc3N1ZWQuCgogICBQ b3N0dXJlIEF0dHJpYnV0ZSBWYWx1ZSBRdWVyeTogIFRoZSBwcmV2aW91cyBzdGF0ZSBvZiBwb3N0 dXJlCiAgICAgICAgIGF0dHJpYnV0ZXMgYXJlIHRyYWNrZWQsIGFsbG93aW5nIGNoYW5nZXMgdG8g YmUgZGV0ZWN0ZWQuCgogICBQb3N0dXJlIEF0dHJpYnV0ZSBFdmFsdWF0aW9uOiAgQWZ0ZXIgdGhl IGluaXRpYWwgYXNzZXNzbWVudCwgYQogICAgICAgICBwYXJ0aWFsIGV2YWx1YXRpb24gaXMgcGVy Zm9ybWVkIGJhc2VkIG9uIGNoYW5nZXMgdG8gc3BlY2lmaWMKICAgICAgICAgcG9zdHVyZSBhdHRy aWJ1dGVzLgoKICAgVGhpcyB1c2FnZSBzY2VuYXJpbyBoaWdobGlnaHRzIHRoZSBuZWVkIHRvIHF1 ZXJ5IGEgZGF0YSBzdG9yZSB0bwogICBwcmVwYXJlIGEgY29tcGxpYW5jZSByZXBvcnQgZm9yIGEg c3BlY2lmaWMgZW5kcG9pbnQgYW5kIGFsc28gdGhlIG5lZWQKICAgZm9yIGEgY2hhbmdlIGluIGVu ZHBvaW50IHN0YXRlIHRvIHRyaWdnZXIgQ29sbGVjdGlvbiBhbmQgRXZhbHVhdGlvbi4KCjIuMi40 LiAgRW5kcG9pbnQgSW5mb3JtYXRpb24gQW5hbHlzaXMgYW5kIFJlcG9ydGluZwoKICAgRnJlZWQg ZnJvbSB0aGUgZHJ1ZGdlcnkgb2YgbWFudWFsIGVuZHBvaW50IGNvbXBsaWFuY2UgbW9uaXRvcmlu Zywgb25lCiAgIG9mIHRoZSBzZWN1cml0eSBhZG1pbmlzdHJhdG9ycyBhdCBFeGFtcGxlIENvcnBv cmF0aW9uIG5vdGljZXMgKG5vdAogICB1c2luZyBTQUNNIHN0YW5kYXJkcykgdGhhdCBmaXZlIGVu ZHBvaW50cyBoYXZlIGJlZW4gdXBsb2FkaW5nIGxvdHMgb2YKICAgZGF0YSB0byBhIHN1c3BpY2lv dXMgc2VydmVyIG9uIHRoZSBJbnRlcm5ldC4gIFRoZSBhZG1pbmlzdHJhdG9yCiAgIHF1ZXJpZXMg ZGF0YSBzdG9yZXMgZm9yIHNwZWNpZmljIGVuZHBvaW50IHBvc3R1cmUgdG8gc2VlIHdoYXQKICAg c29mdHdhcmUgaXMgaW5zdGFsbGVkIG9uIHRob3NlIGVuZHBvaW50cyBhbmQgZmluZHMgdGhhdCB0 aGV5IGFsbCBoYXZlCiAgIGEgcGFydGljdWxhciBwcm9ncmFtIGluc3RhbGxlZC4gIFNoZSB0aGVu IHF1ZXJpZXMgdGhlIGFwcHJvcHJpYXRlCiAgIGRhdGEgc3RvcmVzIHRvIHNlZSB3aGljaCBvdGhl ciBlbmRwb2ludHMgaGF2ZSB0aGF0IHByb2dyYW0gaW5zdGFsbGVkLgogICBBbGwgdGhlc2UgZW5k cG9pbnRzIGFyZSBtb25pdG9yZWQgY2FyZWZ1bGx5IChub3QgdXNpbmcgU0FDTQogICBzdGFuZGFy ZHMpLCB3aGljaCBhbGxvd3MgdGhlIGFkbWluaXN0cmF0b3IgdG8gZGV0ZWN0IHRoYXQgdGhlIG90 aGVyCiAgIGVuZHBvaW50cyBhcmUgYWxzbyBpbmZlY3RlZC4KCiAgIFRoaXMgaXMganVzdCBvbmUg ZXhhbXBsZSBvZiB0aGUgdXNlZnVsIGFuYWx5c2lzIHRoYXQgYSBza2lsbGVkCiAgIGFuYWx5c3Qg Y2FuIGRvIHVzaW5nIGRhdGEgc3RvcmVzIG9mIGVuZHBvaW50IHBvc3R1cmUuCgogICBUaGlzIHVz YWdlIHNjZW5hcmlvIGVtcGxveXMgdGhlIGZvbGxvd2luZyBidWlsZGluZyBibG9ja3MgZGVmaW5l ZCBpbgogICBTZWN0aW9uIDIuMS4xIGFib3ZlOgoKICAgUG9zdHVyZSBBdHRyaWJ1dGUgVmFsdWUg UXVlcnk6ICBQcmV2aW91c2x5IGNvbGxlY3RlZCBwb3N0dXJlCiAgICAgICAgIGF0dHJpYnV0ZSB2 YWx1ZXMgYXJlIHF1ZXJpZWQgZnJvbSB0aGUgYXBwcm9wcmlhdGUgZGF0YSBzdG9yZXMKICAgICAg ICAgZm9yIHRoZSB0YXJnZXQgZW5kcG9pbnQocykuCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9u ICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVy bmV0LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVi cnVhcnkgMjAxNAoKCiAgICAgICAgIFFVRVNUSU9OOiBTaG91bGQgd2UgaW5jbHVkZSBvdGhlciBi dWlsZGluZyBibG9ja3MgaGVyZT8KCiAgIFRoaXMgdXNhZ2Ugc2NlbmFyaW8gaGlnaGxpZ2h0cyB0 aGUgbmVlZCB0byBxdWVyeSBhIHJlcG9zaXRvcnkgZm9yCiAgIGF0dHJpYnV0ZXMgdG8gc2VlIHdo aWNoIGF0dHJpYnV0ZXMgY2VydGFpbiBlbmRwb2ludHMgaGF2ZSBpbiBjb21tb24uCgoyLjIuNS4g IEFzeW5jaHJvbm91cyBDb21wbGlhbmNlL1Z1bG5lcmFiaWxpdHkgQXNzZXNzbWVudCBhdCBJY2Ug U3RhdGlvbgogICAgICAgIFplYnJhCgogICBBIHVuaXZlcnNpdHkgdGVhbSByZWNlaXZlcyBhIGdy YW50IHRvIGRvIHJlc2VhcmNoIGF0IGEgZ292ZXJubWVudAogICBmYWNpbGl0eSBpbiB0aGUgYXJj dGljLiAgVGhlIG9ubHkgbmV0d29yayBjb21tdW5pY2F0aW9ucyB3aWxsIGJlIHZpYQogICBhbiBp bnRlcm1pdHRlbnQgbG93LXNwZWVkIGhpZ2gtbGF0ZW5jeSBoaWdoLWNvc3Qgc2F0ZWxsaXRlIGxp bmsuCiAgIER1cmluZyB0aGVpciBleHRlbmRlZCBleHBlZGl0aW9uIHRoZXkgd2lsbCBuZWVkIHRv IHNob3cgY29udGludWUKICAgY29tcGxpYW5jZSB3aXRoIHRoZSBzZWN1cml0eSBwb2xpY2llcyBv ZiB0aGUgdW5pdmVyc2l0eSwgdGhlCiAgIGdvdmVybm1lbnQsIGFuZCB0aGUgcHJvdmlkZXIgb2Yg dGhlIHNhdGVsbGl0ZSBuZXR3b3JrIGFzIHdlbGwgYXMga2VlcAogICBjdXJyZW50IG9uIHZ1bG5l cmFiaWxpdHkgdGVzdGluZy4gIEludGVyYWN0aXZlIGFzc2Vzc21lbnRzIGFyZQogICB0aGVyZWZv cmUgbm90IHJlbGlhYmxlLCBhbmQgc2luY2UgdGhlIHJlc2VhcmNoZXJzIGhhdmUgdmVyeSBsaW1p dGVkCiAgIGZ1bmRpbmcgdGhleSBuZWVkIHRvIG1pbmltaXplIGhvdyBtdWNoIG1vbmV5IHRoZXkg c3BlbmQgb24gbmV0d29yawogICBkYXRhLgoKICAgUHJpb3IgdG8gZGVwYXJ0dXJlIHRoZXkgcmVn aXN0ZXIgYWxsIGVxdWlwbWVudCB3aXRoIGFuIGFzc2V0CiAgIG1hbmFnZW1lbnQgc3lzdGVtIG93 bmVkIGJ5IHRoZSB1bml2ZXJzaXR5LCB3aGljaCB3aWxsIGFsc28gaW5pdGlhdGUKICAgYW5kIHRy YWNrIGFzc2Vzc21lbnRzLgoKICAgT24gYSBwZXJpb2RpYyBiYXNpcyAtLSBlaXRoZXIgYWZ0ZXIg YSBtYXhpbXVtIHRpbWUgZGVsdGEgb3Igd2hlbiB0aGUKICAgc2VjdXJpdHkgYXV0b21hdGlvbiBk YXRhIHN0b3JlIGhhcyByZWNlaXZlZCBhIHRocmVzaG9sZCBsZXZlbCBvZiBuZXcKICAgdnVsbmVy YWJpbGl0eSBkZWZpbml0aW9ucyAtLSB0aGUgdW5pdmVyc2l0eSB1c2VzIHRoZSBpbmZvcm1hdGlv biBpbgogICB0aGUgYXNzZXQgbWFuYWdlbWVudCBzeXN0ZW0gdG8gcHV0IHRvZ2V0aGVyIGEgY29s bGVjdGlvbiByZXF1ZXN0IGZvcgogICBhbGwgb2YgdGhlIGRlcGxveWVkIGFzc2V0cyB0aGF0IGVu Y29tcGFzc2VzIHRoZSBtaW5pbWFsIHNldCBvZgogICBhcnRpZmFjdHMgbmVjZXNzYXJ5IHRvIGV2 YWx1YXRlIGFsbCB0aHJlZSBzZWN1cml0eSBwb2xpY2llcyBhcyB3ZWxsCiAgIGFzIHZ1bG5lcmFi aWxpdHkgdGVzdGluZy4KCiAgIEluIHRoZSBjYXNlIG9mIG5ldyBjcml0aWNhbCB2dWxuZXJhYmls aXRpZXMgdGhpcyBjb2xsZWN0aW9uIHJlcXVlc3QKICAgY29uc2lzdHMgb25seSBvZiB0aGUgYXJ0 aWZhY3RzIG5lY2Vzc2FyeSBmb3IgdGhvc2UgdnVsbmVyYWJpbGl0aWVzCiAgIGFuZCBjb2xsZWN0 aW9uIGlzIG9ubHkgaW5pdGlhdGVkIGZvciB0aG9zZSBhc3NldHMgdGhhdCBjb3VsZAogICBwb3Rl bnRpYWxseSBoYXZlIGEgbmV3IHZ1bG5lcmFiaWxpdHkuCgogICBbT3B0aW9uYWxdIEFzc2V0IGFy dGlmYWN0cyBhcmUgY2FjaGVkIGluIGEgbG9jYWwgQ01EQi4gIFdoZW4gbmV3CiAgIHZ1bG5lcmFi aWxpdGllcyBhcmUgcmVwb3J0ZWQgdG8gdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gZGF0YSBzdG9y ZSwgYQogICByZXF1ZXN0IHRvIHRoZSBsaXZlIGFzc2V0IGlzIG9ubHkgZG9uZSBpZiB0aGUgYXJ0 aWZhY3RzIGluIHRoZSBDTURCCiAgIGFyZSBpbmNvbXBsZXRlIGFuZC9vciBub3QgY3VycmVudCBl bm91Z2guCgogICBUaGUgY29sbGVjdGlvbiByZXF1ZXN0IGlzIHF1ZXVlZCBmb3IgdGhlIG5leHQg d2luZG93IG9mIGNvbm5lY3Rpdml0eS4KICAgVGhlIGRlcGxveWVkIGFzc2V0cyBldmVudHVhbGx5 IHJlY2VpdmUgdGhlIHJlcXVlc3QsIGZ1bGZpbGwgaXQsIGFuZAogICBxdWV1ZSB0aGUgcmVzdWx0 cyBmb3IgdGhlIG5leHQgcmV0dXJuIG9wcG9ydHVuaXR5LgoKICAgVGhlIGNvbGxlY3RlZCBhcnRp ZmFjdHMgZXZlbnR1YWxseSBtYWtlIGl0IGJhY2sgdG8gdGhlIHVuaXZlcnNpdHkKICAgd2hlcmUg dGhlIGxldmVsIG9mIGNvbXBsaWFuY2UgYW5kIHZ1bG5lcmFiaWxpdHkgZXhwb3NlIGlzIGNhbGN1 bGF0ZWQKCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAx NCAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0RW50ZXJwcmlzZSBVc2Ug Q2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVhcnkgMjAxNAoKCiAgIGFuZCBhc3Nl dCBjaGFyYWN0ZXJpc3RpY3MgYXJlIGNvbXBhcmVkIHRvIHdoYXQgaXMgaW4gdGhlIGFzc2V0CiAg IG1hbmFnZW1lbnQgc3lzdGVtIGZvciBhY2N1cmFjeSBhbmQgY29tcGxldGVuZXNzLgoKICAgTGlr ZSB0aGUgQXV0b21hdGVkIENoZWNrbGlzdCBWZXJpZmljYXRpb24gdXNhZ2Ugc2NlbmFyaW8gKHNl ZSBzZWN0aW9uCiAgIDIuMi4yKSwgdGhpcyB1c2FnZSBzY2VuYXJpbyBzdXBwb3J0cyBhc3Nlc3Nt ZW50IGJhc2VkIG9uIGNoZWNrbGlzdHMuCiAgIEl0IGRpZmZlcnMgZnJvbSB0aGF0IHNjZW5hcmlv IGluIGhvdyBndWlkYW5jZSwgY29sbGVjdGVkIHBvc3R1cmUKICAgYXR0cmlidXRlIHZhbHVlcywg YW5kIGV2YWx1YXRpb24gcmVzdWx0cyBhcmUgZXhjaGFuZ2VkIGR1ZSB0bwogICBiYW5kd2lkdGgg bGltaXRhdGlvbnMgYW5kIGF2YWlsYWJpbGl0eS4gIFRoaXMgdXNhZ2Ugc2NlbmFyaW8gZW1wbG95 cwogICB0aGUgc2FtZSBidWlsZGluZyBibG9ja3MgYXMgQXV0b21hdGVkIENoZWNrbGlzdCBWZXJp ZmljYXRpb24gKHNlZQogICBzZWN0aW9uIDIuMi4yKS4gIEl0IGRpZmZlcnMgc2xpZ2h0bHkgaW4g aG93IGl0IHVzZXMgdGhlIGZvbGxvd2luZwogICBidWlsZGluZyBibG9ja3M6CgogICBFbmRwb2lu dCBDb21wb25lbnQgSW52ZW50b3J5OiAgSXQgaXMgbGlrZWx5IHRoYXQgdGhlIGNvbXBvbmVudAog ICAgICAgICBpbnZlbnRvcnkgd2lsbCBub3QgY2hhbmdlLiAgSWYgaXQgZG9lcywgdGhpcyBpbmZv cm1hdGlvbiB3aWxsCiAgICAgICAgIG5lZWQgdG8gYmUgYmF0Y2hlZCBhbmQgdHJhbnNtaXR0ZWQg ZHVyaW5nIHRoZSBuZXh0CiAgICAgICAgIGNvbW11bmljYXRpb24gd2luZG93LgoKICAgQ29sbGVj dGlvbiBHdWlkYW5jZSBBY3F1aXNpdGlvbjogIER1ZSB0byBpbnRlcm1pdHRlbnQgY29tbXVuaWNh dGlvbgogICAgICAgICB3aW5kb3dzIGFuZCBiYW5kd2lkdGggY29uc3RyYWludHMsIGNoYW5nZXMg dG8gY29sbGVjdGlvbgogICAgICAgICBndWlkYW5jZSB3aWxsIG5lZWQgdG8gYmF0Y2hlZCBhbmQg dHJhbnNtaXR0ZWQgZHVyaW5nIHRoZSBuZXh0CiAgICAgICAgIGNvbW11bmljYXRpb24gd2luZG93 LiAgR3VpZGFuY2Ugd2lsbCBuZWVkIHRvIGJlIGNhY2hlZCBsb2NhbGx5CiAgICAgICAgIHRvIGF2 b2lkIHRoZSBuZWVkIGZvciByZW1vdGUgY29tbXVuaWNhdGlvbnMuCgogICBQb3N0dXJlIEF0dHJp YnV0ZSBWYWx1ZSBDb2xsZWN0aW9uOiAgVGhlIHNwZWNpZmljIHBvc3R1cmUgYXR0cmlidXRlCiAg ICAgICAgIHZhbHVlcyB0byBiZSBjb2xsZWN0ZWQgYXJlIGlkZW50aWZpZWQgcmVtb3RlbHkgYW5k IGJhdGNoZWQgZm9yCiAgICAgICAgIGNvbGxlY3Rpb24gZHVyaW5nIHRoZSBuZXh0IGNvbW11bmlj YXRpb24gd2luZG93LiAgSWYgYSBkZWxheSBpcwogICAgICAgICBpbnRyb2R1Y2VkIGZvciBjb2xs ZWN0aW9uIHRvIGNvbXBsZXRlLCByZXN1bHRzIHdpbGwgbmVlZCB0byBiZQogICAgICAgICBiYXRj aGVkIGFuZCB0cmFuc21pdHRlZCBpbiB0aGUgc2FtZSB3YXkuCgogICAgICAgICBDT01NRU5UKERC SCk6IFdoeSAiaW4gdGhlIHNhbWUgd2F5Ij8gIE1heWJlIHJlc3VsdHMgY291bGQgYmUKICAgICAg ICAgaGFuZGxlZCBpbiBhIGRpZmZlcmVudCB3YXkuCgogICBQb3N0dXJlIEF0dHJpYnV0ZSBWYWx1 ZSBRdWVyeTogIFByZXZpb3VzbHkgY29sbGVjdGVkIHBvc3R1cmUKICAgICAgICAgYXR0cmlidXRl IHZhbHVlcyB3aWxsIGJlIHN0b3JlZCBpbiBhIHJlbW90ZSBkYXRhIHN0b3JlIGZvciB1c2UKICAg ICAgICAgYXQgdGhlIHVuaXZlcnNpdHkKCiAgIEV2YWx1YXRpb24gR3VpZGFuY2UgQWNxdWlzaXRp b246ICBEdWUgdG8gaW50ZXJtaXR0ZW50IGNvbW11bmljYXRpb24KICAgICAgICAgd2luZG93cyBh bmQgYmFuZHdpZHRoIGNvbnN0cmFpbnRzLCBjaGFuZ2VzIHRvIGV2YWx1YXRpb24KICAgICAgICAg Z3VpZGFuY2Ugd2lsbCBuZWVkIHRvIGJhdGNoZWQgYW5kIHRyYW5zbWl0dGVkIGR1cmluZyB0aGUg bmV4dAogICAgICAgICBjb21tdW5pY2F0aW9uIHdpbmRvdy4gIEd1aWRhbmNlIHdpbGwgbmVlZCB0 byBiZSBjYWNoZWQgbG9jYWxseQogICAgICAgICB0byBhdm9pZCB0aGUgbmVlZCBmb3IgcmVtb3Rl IGNvbW11bmljYXRpb25zLgoKICAgUG9zdHVyZSBBdHRyaWJ1dGUgRXZhbHVhdGlvbjogIER1ZSB0 byB0aGUgY2FjaGluZyBvZiBwb3N0dXJlCiAgICAgICAgIGF0dHJpYnV0ZSB2YWx1ZXMgYW5kIGV2 YWx1YXRpb24gZ3VpZGFuY2UsIGV2YWx1YXRpb24gbWF5IGJlCiAgICAgICAgIHBlcmZvcm1lZCBh dCBib3RoIHRoZSB1bml2ZXJzaXR5IGNhbXB1cyBhcyB3ZWxsIGFzIHRoZQogICAgICAgICBzYXRl bGxpdGUgc2l0ZS4KCgoKCgpXYWx0ZXJtaXJlICYgSGFycmluZ3RvbiAgRXhwaXJlcyBBdWd1c3Qg MTksIDIwMTQgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1EcmFmdEVudGVycHJp c2UgVXNlIENhc2VzIGZvciBTZWN1cml0eSBBc3Nlc3NtZW50IEZlYnJ1YXJ5IDIwMTQKCgogICBU aGlzIHVzYWdlIHNjZW5hcmlvIGhpZ2hsaWdodHMgdGhlIG5lZWQgdG8gc3VwcG9ydCBsb3ctYmFu ZHdpZHRoLAogICBpbnRlcm1pdHRlbnQsIG9yIGhpZ2gtbGF0ZW5jeSBsaW5rcy4KCjIuMi42LiAg SWRlbnRpZmljYXRpb24gYW5kIFJldHJpZXZhbCBvZiBHdWlkYW5jZQoKICAgSW4gcHJlcGFyYXRp b24gZm9yIHBlcmZvcm1pbmcgYW4gYXNzZXNzbWVudCwgYW4gb3BlcmF0b3Igb3IKICAgYXBwbGlj YXRpb24gd2lsbCBuZWVkIHRvIGlkZW50aWZ5IG9uZSBvciBtb3JlIHNlY3VyaXR5IGF1dG9tYXRp b24KICAgZGF0YSBzdG9yZXMgdGhhdCBjb250YWluIHRoZSBndWlkYW5jZSBlbnRyaWVzIG5lY2Vz c2FyeSB0byBwZXJmb3JtCiAgIGRhdGEgY29sbGVjdGlvbiBhbmQgZXZhbHVhdGlvbiB0YXNrcy4g IFRoZSBsb2NhdGlvbiBvZiBhIGdpdmVuCiAgIGd1aWRhbmNlIGVudHJ5IHdpbGwgZWl0aGVyIGJl IGtub3duIGEgcHJpb3JpIG9yIGtub3duIHNlY3VyaXR5CiAgIGF1dG9tYXRpb24gZGF0YSBzdG9y ZXMgd2lsbCBuZWVkIHRvIGJlIHF1ZXJpZWQgdG8gcmV0cmlldmUgYXBwbGljYWJsZQogICBndWlk YW5jZS4KCiAgIFRvIHF1ZXJ5IGd1aWRhbmNlIGl0IHdpbGwgYmUgbmVjZXNzYXJ5IHRvIGRlZmlu ZSBhIHNldCBvZiBzZWFyY2gKICAgY3JpdGVyaWEuICBUaGlzIGNyaXRlcmlhIHdpbGwgb2Z0ZW4g dXRpbGl6ZSBhIGxvZ2ljYWwgY29tYmluYXRpb24gb2YKICAgcHVibGljYXRpb24gbWV0YWRhdGEg KGUuZy4gIHB1Ymxpc2hpbmcgaWRlbnRpdHksIGNyZWF0ZSB0aW1lLAogICBtb2RpZmljYXRpb24g dGltZSkgYW5kIGd1aWRhbmNlIGRhdGEtc3BlY2lmaWMgY3JpdGVyaWEgZWxlbWVudHMuCiAgIE9u Y2UgdGhlIGNyaXRlcmlhIGlzIGRlZmluZWQsIG9uZSBvciBtb3JlIHNlY3VyaXR5IGF1dG9tYXRp b24gZGF0YQogICBzdG9yZXMgd2lsbCBuZWVkIHRvIGJlIHF1ZXJpZWQgZ2VuZXJhdGluZyBhIHJl c3VsdCBzZXQuICBEZXBlbmRpbmcgb24KICAgaG93IHRoZSByZXN1bHRzIGFyZSB1c2VkLCBpdCBt YXkgYmUgZGVzaXJhYmxlIHRvIHJldHVybiB0aGUgbWF0Y2hpbmcKICAgZ3VpZGFuY2UgZGlyZWN0 bHksIGEgc25pcHBldCBvZiB0aGUgZ3VpZGFuY2UgbWF0Y2hpbmcgdGhlIHF1ZXJ5LCBvciBhCiAg IHJlc29sdmFibGUgbG9jYXRpb24gdG8gcmV0cmlldmUgdGhlIGRhdGEgYXQgYSBsYXRlciB0aW1l LiAgVGhlCiAgIGd1aWRhbmNlIG1hdGNoaW5nIHRoZSBxdWVyeSB3aWxsIGJlIHJlc3RyaWN0ZWQg YmFzZWQgdGhlIGF1dGhvcml6ZWQKICAgbGV2ZWwgb2YgYWNjZXNzIGFsbG93ZWQgdG8gdGhlIHJl cXVlc3Rlci4KCiAgIElmIHRoZSBsb2NhdGlvbiBvZiBndWlkYW5jZSBpcyBpZGVudGlmaWVkIGlu IHRoZSBxdWVyeSByZXN1bHQgc2V0LAogICB0aGUgZ3VpZGFuY2Ugd2lsbCBiZSByZXRyaWV2ZWQg d2hlbiBuZWVkZWQgdXNpbmcgb25lIG9yIG1vcmUgZGF0YQogICByZXRyaWV2YWwgcmVxdWVzdHMu ICBBIHZhcmlhdGlvbiBvbiB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHRvCiAgIG1haW50YWluIGEg bG9jYWwgY2FjaGUgb2YgcHJldmlvdXNseSByZXRyaWV2ZWQgZGF0YS4gIEluIHRoaXMgY2FzZSwK ICAgb25seSBndWlkYW5jZSB0aGF0IGlzIGRldGVybWluZWQgdG8gYmUgc3RhbGUgYnkgc29tZSBt ZWFzdXJlIHdpbGwgYmUKICAgcmV0cmlldmVkIGZyb20gdGhlIHJlbW90ZSBkYXRhIHN0b3JlLgoK ICAgQWx0ZXJuYXRlbHksIGd1aWRhbmNlIGNhbiBiZSBkaXNjb3ZlcmVkIGJ5IGl0ZXJhdGluZyBv dmVyIGRhdGEKICAgcHVibGlzaGVkIHdpdGggYSBnaXZlbiBjb250ZXh0IHdpdGhpbiBhIHNlY3Vy aXR5IGF1dG9tYXRpb24gZGF0YQogICBzdG9yZS4gIFNwZWNpZmljIGd1aWRhbmNlIGNhbiBiZSBz ZWxlY3RlZCBhbmQgcmV0cmlldmVkIGFzIG5lZWRlZC4KCiAgIFRoaXMgdXNhZ2Ugc2NlbmFyaW8g ZW1wbG95cyB0aGUgZm9sbG93aW5nIGJ1aWxkaW5nIGJsb2NrcyBkZWZpbmVkIGluCiAgIFNlY3Rp b24gMi4xLjEgYWJvdmU6CgogICBEYXRhIFF1ZXJ5OiAgRW5hYmxlcyBhbiBvcGVyYXRvciBvciBh cHBsaWNhdGlvbiB0byBxdWVyeSBvbmUgb3IgbW9yZQogICAgICAgICBzZWN1cml0eSBhdXRvbWF0 aW9uIGRhdGEgc3RvcmVzIGZvciBndWlkYW5jZSB1c2luZyBhIHNldCBvZgogICAgICAgICBzcGVj aWZpZWQgY3JpdGVyaWEuCgogICBEYXRhIFJldHJpZXZhbDogIElmIGRhdGEgbG9jYXRpb25zIGFy ZSByZXR1cm5lZCBpbiB0aGUgcXVlcnkgcmVzdWx0CiAgICAgICAgIHNldCwgdGhlbiBzcGVjaWZp YyBndWlkYW5jZSBlbnRyaWVzIGNhbiBiZSByZXRyaWV2ZWQgYW5kCiAgICAgICAgIHBvc3NpYmx5 IGNhY2hlZCBsb2NhbGx5LgoKCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBpcmVzIEF1 Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0RW50 ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVhcnkgMjAxNAoK CjIuMi43LiAgR3VpZGFuY2UgQ2hhbmdlIERldGVjdGlvbgoKICAgQW4gb3BlcmF0b3Igb3IgYXBw bGljYXRpb24gbWF5IG5lZWQgdG8gaWRlbnRpZnkgbmV3LCB1cGRhdGVkLCBvcgogICBkZWxldGVk IGd1aWRhbmNlIGluIGEgc2VjdXJpdHkgYXV0b21hdGlvbiBkYXRhIHN0b3JlIGZvciB3aGljaCB0 aGV5CiAgIGhhdmUgYmVlbiBhdXRob3JpemVkIHRvIGFjY2Vzcy4gIFRoaXMgbWF5IGJlIGFjaGll dmVkIGJ5IHF1ZXJ5aW5nIG9yCiAgIGl0ZXJhdGluZyBvdmVyIGd1aWRhbmNlIGluIGEgc2VjdXJp dHkgYXV0b21hdGlvbiBkYXRhIHN0b3JlLCBvcgogICB0aHJvdWdoIGEgbm90aWZpY2F0aW9uIG1l Y2hhbmlzbSB0aGF0IGFsZXJ0cyB0byBjaGFuZ2VzIG1hZGUgdG8gYQogICBzZWN1cml0eSBhdXRv bWF0aW9uIGRhdGEgc3RvcmUuCgogICBPbmNlIGd1aWRhbmNlIGNoYW5nZXMgaGF2ZSBiZWVuIGRl dGVybWluZWQsIGRhdGEgY29sbGVjdGlvbiBhbmQKICAgZXZhbHVhdGlvbiBhY3Rpdml0aWVzIG1h eSBiZSB0cmlnZ2VyZWQuCgogICBUaGlzIHVzYWdlIHNjZW5hcmlvIGVtcGxveXMgdGhlIGZvbGxv d2luZyBidWlsZGluZyBibG9ja3MgZGVmaW5lZCBpbgogICBTZWN0aW9uIDIuMS4xIGFib3ZlOgoK ICAgRGF0YSBDaGFuZ2UgRGV0ZWN0aW9uOiAgQWxsb3dzIGFuIG9wZXJhdG9yIG9yIGFwcGxpY2F0 aW9uIHRvIGlkZW50aWZ5CiAgICAgICAgIGd1aWRhbmNlIGNoYW5nZXMgaW4gYSBzZWN1cml0eSBh dXRvbWF0aW9uIGRhdGEgc3RvcmUgd2hpY2ggdGhleQogICAgICAgICBoYXZlIGJlZW4gYXV0aG9y aXplZCB0byBhY2Nlc3MuCgogICBEYXRhIFJldHJpZXZhbDogIElmIGRhdGEgbG9jYXRpb25zIGFy ZSBwcm92aWRlZCBieSB0aGUgY2hhbmdlCiAgICAgICAgIGRldGVjdGlvbiBtZWNoYW5pc20sIHRo ZW4gc3BlY2lmaWMgZ3VpZGFuY2UgZW50cmllcyBjYW4gYmUKICAgICAgICAgcmV0cmlldmVkIGFu ZCBwb3NzaWJseSBjYWNoZWQgbG9jYWxseS4KCjIuMi44LiAgT3RoZXJzLi4uCgogICBBZGRpdGlv bmFsIHVzYWdlIHNjZW5hcmlvcyB3aWxsIGJlIGlkZW50aWZpZWQgYXMgd2Ugd29yayB0aHJvdWdo CiAgIG90aGVyIGRvbWFpbnMuCgozLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBtZW1v IGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS4KCjQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cwoKICAgVGhpcyBtZW1vIGRvY3VtZW50cywgZm9yIEluZm9ybWF0aW9uYWwgcHVycG9zZXMsIHVz ZSBjYXNlcyBmb3IKICAgc2VjdXJpdHkgYXV0b21hdGlvbi4gIFdoaWxlIGl0IGlzIGFib3V0IHNl Y3VyaXR5LCBpdCBkb2VzIG5vdCBhZmZlY3QKICAgc2VjdXJpdHkuCgo1LiAgQWNrbm93bGVkZ2Vt ZW50cwoKICAgVGhlIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xv Z3kgKE5JU1QpIGFuZC9vciB0aGUKICAgTUlUUkUgQ29ycG9yYXRpb24gaGF2ZSBkZXZlbG9wZWQg c3BlY2lmaWNhdGlvbnMgdW5kZXIgdGhlIGdlbmVyYWwKICAgdGVybSAiU2VjdXJpdHkgQXV0b21h dGlvbiIgaW5jbHVkaW5nIGxhbmd1YWdlcywgcHJvdG9jb2xzLAogICBlbnVtZXJhdGlvbnMsIGFu ZCBtZXRyaWNzLgoKICAgQWRhbSBNb250dmlsbGUgZWRpdGVkIGVhcmx5IHZlcnNpb25zIG9mIHRo aXMgZHJhZnQuCgoKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMgQXVndXN0IDE5 LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnRFbnRlcnByaXNl IFVzZSBDYXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0CgoKICAgS2F0 aGxlZW4gTW9yaWFydHksIGFuZCBTdGVwaGVuIEhhbm5hIGNvbnRyaWJ1dGVkIHRleHQgZGVzY3Jp YmluZyB0aGUKICAgc2NvcGUgb2YgdGhlIGRvY3VtZW50LgoKICAgR3VubmFyIEVuZ2VsYmFjaCwg U3RldmUgSGFubmEsIENocmlzIEluYWNpbywgS2VudCBMYW5kZmllbGQsIExpc2EKICAgTG9yZW56 aW4sIEFkYW0gTW9udHZpbGxlLCBLYXRobGVlbiBNb3JpYXJ0eSwgTmFuY3kgQ2FtLVdpbmdldCwg YW5kCiAgIEFyb24gV29sYW5kIHByb3ZpZGVkIHVzZSBjYXNlcyB0ZXh0IGZvciB2YXJpb3VzIHJl dmlzaW9ucyBvZiB0aGlzCiAgIGRyYWZ0LgoKNi4gIENoYW5nZSBMb2cKCjYuMS4gIC0wNS0gdG8g LTA2LQoKICAgVXBkYXRlZCB0aGUgIkludHJvZHVjdGlvbiIgc2VjdGlvbiB0byBiZXR0ZXIgcmVm bGVjdCB0aGUgdXNlIGNhc2UsCiAgIGJ1aWxkaW5nIGJsb2NrLCBhbmQgdXNhZ2Ugc2NlbmFyaW8g c3RydWN0dXJlIGNoYW5nZXMgZnJvbSBwcmV2aW91cwogICByZXZpc2lvbnMuCgogICBVcGRhdGVk IG1vc3QgdXNlcyBvZiB0aGUgdGVybXMgImNvbnRlbnQiIGFuZCAiY29udGVudCByZXBvc2l0b3J5 IiB0bwogICB1c2UgImd1aWRhbmNlIiBhbmQgInNlY3VyaXR5IGF1dG9tYXRpb24gZGF0YSBzdG9y ZSIgcmVzcGVjdGl2ZWx5LgoKICAgSW4gc2VjdGlvbiAyLjEuMSwgYWRkZWQgYSBkaXNjdXNzaW9u IG9mIGRpZmZlcmVudCBkYXRhIHR5cGVzIGFuZAogICByZW5hbWVkICJjb250ZW50IiB0byAiZGF0 YSIgaW4gdGhlIGJ1aWxkaW5nIGJsb2NrIG5hbWVzLgoKICAgSW4gc2VjdGlvbiAyLjEuMiwgc2Vw YXJhdGVkIG91dCB0aGUgYnVpbGRpbmcgYmxvY2sgY29uY2VwdHMgb2YKICAgIkVuZHBvaW50IERp c2NvdmVyeSIgYW5kICJFbmRwb2ludCBDaGFyYWN0ZXJpemF0aW9uIiBiYXNlZCBvbiBtYWlsaW5n CiAgIGxpc3QgZGlzY3Vzc2lvbnMuCgogICBBZGRyZXNzZWQgc29tZSBvcGVuIHF1ZXN0aW9ucyB0 aHJvdWdob3V0IHRoZSBkcmFmdCBiYXNlZCBvbiBjb25zZW5zdXMKICAgZnJvbSBtYWlsaW5nIGxp c3QgZGlzY3Vzc2lvbnMgYW5kIHRoZSB0d28gdmlydHVhbCBpbnRlcmltIG1lZXRpbmdzLgoKICAg Q2hhbmdlZCBtYW55IHNlY3Rpb24vc3ViLXNlY3Rpb24gbmFtZXMgdG8gYmV0dGVyIHJlZmxlY3Qg dGhlaXIKICAgY29udGVudC4KCjYuMi4gIC0wNC0gdG8gLTA1LQoKICAgQ2hhbmdlcyBpbiB0aGlz IHJldmlzaW9uIGFyZSBmb2N1c2VkIG9uIHNlY3Rpb24gMiBhbmQgdGhlIHN1YnNlcXVlbnQKICAg c3Vic2VjdGlvbnM6CgogICBvICBNb3ZlZCBleGlzdGluZyB1c2UgY2FzZXMgdG8gYSBzdWJzZWN0 aW9uIHRpdGxlZCAiVXNhZ2UgU2NlbmFyaW9zIi4KCiAgIG8gIEFkZGVkIGEgbmV3IHN1YnNlY3Rp b24gdGl0bGVkICJVc2UgQ2FzZXMiIHRvIGRlc2NyaWJlIHRoZSBjb21tb24KICAgICAgdXNlIGNh c2VzIGFuZCBidWlsZGluZyBibG9ja3MgdXNlZCB0byBhZGRyZXNzIHRoZSAiVXNhZ2UKICAgICAg U2NlbmFyaW9zIi4gIFRoZSBuZXcgdXNlIGNhc2VzIGFyZToKCiAgICAgICogIERlZmluZSwgUHVi bGlzaCwgUXVlcnkgYW5kIFJldHJpZXZlIENvbnRlbnQKCiAgICAgICogIEVuZHBvaW50IElkZW50 aWZpY2F0aW9uIGFuZCBBc3Nlc3NtZW50IFBsYW5uaW5nCgogICAgICAqICBFbmRwb2ludCBQb3N0 dXJlIEF0dHJpYnV0ZSBWYWx1ZSBDb2xsZWN0aW9uCgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9u ICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVy bmV0LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVi cnVhcnkgMjAxNAoKCiAgICAgICogIFBvc3R1cmUgRXZhbHVhdGlvbgoKICAgICAgKiAgTWluaW5n IHRoZSBEYXRhYmFzZQoKICAgbyAgQWRkZWQgYSBsaXN0aW5nIG9mIGJ1aWxkaW5nIGJsb2NrcyB1 c2VkIGZvciBhbGwgdXNhZ2Ugc2NlbmFyaW9zLgoKICAgbyAgQ29tYmluZWQgdGhlIGZvbGxvd2lu ZyB1c2FnZSBzY2VuYXJpb3MgaW50byAiQXV0b21hdGVkIENoZWNrbGlzdAogICAgICBWZXJpZmlj YXRpb24iOiAiT3JnYW5pemF0aW9uYWwgU29mdHdhcmUgUG9saWN5IENvbXBsaWFuY2UiLAogICAg ICAiU2VhcmNoIGZvciBTaWducyBvZiBJbmZlY3Rpb24iLCAiVnVsbmVyYWJsZSBFbmRwb2ludAog ICAgICBJZGVudGlmaWNhdGlvbiIsICJDb21wcm9taXNlZCBFbmRwb2ludCBJZGVudGlmaWNhdGlv biIsCiAgICAgICJTdXNwaWNpb3VzIEVuZHBvaW50IEJlaGF2aW9yIiwgIlRyYWRpdGlvbmFsIGVu ZHBvaW50IGFzc2Vzc21lbnQKICAgICAgd2l0aCBzdG9yZWQgcmVzdWx0cyIsICJOQUMvTkFQIGNv bm5lY3Rpb24gd2l0aCBubyBzdG9yZWQgcmVzdWx0cwogICAgICB1c2luZyBhbiBlbmRwb2ludCBl dmFsdWF0b3IiLCBhbmQgIk5BQy9OQVAgY29ubmVjdGlvbiB3aXRoIG5vCiAgICAgIHN0b3JlZCBy ZXN1bHRzIHVzaW5nIGEgdGhpcmQtcGFydHkgZXZhbHVhdG9yIi4KCiAgIG8gIENyZWF0ZWQgbmV3 IHVzYWdlIHNjZW5hcmlvICJJZGVudGlmaWNhdGlvbiBhbmQgUmV0cmlldmFsIG9mCiAgICAgIFJl cG9zaXRvcnkgQ29udGVudCIgYnkgY29tYmluaW5nIHRoZSBmb2xsb3dpbmcgdXNhZ2Ugc2NlbmFy aW9zOgogICAgICAiUmVwb3NpdG9yeSBJbnRlcmFjdGlvbiAtIEEgRnVsbCBBc3Nlc3NtZW50IiBh bmQgIlJlcG9zaXRvcnkKICAgICAgSW50ZXJhY3Rpb24gLSBGaWx0ZXJlZCBEZWx0YSBBc3Nlc3Nt ZW50IgoKICAgbyAgUmVuYW1lZCAiUmVnaXN0ZXIgd2l0aCByZXBvc2l0b3J5IGZvciBpbW1lZGlh dGUgbm90aWZpY2F0aW9uIG9mCiAgICAgIG5ldyBzZWN1cml0eSB2dWxuZXJhYmlsaXR5IGNvbnRl bnQgdGhhdCBtYXRjaCBhIHNlbGVjdGlvbiBmaWx0ZXIiCiAgICAgIHRvICJDb250ZW50IENoYW5n ZSBEZXRlY3Rpb24iIGFuZCBnZW5lcmFsaXplZCB0aGUgZGVzY3JpcHRpb24gdG8KICAgICAgYmUg bmV1dHJhbCB0byBpbXBsZW1lbnRhdGlvbiBhcHByb2FjaGVzLgoKICAgbyAgUmVtb3ZlZCBvdXQt b2Ytc2NvcGUgdXNhZ2Ugc2NlbmFyaW9zOiAiUmVtZWRpYXRpb24gYW5kIE1pdGlnYXRpb24iCiAg ICAgIGFuZCAiRGlyZWN0IEh1bWFuIFJldHJpZXZhbCBvZiBBbmNpbGxhcnkgTWF0ZXJpYWxzIgoK ICAgVXBkYXRlZCBhY2tub3dsZWRnZW1lbnRzIHRvIHJlY29nbml6ZSB0aG9zZSB0aGF0IGhlbHBl ZCB3aXRoIGVkaXRpbmcKICAgdGhlIHVzZSBjYXNlIHRleHQuCgo2LjMuICAtMDMtIHRvIC0wNC0K CiAgIEFkZGVkIGZvdXIgbmV3IHVzZSBjYXNlcyByZWdhcmRpbmcgY29udGVudCByZXBvc2l0b3J5 LgoKNi40LiAgLTAyLSB0byAtMDMtCgogICBFeHBhbmRlZCB0aGUgd29ya2Zsb3cgZGVzY3JpcHRp b24gYmFzZWQgb24gTUwgaW5wdXQuCgogICBDaGFuZ2VkIHRoZSBhbWJpZ3VvdXMgImFzc2VzcyIg dG8gYmV0dGVyIHNlcGFyYXRlIGRhdGEgY29sbGVjdGlvbgogICBmcm9tIGV2YWx1YXRpb24uCgog ICBBZGRlZCB1c2UgY2FzZSBmb3IgU2VhcmNoIGZvciBTaWducyBvZiBJbmZlY3Rpb24uCgogICBB ZGRlZCB1c2UgY2FzZSBmb3IgUmVtZWRpYXRpb24gYW5kIE1pdGlnYXRpb24uCgogICBBZGRlZCB1 c2UgY2FzZSBmb3IgRW5kcG9pbnQgSW5mb3JtYXRpb24gQW5hbHlzaXMgYW5kIFJlcG9ydGluZy4K CgoKCldhbHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAg ICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMg Zm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQgRmVicnVhcnkgMjAxNAoKCiAgIEFkZGVkIHVzZSBjYXNl IGZvciBBc3luY2hyb25vdXMgQ29tcGxpYW5jZS9WdWxuZXJhYmlsaXR5IEFzc2Vzc21lbnQKICAg YXQgSWNlIFN0YXRpb24gWmVicmEuCgogICBBZGRlZCB1c2UgY2FzZSBmb3IgVHJhZGl0aW9uYWwg ZW5kcG9pbnQgYXNzZXNzbWVudCB3aXRoIHN0b3JlZAogICByZXN1bHRzLgoKICAgQWRkZWQgdXNl IGNhc2UgZm9yIE5BQy9OQVAgY29ubmVjdGlvbiB3aXRoIG5vIHN0b3JlZCByZXN1bHRzIHVzaW5n IGFuCiAgIGVuZHBvaW50IGV2YWx1YXRvci4KCiAgIEFkZGVkIHVzZSBjYXNlIGZvciBOQUMvTkFQ IGNvbm5lY3Rpb24gd2l0aCBubyBzdG9yZWQgcmVzdWx0cyB1c2luZyBhCiAgIHRoaXJkLXBhcnR5 IGV2YWx1YXRvci4KCiAgIEFkZGVkIHVzZSBjYXNlIGZvciBDb21wcm9taXNlZCBFbmRwb2ludCBJ ZGVudGlmaWNhdGlvbi4KCiAgIEFkZGVkIHVzZSBjYXNlIGZvciBTdXNwaWNpb3VzIEVuZHBvaW50 IEJlaGF2aW9yLgoKICAgQWRkZWQgdXNlIGNhc2UgZm9yIFZ1bG5lcmFibGUgRW5kcG9pbnQgSWRl bnRpZmljYXRpb24uCgogICBVcGRhdGVkIEFja25vd2xlZGdlbWVudHMKCjYuNS4gIC0wMS0gdG8g LTAyLQoKICAgQ2hhbmdlZCB0aXRsZQoKICAgcmVtb3ZlZCBzZWN0aW9uIDQsIGV4cGVjdGluZyBp dCB3aWxsIGJlIG1vdmVkIGludG8gdGhlIHJlcXVpcmVtZW50cwogICBkb2N1bWVudC4KCiAgIHJl bW92ZWQgdGhlIGxpc3Qgb2YgcHJvcG9zZWQgY2FwYWJpbGl0aWVzIGZyb20gc2VjdGlvbiAzLjEK CiAgIEFkZGVkIGVtcHR5IHNlY3Rpb25zIGZvciBTZWFyY2ggZm9yIFNpZ25zIG9mIEluZmVjdGlv biwgUmVtZWRpYXRpb24KICAgYW5kIE1pdGlnYXRpb24sIGFuZCBFbmRwb2ludCBJbmZvcm1hdGlv biBBbmFseXNpcyBhbmQgUmVwb3J0aW5nLgoKICAgUmVtb3ZlZCBSZXF1aXJlbWVudHMgTGFuZ3Vh Z2Ugc2VjdGlvbiBhbmQgcmZjMjExOSByZWZlcmVuY2UuCgogICBSZW1vdmVkIHVudXNlZCByZWZl cmVuY2VzICh3aGljaCBlbmRlZCB1cCBiZWluZyBhbGwgcmVmZXJlbmNlcykuCgo2LjYuICAtMDAt IHRvIC0wMS0KCiAgIG8gIFdvcmsgb24gdGhpcyByZXZpc2lvbiBoYXMgYmVlbiBmb2N1c2VkIG9u IGRvY3VtZW50IGNvbnRlbnQKICAgICAgcmVsYXRpbmcgcHJpbWFyaWx5IHRvIHVzZSBvZiBhc3Nl dCBtYW5hZ2VtZW50IGRhdGEgYW5kIGZ1bmN0aW9ucy4KCiAgIG8gIE1hZGUgc2lnbmlmaWNhbnQg dXBkYXRlcyB0byBzZWN0aW9uIDMgaW5jbHVkaW5nOgoKICAgICAgKiAgUmV3b3JrZWQgaW50cm9k dWN0b3J5IHRleHQuCgogICAgICAqICBSZXBsYWNlZCB0aGUgc2luZ2xlIGV4YW1wbGUgd2l0aCBt dWx0aXBsZSB1c2UgY2FzZXMgdGhhdCBmb2N1cwogICAgICAgICBvbiBtb3JlIGRpc2NyZXRlIHVz ZXMgb2YgYXNzZXQgbWFuYWdlbWVudCBkYXRhIHRvIHN1cHBvcnQKCgoKCldhbHRlcm1pcmUgJiBI YXJyaW5ndG9uICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDI0 XQoMCkludGVybmV0LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vz c21lbnQgRmVicnVhcnkgMjAxNAoKCiAgICAgICAgIGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSBpbnZl bnRvcnksIGFuZCBjb25maWd1cmF0aW9uIG1hbmFnZW1lbnQKICAgICAgICAgdXNlIGNhc2VzLgoK ICAgICAgKiAgRm9yIG9uZSBvZiB0aGUgdXNlIGNhc2VzLCBhZGRlZCBtYXBwaW5nIHRvIGZ1bmN0 aW9uYWwKICAgICAgICAgY2FwYWJpbGl0aWVzIHVzZWQuICBJZiBwb3B1bGFyLCB0aGlzIHdpbGwg YmUgYWRkZWQgdG8gdGhlIG90aGVyCiAgICAgICAgIHVzZSBjYXNlcyBhcyB3ZWxsLgoKICAgICAg KiAgQWRkaXRpb25hbCB1c2UgY2FzZXMgd2lsbCBiZSBhZGRlZCBpbiB0aGUgbmV4dCByZXZpc2lv bgogICAgICAgICBjYXB0dXJpbmcgYWRkaXRpb25hbCBkaXNjdXNzaW9uIGZyb20gdGhlIGxpc3Qu CgogICBvICBNYWRlIHNpZ25pZmljYW50IHVwZGF0ZXMgdG8gc2VjdGlvbiA0IGluY2x1ZGluZzoK CiAgICAgICogIFJlbmFtZWQgdGhlIHNlY3Rpb24gaGVhZGluZyBmcm9tICJVc2UgQ2FzZXMiIHRv ICJGdW5jdGlvbmFsCiAgICAgICAgIENhcGFiaWxpdGllcyIgc2luY2UgdXNlIGNhc2VzIGFyZSBj b3ZlcmVkIGluIHNlY3Rpb24gMy4gIFRoaXMKICAgICAgICAgc2VjdGlvbiBub3cgZXh0cmFwb2xh dGVzIHNwZWNpZmljIGZ1bmN0aW9ucyB0aGF0IGFyZSBuZWVkZWQgdG8KICAgICAgICAgc3VwcG9y dCB0aGUgdXNlIGNhc2VzLgoKICAgICAgKiAgU3RhcnRlZCB3b3JrIHRvIGZsYXR0ZW4gdGhlIHNl Y3Rpb24sIG1vdmluZyBzZWxlY3Qgc3Vic2VjdGlvbnMKICAgICAgICAgdXAgZnJvbSB1bmRlciBh c3NldCBtYW5hZ2VtZW50LgoKICAgICAgKiAgUmVtb3ZlZCB0aGUgc3Vic2VjdGlvbnMgZm9yOiBB c3NldCBEaXNjb3ZlcnksIEVuZHBvaW50CiAgICAgICAgIENvbXBvbmVudHMgYW5kIEFzc2V0IENv bXBvc2l0aW9uLCBBc3NldCBSZXNvdXJjZXMsIGFuZCBBc3NldAogICAgICAgICBMaWZlIEN5Y2xl LgoKICAgICAgKiAgUmVuYW1lZCB0aGUgc3Vic2VjdGlvbiAiQXNzZXQgUmVwcmVzZW50YXRpb24g UmVjb25jaWxpYXRpb24iIHRvCiAgICAgICAgICJEZWNvbmZsaWN0aW9uIG9mIEFzc2V0IElkZW50 aXRpZXMiLgoKICAgICAgKiAgRXhwYW5kZWQgdGhlIHN1YnNlY3Rpb25zIGZvcjogQXNzZXQgSWRl bnRpZmljYXRpb24sIEFzc2V0CiAgICAgICAgIENoYXJhY3Rlcml6YXRpb24sIGFuZCBEZWNvbmZs aWN0aW9uIG9mIEFzc2V0IElkZW50aXRpZXMuCgogICAgICAqICBBZGRlZCBhIG5ldyBzdWJzZWN0 aW9uIGZvciBBc3NldCBUYXJnZXRpbmcuCgogICAgICAqICBNb3ZlZCByZW1haW5pbmcgc2VjdGlv bnMgdG8gIk90aGVyIFVuZWRpdGVkIENvbnRlbnQiIGZvciBmdXR1cmUKICAgICAgICAgdXBkYXRp bmcuCgo2LjcuICBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTA1IHRvIGRyYWZ0LWll dGYtc2FjbS11c2UtY2FzZXMtMDAKCiAgIG8gIFRyYW5zaXRpb25lZCBmcm9tIGluZGl2aWR1YWwg SS9EIHRvIFdHIEkvRCBiYXNlZCBvbiBXRyBjb25zZW5zdXMKICAgICAgY2FsbC4KCiAgIG8gIEZp eGVkIGEgbnVtYmVyIG9mIHNwZWxsaW5nIGVycm9ycy4gIFRoYW5rIHlvdSBFcmlrIQoKICAgbyAg QWRkZWQga2V5d29yZHMgdG8gdGhlIGZyb250IG1hdHRlci4KCiAgIG8gIFJlbW92ZWQgdGhlIHRl cm1pbm9sb2d5IHNlY3Rpb24gZnJvbSB0aGUgZHJhZnQuICBUZXJtcyBoYXZlIGJlZW4KICAgICAg bW92ZWQgdG86IGRyYWZ0LWRiaC1zYWNtLXRlcm1pbm9sb2d5LTAwCgogICBvICBSZW1vdmVkIHJl cXVpcmVtZW50cyB0byBiZSBtb3ZlZCBpbnRvIGEgbmV3IEkvRC4KCgoKV2FsdGVybWlyZSAmIEhh cnJpbmd0b24gIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMjVd CgwKSW50ZXJuZXQtRHJhZnRFbnRlcnByaXNlIFVzZSBDYXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNz bWVudCBGZWJydWFyeSAyMDE0CgoKICAgbyAgRXh0cmFjdGVkIHRoZSBmdW5jdGlvbmFsaXR5IGZy b20gdGhlIGV4YW1wbGVzIGFuZCBtYWRlIHRoZQogICAgICBleGFtcGxlcyBsZXNzIHByb21pbmVu dC4KCiAgIG8gIFJlbmFtZWQgIkZ1bmN0aW9uYWwgQ2FwYWJpbGl0aWVzIGFuZCBSZXF1aXJlbWVu dHMiIHNlY3Rpb24gdG8gIlVzZQogICAgICBDYXNlcyIuCgogICAgICAqICBSZW9yZ2FuaXplZCB0 aGUgIkFzc2V0IE1hbmFnZW1lbnQiIHN1Yi1zZWN0aW9uLiAgQWRkZWQgbmV3IHRleHQKICAgICAg ICAgdGhyb3VnaG91dC4KCiAgICAgICAgICsgIFJlbmFtZWQgYSBmZXcgc3ViLXNlY3Rpb24gaGVh ZGluZ3MuCgogICAgICAgICArICBBZGRlZCB0ZXh0IHRvIHRoZSAiQXNzZXQgQ2hhcmFjdGVyaXph dGlvbiIgc3ViLXNlY3Rpb24uCgogICBvICBSZW5hbWVkICJTZWN1cml0eSBDb25maWd1cmF0aW9u IE1hbmFnZW1lbnQiIHRvICJFbmRwb2ludAogICAgICBDb25maWd1cmF0aW9uIE1hbmFnZW1lbnQi LiAgTm90IHN1cmUgaWYgdGhlICJzZWN1cml0eSIgZGlzdGluY3Rpb24KICAgICAgaXMgaW1wb3J0 YW50LgoKICAgICAgKiAgQWRkZWQgbmV3IHNlY3Rpb25zLCBwYXJ0aWFsbHkgaW50ZWdyYXRlZCBl eGlzdGluZyBjb250ZW50LgoKICAgICAgKiAgQWRkaXRpb25hbCB0ZXh0IGlzIG5lZWRlZCBpbiBh bGwgb2YgdGhlIHN1Yi1zZWN0aW9ucy4KCiAgIG8gIENoYW5nZWQgIlNlY3VyaXR5IENoYW5nZSBN YW5hZ2VtZW50IiB0byAiRW5kcG9pbnQgUG9zdHVyZSBDaGFuZ2UKICAgICAgTWFuYWdlbWVudCIu ICBBZGRlZCBuZXcgc2tlbGV0YWwgb3V0bGluZSBzZWN0aW9ucyBmb3IgZnV0dXJlCiAgICAgIHVw ZGF0ZXMuCgo2LjguICB3YWx0ZXJtaXJlIC0wNC0gdG8gLTA1LQoKICAgbyAgQXJlIHdlIGluY2x1 ZGluZyB1c2VyIGFjdGl2aXRpZXMgYW5kIGJlaGF2aW9yIGluIHRoZSBzY29wZSBvZiB0aGlzCiAg ICAgIHdvcms/ICBUaGF0IHNlZW1zIHRvIGJlIGxheWVyIDggc3R1ZmYsIGFwcHJvcHJpYXRlIHRv IGFuIElEUy9JUFMKICAgICAgYXBwbGljYXRpb24sIG5vdCBJbnRlcm5ldCBzdHVmZi4KCiAgIG8g IEkgcmVtb3ZlZCB0aGUgcmVmZXJlbmNlcyB0byB3aGF0IHRoZSBXRyB3aWxsIGRvIGJlY2F1c2Ug dGhpcwogICAgICBiZWxvbmdzIGluIHRoZSBjaGFydGVyLCBub3QgdGhlIChwb3RlbnRpYWxseSBs b25nLWxpdmVkKSB1c2UgY2FzZXMKICAgICAgZG9jdW1lbnQuICBJIHJlbW92ZWQgbWVudGlvbiBv ZiBjaGFydGVyIG9iamVjdGl2ZXMgYmVjYXVzZSB0aGUKICAgICAgY2hhcnRlciBtYXkgZ28gdGhy b3VnaCBtdWx0aXBsZSBpdGVyYXRpb25zIG92ZXIgdGltZTsgdGhlcmUgaXMgYQogICAgICB3ZWJz aXRlIGZvciBob3N0aW5nIHRoZSBjaGFydGVyOyB0aGlzIGRvY3VtZW50IGlzIG5vdCB0aGUgY29y cmVjdAogICAgICBwbGFjZSBmb3IgdGhhdCBkaXNjdXNzaW9uLgoKICAgbyAgSSBtb3ZlZCB0aGUg ZGlzY3Vzc2lvbiBvZiBOSVNUIHNwZWNpZmljYXRpb25zIHRvIHRoZQogICAgICBhY2tub3dsZWRn ZW1lbnRzIHNlY3Rpb24uCgogICBvICBSZW1vdmVkIHRoZSBwb3J0aW9uIG9mIHRoZSBpbnRyb2R1 Y3Rpb24gdGhhdCBkZXNjcmliZXMgdGhlCiAgICAgIGNoYXB0ZXJzOyB3ZSBoYXZlIGEgdGFibGUg b2YgY29uY2VwdHMsIGFuZCB0aGUgZXhpc3RpbmcgdGV4dAogICAgICBzZWVtZWQgcmVkdW5kYW50 LgoKICAgbyAgUmVtb3ZlZCBtYXJrZXRpbmcgY2xhaW1zLCB0byBmb2N1cyBvbiB0ZWNobmljYWwg Y29uY2VwdHMgYW5kCiAgICAgIHRlY2huaWNhbCBhbmFseXNpcywgdGhhdCB3b3VsZCBlbmFibGUg c3Vic2VxdWVudCBlbmdpbmVlcmluZwogICAgICBlZmZvcnQuCgoKCldhbHRlcm1pcmUgJiBIYXJy aW5ndG9uICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDI2XQoM CkludGVybmV0LURyYWZ0RW50ZXJwcmlzZSBVc2UgQ2FzZXMgZm9yIFNlY3VyaXR5IEFzc2Vzc21l bnQgRmVicnVhcnkgMjAxNAoKCiAgIG8gIFJlbW92ZWQgKGNvbW1lbnRlZCBvdXQgaW4gWE1MKSBV QzIgYW5kIFVDMywgYW5kIGVsaW1pbmF0ZWQgc29tZQogICAgICB0ZXh0IHRoYXQgcmVmZXJyZWQg dG8gdGhlc2UgdXNlIGNhc2VzLgoKICAgbyAgTW9kaWZpZWQgSUFOQSBhbmQgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbiBzZWN0aW9ucy4KCiAgIG8gIE1vdmVkIFRlcm1zIHRvIHRoZSBmcm9udCwgc28g d2UgY2FuIHVzZSB0aGVtIGluIHRoZSBzdWJzZXF1ZW50CiAgICAgIHRleHQuCgogICBvICBSZW1v dmVkIHRoZSAiS2V5IENvbmNlcHRzIiBzZWN0aW9uLCBzaW5jZSB0aGUgY29uY2VwdHMgb2YgT1JN IGFuZAogICAgICBJUk0gd2VyZSBub3Qgb3RoZXJ3aXNlIG1lbnRpb25lZCBpbiB0aGUgZG9jdW1l bnQuICBUaGlzIHdvdWxkIHNlZW0KICAgICAgbW9yZSBhcHByb3ByaWF0ZSB0byB0aGUgYXJjaCBk b2MgcmF0aGVyIHRoYW4gdXNlIGNhc2VzLgoKICAgbyAgUmVtb3ZlZCByb2xlPWVkaXRvciBmcm9t IERhdmlkIFdhbHRlcm1pcmUncyBpbmZvLCBzaW5jZSB0aGVyZSBhcmUKICAgICAgdGhyZWUgZWRp dG9ycyBvbiB0aGUgZG9jdW1lbnQuICBUaGUgZWRpdG9yIGlzIG1vc3QgaW1wb3J0YW50IHdoZW4K ICAgICAgb25lIHBlcnNvbiB3cml0ZXMgdGhlIGRvY3VtZW50IHRoYXQgcmVwcmVzZW50cyB0aGUg d29yayBvZgogICAgICBtdWx0aXBsZSBwZW9wbGUuICBXaGVuIHRoZXJlIGFyZSB0aHJlZSBlZGl0 b3JzLCB0aGlzIHJvbGUgbWFya2luZwogICAgICBpc24ndCBuZWNlc3NhcnkuCgogICBvICBNb2Rp ZmllZCB0ZXh0IHRvIGRlc2NyaWJlIHRoYXQgdGhpcyB3YXMgc3BlY2lmaWMgdG8gZW50ZXJwcmlz ZXMsCiAgICAgIGFuZCB0aGF0IGl0IHdhcyBleHBlY3RlZCB0byBvdmVybGFwIHdpdGggc2Vydmlj ZSBwcm92aWRlciB1c2UKICAgICAgY2FzZXMsIGFuZCBkZXNjcmliZWQgdGhlIGNvbnRleHQgb2Yg dGhpcyBzY29wZWQgd29yayB3aXRoaW4gYQogICAgICBsYXJnZXIgY29udGV4dCBvZiBwb2xpY3kg ZW5mb3JjZW1lbnQsIGFuZCB2ZXJpZmljYXRpb24uCgogICBvICBUaGUgZG9jdW1lbnQgaGFkIGFz c2V0IG1hbmFnZW1lbnQsIGJ1dCB0aGUgY2hhcnRlciBtZW50aW9uZWQKICAgICAgYXNzZXQsIGNo YW5nZSwgY29uZmlndXJhdGlvbiwgYW5kIHZ1bG5lcmFiaWxpdHkgbWFuYWdlbWVudCwgc28gSQog ICAgICBhZGRlZCBzZWN0aW9ucyBmb3IgZWFjaCBvZiB0aG9zZSBjYXRlZ29yaWVzLgoKICAgbyAg QWRkZWQgdGV4dCB0byBJbnRyb2R1Y3Rpb24gZXhwbGFpbmluZyBnb2FsIG9mIHRoZSBkb2N1bWVu dC4KCiAgIG8gIEFkZGVkIHNlY3Rpb25zIG9uIHZhcmlvdXMgZXhhbXBsZSB1c2UgY2FzZXMgZm9y IGFzc2V0IG1hbmFnZW1lbnQsCiAgICAgIGNvbmZpZyBtYW5hZ2VtZW50LCBjaGFuZ2UgbWFuYWdl bWVudCwgYW5kIHZ1bG5lcmFiaWxpdHkKICAgICAgbWFuYWdlbWVudC4KCjcuICBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzCgogICBbUkZDMzQ0NF0gIFByYXMsIEEuIGFuZCBKLiBTY2hvZW53YWVsZGVy LCAiT24gdGhlIERpZmZlcmVuY2UgYmV0d2VlbgogICAgICAgICAgICAgIEluZm9ybWF0aW9uIE1v ZGVscyBhbmQgRGF0YSBNb2RlbHMiLCBSRkMgMzQ0NCwgSmFudWFyeQogICAgICAgICAgICAgIDIw MDMuCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIERhdmlkIFdhbHRlcm1pcmUKICAgTmF0aW9uYWwg SW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQogICAxMDAgQnVyZWF1IERyaXZl CiAgIEdhaXRoZXJzYnVyZywgTWFyeWxhbmQgIDIwODc3CiAgIFVTQQoKICAgRW1haWw6IGRhdmlk LndhbHRlcm1pcmVAbmlzdC5nb3YKCgoKV2FsdGVybWlyZSAmIEhhcnJpbmd0b24gIEV4cGlyZXMg QXVndXN0IDE5LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQtRHJhZnRF bnRlcnByaXNlIFVzZSBDYXNlcyBmb3IgU2VjdXJpdHkgQXNzZXNzbWVudCBGZWJydWFyeSAyMDE0 CgoKICAgRGF2aWQgSGFycmluZ3RvbgogICBFZmZlY3RpdmUgU29mdHdhcmUKICAgNTAgSGFyZGlu ZyBSZAogICBQb3J0c21vdXRoLCBOSCAgMDM4MDEKICAgVVNBCgogICBFbWFpbDogaWV0ZmRiaEBj b21jYXN0Lm5ldAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCldh bHRlcm1pcmUgJiBIYXJyaW5ndG9uICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAg ICAgIFtQYWdlIDI4XQo= --_004_a96d2bc02a2e487e888133f5176c90b6BLUPR09MB038namprd09pro_-- From nobody Fri Feb 14 16:30:52 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD31A00DE for ; Fri, 14 Feb 2014 16:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmsryVBRRZzT for ; Fri, 14 Feb 2014 16:30:44 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5D1A00A5 for ; Fri, 14 Feb 2014 16:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22923; q=dns/txt; s=iport; t=1392424242; x=1393633842; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MYBScfhGG6kppmkdBJwX18hpOf3u2fpaZ3SyzdtI5O4=; b=GPgdBGjXw4VS899WtjZ6X2zK6GG/tVYb1X+KwSxqOF111RRMulSX0tjI bW6LrnQmz38Tz+kWWntrLrFA23ijczLk0MmGjFxOeszJQgpHIiRB2sL3Q XCGyhJQMixdwmq4dJeTLnGvEkO8oyTZPDafe2IvghliKPGcSarUXmz+at w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJq0/lKtJV2Z/2dsb2JhbABPCoMGOFe/MoEXFnSCJQEBAQQBAQEXIDQEEwYBCBEEAQEBFQkJLgsUCQgCBAESiAUNyGsTBI4XBgsBVwYEhC4EmCySI4MtgXE5 X-IronPort-AV: E=Sophos;i="4.95,848,1384300800"; d="scan'208";a="20635987" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 15 Feb 2014 00:30:40 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1F0Ue5j022825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 00:30:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 18:30:40 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "Waltermire, David A." , Stephen Hanna , Gunnar Engelbach , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: AQHPKeUmiew5+LVHAUCWf9mUoqqSNA== Date: Sat, 15 Feb 2014 00:30:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.48] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A219F78AF9F424DBC4FBC5BCB6F6EE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/pR7IOmtyr4e0OIpoTtXv2lSVnfo Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:30:50 -0000 Hi Dave: Thanks for putting more clarity, I have some comments and questions below: On 2/11/14 4:13 PM, "Waltermire, David A." wrote: >I'd like to get the discussion around this topic to a point where I have >clear editorial direction on what text we want included in the updated >use case draft for this Friday's submission cutoff deadline. > >Based on the mailing list discussions to date, I'd like to propose the >following categories of security automation data for inclusion in the use >cases draft: Guidance, Endpoint/Asset Attribute Data, and Processing >Artifacts. > >The following sections roughly define each of the proposed categories. >For each section some insights are provided into the how the data might >be sourced and how often it may change. I have also included examples of >the classes of information for each category with mappings to the use >cases and building blocks they support to insure we have the necessary >coverage. > >To move forward I need answers to the following questions: > >1) Do you like these groupings? If not, is there a better set of >groupings? [NCW] It is an improvement, but please see my further comments and questions below. >2) Do you like the labels for each of the groups? If not, do you have a >better label(s)? [NCW] I'm OK with the current groupings, though I'd like to keep the model as simple as possible. >3) Are there other types of content that should be included? >4) What level of detail should be included in the use cases draft >regarding this discussion? What I have below is likely too much detail. [NCW] I agree with Steve H. that this is probably too much details for the use cases. =20 > >Thanks, >Dave > >Guidance: >------------ >The term "guidance" was proposed by Steve Hanna and was supported by >Gunnar Engelbach on the list. Steve proposed that this concept >encompasses "attribute identifiers, lists of attributes that are to be >collected and when and perhaps how, and policies about what attribute >values are acceptable for different kinds or groups of endpoints. This >indicates that these things (and maybe others to be added later) guide >the attribute collection and evaluation process." I would also add that >this should include instructions supporting data-driven evaluation >processes. > >This data tends to change in units of months and days. In cases where >assessments are made more dynamic, it may be necessary to handle changes >in the scope of hours or minutes. This data will typically be provided by >large organizations, product vendors, and some 3rd-parties. Thus, it will >tend to be shared across large enterprises and customer communities. In >some cases access may be controlled to specific authenticated users. In >other cases, the data may be provided broadly with little to no access >control. > >This would include: > >- Applicability Statements: Data the identifies the conditional >applicability of an assessment (and related assessment "guidance") based >on automated collection of endpoint posture attribute values and other >endpoint characterizations. > + Endpoint Identification and Assessment Planning BB: Identify >Endpoint Targets - This supports the targeting concept allowing >characterizations and collected posture attribute values to be evaluated >to determine what set of endpoints should be assessed. > >- Collection Instructions: Data that drives the identification of the set >of posture attributes needed to perform an assessment and the collection >of posture attributes. > + Endpoint Identification and Assessment Planning BB: Posture >Attribute Identification - Used to determine the set of posture >attributes for which values must be collected (or retrieved) to support >the evaluation. > + Endpoint Posture Attribute Value Collection BB: Collection Content >Acquisition - Data is retrieved based on its relationship to the >assessment and other applicability concepts to drive collection >activities. > + Endpoint Posture Attribute Value Collection BB: Posture Attribute >Value Collection - Directives on how the posture attributes should be >collected. This may include: events to monitor, scheduling info, >instructions for using specific models/protocols, etc. [NCW] I am not seeing strong distinctions of the Applicability Statements vs. Collection Instructions. As I see this converged through an endpoint profile that defines the attributes to be assessed for that particular endpoint. Given that profile, I would see how both applicability and collection duties are fulfilled. > >- Evaluation instructions: Data the identifies what endpoint posture >attribute values are to be evaluated and how this evaluation should be >performed. > + Endpoint Identification and Assessment Planning BB: Posture >Attribute Identification - Use to determine the set of posture attributes >for which values are required for evaluation. > + Posture Evaluation BB: Evaluation Content Acquisition - Data is >retrieved based on its relationship to the assessment and other >applicability concepts to drive evaluation activities. > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs the >evaluation of collected endpoint posture attribute values. This will >likely include comparison operators and logical constructs. Additional >instructions might indicate the required result output format. > >Our information model will need to relate the concepts of applicability >statements, collection instructions, and evaluation instructions in >support of assessment activities. [NCW] Why couldn't the evaluation instruction be extracted from the endpoint assessment profile? > >Endpoint/Asset Attribute Data: >-------------------------------------- > >This category includes contextual metadata pertaining to endpoints and >the assets that they are composed of (e.g., hardware, software, >accounts), and collected endpoint posture attributes, their associated >values, and related context. > >This data tends to change in units of days, minutes, a seconds with >posture attribute values typically changing more frequently than endpoint >characterizations. This data tends to be organizationally and endpoint >specific, with specific operational groups of endpoints tending to >exhibit similar attribute profiles. This data will generally not be >shared outside an organizational boundary and will generally require >authentication with specific access controls. > >This would include: > >- Characterizations of endpoints: Endpoint metadata that describes the >endpoint type, organizationally expected function/role, etc. > + Endpoint Identification and Assessment Planning BB: Endpoint >Characterization - Gathered through automated posture attribute >collection, manual data entry/query, and interactions with other data >stores. > >- Collected Posture Attributes: Posture attributes and associated values >collected from endpoints representing hardware, software inventory, >configurations, accounts/privileges, and other aspects of endpoint state. > + Endpoint Identification and Assessment Planning BB: Endpoint >Component Inventory - This provides context to identify what posture >attributes should be collected as part of the assessment based on the >current endpoint posture (e.g., what software is installed). > + Endpoint Posture Attribute Value Collection BB: Posture Attribute >Value Collection - For each targeted endpoint, the set of collected >posture attributes and associated values. The result of collection. > + Posture Evaluation BB: Posture Attribute Value Query - The >retrieval of a set of previously collected posture attributes and >associated values. This may not be required if collected data is fed >directly to an evaluator after collection. > >An important dimension here may be the separation between actual and >expected posture attribute values. It may be possible to express guidance >in a way that allows expected values to parameterized. In this case it >will be necessary to allow for organizationally expected values to be >associated with defined guidance (perhaps provided by a different party). > >Our information model will need to relate the concepts of endpoint >characterizations and collected posture information to the types of >guidance data. > >Processing Artifacts: >------------------------- > >This type of data is generated by and is specific to an individual >assessment process. This data may be used as part of the interactions >between SACM architectural components to drive and coordinate collection >and evaluation activities. Its lifespan will be bounded by the lifespan >of the assessment. It may also be exchanged and stored to provide >historic context around an assessment activity. > >This would include: > >- Endpoint Targets: An identified set of endpoints for which an >assessment should be performed. > + Endpoint Identification and Assessment Planning BB: Identify >Endpoint Targets - The endpoints targeted for an assessment. > >- Identified Posture Attributes > + Endpoint Identification and Assessment Planning BB: Posture >Attribute Identification - The required posture attributes that need to >be collected to perform the evaluation. > >- Assessment Results: The resulting output generated by the evaluation >process. > + Posture Evaluation BB: Posture Attribute Evaluation - The results >produced through the comparison of actual collected posture attribute > values against their expected state. The specific output an >evaluation criteria may be specified by the required evaluation >instructions. [NCW] Is it correct for me to conclude that "Processing artifacts" are differentiated from "Endpoint attribute data" in that "Processing artifacts" are basically the types of attributes that result from an "evaluation result"? My definition of "evaluation result" could be the processing result based on success in (endpoint) attribute collection or assessment (and the assessment could have been affected from 1 or more [endpoint] attributes)? > >Our information model will need to relate these concepts to those >provided in the other two categories. I know this is not saying much, but >I am tired and ready to end this email. ;-) > >> -----Original Message----- >> From: Stephen Hanna [mailto:shanna@juniper.net] >> Sent: Wednesday, February 05, 2014 10:48 PM >> To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis (pkampana); >> sacm@ietf.org >> Subject: RE: [sacm] Types of content >>=20 >> Gunnar Engelbach wrote: >> > So "Guidance" is input and "collected attributes" is the immediate >> > product? >>=20 >> Right. At least, that's one way of describing it. >> I'm thinking that guidance would include all the things that Dave was >> previously calling "content". >>=20 >> > That works. And is line with common usage. >>=20 >> Good! I'm glad to hear that it makes sense to you. >>=20 >> > And for the final result of applying the collected attributes to the >> > guidance, how about "assessment results?" >>=20 >> Yes, I like that also. >>=20 >> > Is there a need for anything more granular? >>=20 >> Probably eventually. But there also seems to be a need for broad terms >>since >> people want to be able to put all the "guidance" into one repository >> (perhaps) and have a different kind of repository for "collected >>attributes" >> and maybe also "assessment results". >>=20 >> > Mention of other terms commonly used for the same thing? >>=20 >> Maybe. Listing alternative terms in common usage today can be confusing >> since different people may use those terms differently. >>=20 >> Thanks, >>=20 >> Steve >>=20 >> > >> > >> > What I frequently see: >> > >> > Input: >> > Guidance >> > Content >> > Checklist >> > Questionnaire >> > Data stream >> > Benchmark >> > Definitions >> > >> > >> > Product: >> > Collected Attributes >> > System Characteristics >> > Assessment Results >> > Posture >> > >> > >> > >> > >> > On 2/5/2014 9:13 PM, Stephen Hanna wrote: >> > > The terms "content" and "data" are just too general. "SA content" >> > > isn't much better. It seems to include any kind of data related to >> > > security automation. In the long run, that might include lots of >> > > things like vulnerability reports and alerts that an intrusion has >> > > been detected and remediation or mitigation instructions. >> > > Also reports on endpoint compliance and attributes that have been >> > > collected from endpoints and maybe persisted. It's just not useful >> > > to use one term for all those kinds of things. >> > > >> > > I think that we need a new, more specific term for the things that >> > > Dave described below: attribute identifiers, lists of attributes >> > > that are to be collected and when and perhaps how, and policies >> > > about what attribute values are acceptable for different kinds or >> > > groups of endpoints. I suggest that we use the collective term >> > > "guidance" for these things. This indicates that these things (and >> > > maybe others to be added >> > > later) guide the attribute collection and evaluation process. >> > > >> > > We also need to have a term for attribute values that have been >> > > collected from endpoints. I vote for "collected attributes". >> > > These attributes might be persisted (stored) or maybe not. >> > > Either way, they are attribute values that have been collected from >> > > endpoints. >> > > >> > > Thanks, >> > > >> > > Steve >> > > >> > >> -----Original Message----- >> > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar >> > Engelbach >> > >> Sent: Wednesday, February 05, 2014 7:37 PM >> > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis >> > (pkampana); >> > >> sacm@ietf.org >> > >> Subject: Re: [sacm] Types of content >> > >> >> > >> >> > >> I would prefer to reserve the term "content" for the instructional >> > >> documentation. That is, the documents that cause an action, be it >> > >> legislation, prose guidance, or a set of machine instructions that >> > >> implement that guidance. >> > >> >> > >> We typically use "system characteristics" when referring to >> > collected >> > >> items, and variations on "endpoint attributes" has been used >> > frequently >> > >> on this list. System characteristics are the product of applying >> > >> content to an endpoint. >> > >> >> > >> Collectively it's all data. Is there a desire to have a general >> > term >> > >> for all data that could flow through a SACM implementation but is >> > >> specific to SACM? >> > >> >> > >> >> > >> Also, while I agree with the need to allow the ability to persist >> > >> collected data items (and the results of posture evaluations), I >> > don't >> > >> see that as a requirement. >> > >> >> > >> >> > >> >> > >> >> > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: >> > >>> Dictionaries of posture attributes was not intended to include >> > >> attribute >> > >>> values. IETF examples of this concept might include attributes in >> > >>> a >> > >> MIB >> > >>> or a NETMOD model. >> > >>> >> > >>> I agree that we need to "persist" posture attribute values. I have >> > >>> always been on the fence personally about calling collection and >> > >>> evaluation results "content". I agree 100% that we need to be >> > crystal >> > >>> clear about what we mean when we use the terms "content" and >> > "content >> > >>> repository". If we choose to lump all of this together as >> > "content", >> > >> we >> > >>> will need to include some discussion in the use case document >> > >>> contrasting different types of content to drive discussion of >> > content >> > >>> type-specific requirements. >> > >>> >> > >>> I also personally like Ira's feedback on using a more specific >> > >> term(s) >> > >>> instead of the more general "content". >> > >>> >> > >>> I also share the same personal view around interacting with stores >> > of >> > >>> collected posture attribute values and evaluation results. The >> > larger >> > >>> data volumes and rate of change will likely require different >> > >>> approaches. I also believe that the temporal nature of this data, >> > the >> > >>> need to persist historic information, will be more significant >> > >>> than other types of data that we may call "content". >> > >>> >> > >>> Are there other opinions on this? Does anyone feel strongly that >> > >>> collected posture attribute values and evaluation results SHOULD >> > NOT >> > >> be >> > >>> considered content? >> > >>> >> > >>> Thanks, >> > >>> >> > >>> Dave >> > >>> >> > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] >> > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM >> > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; >> > >> sacm@ietf.org >> > >>> *Subject:* RE: Types of content >> > >>> >> > >>> Would "dictionaries of posture attributes" include attribute >> > >>> values >> > >> that >> > >>> have been collected from endpoints? >> > >>> >> > >>> We want to have the ability to collect attribute values from >> > >> endpoints >> > >>> and "persist" them, as described in section 2.1.3. So we'll need >> > >>> to >> > >> have >> > >>> a repository for collected and persisted attribute values. >> > >>> >> > >>> If collected endpoint attribute values are considered content, >> > let's >> > >> say >> > >>> so. If not, let's say that explicitly. >> > >>> >> > >>> My personal view is that collected endpoint attribute values >> > >>> should >> > >> be >> > >>> considered content. They may be a different kind of content from >> > the >> > >>> others due to larger volume and higher change rate. For that >> > reason, >> > >>> people may choose to put them into a different repository and >> > >>> maybe >> > >> even >> > >>> use a different query protocol for that repository to munge the >> > large >> > >>> quantities of data. But they're still content. >> > >>> >> > >>> Thanks, >> > >>> >> > >>> Steve >> > >>> >> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Panos >> > >>> Kampanakis (pkampana) >> > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM >> > >>> *To:* Waltermire, David A.; sacm@ietf.org >> > >>> *Subject:* Re: [sacm] Types of content >> > >>> >> > >>> Sounds like a good summary of what "content" could mean. >> > >>> >> > >>> Panos >> > >>> >> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of >> > *Waltermire, >> > >>> David A. >> > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM >> > >>> *To:* sacm@ietf.org >> > >>> *Subject:* [sacm] Types of content >> > >>> >> > >>> I'm working through the UC draft addressing discussion items from >> > >>> yesterday and the previous comments we have received on the list >> > >>> on >> > - >> > >> 05. >> > >>> >> > >>> Related to section 2.1.1, we have had many previous discussions >> > >> around >> > >>> the notional idea of content. There has been general agreement >> > >>> that >> > >> we >> > >>> need to be more specific. Please find below an attempt to put some >> > >>> "bounds" around different types of content. >> > >>> >> > >>> Is this hitting the mark, or do we need to say something >> > >> more/different? >> > >>> >> > >>> The following is a snippet from a possible update to section 2.1.1 >> > >> with >> > >>> some additional description: >> > >>> >> > >>> I'd appreciate any thoughts, concerns, objections before I include >> > >> the >> > >>> changes in the draft. >> > >>> >> > >>> Thanks, >> > >>> >> > >>> Dave >> > >>> >> > >>> 2.1.1. Define, Publish, Query and Retrieve Content >> > >>> >> > >>> This use case describes the need for content to be defined >> > >>> and >> > >>> >> > >>> published to a data store, as well as queried and retrieved >> > from >> > >> the >> > >>> >> > >>> data store for the explicit use of posture collection and >> > >> evaluation. >> > >>> >> > >>> The term "content" is a general concept that refers to any >> > data >> > >>> >> > >>> expression that may be used as part of the process of >> > collecting >> > >> and >> > >>> >> > >>> evaluating endpoint posture. Typical types of content >> > include: >> > >>> >> > >>> o Dictionaries of posture attributes (e.g. software >> > >> installation, >> > >>> >> > >>> configuration, privileges) that may be collected from a >> > given >> > >>> >> > >>> endpoint type that relate to installed hardware, installed >> > >>> >> > >>> software, software configurations, accounts, privileges, >> > and >> > >> other >> > >>> >> > >>> operational state. >> > >>> >> > >>> o Expressions that provide instructions for using a specific >> > >> API, >> > >>> >> > >>> management protocol, or other mechanisms to collect >> > specific >> > >>> >> > >>> posture attributes from specific device types. >> > >>> >> > >>> o Policies that define the selected posture attributes for >> > which >> > >>> >> > >>> values must be collected to support one or more posture >> > >>> >> > >>> assessments. This may include information that targets >> > >> collection >> > >>> >> > >>> to a specific set of endpoints and instructions on the >> > >> frequency >> > >>> >> > >>> and/or change events (e.g., configuration changes, >> > >>> software >> > >>> >> > >>> installation/uninstallation, account/privilege >> > modifications) >> > >> that >> > >>> >> > >>> will trigger collection of one or more posture attributes. >> > >>> >> > >>> o Policies that define the logical criteria to evaluate >> > >> collected >> > >>> >> > >>> posture attribute values to determine if they meet >> > >> organizational >> > >>> >> > >>> requirements. This may include information that targets >> > >>> >> > >>> evaluation to a specific set of endpoints. >> > >>> >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> sacm mailing list >> > >>> sacm@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/sacm >> > >>> >> > >> _______________________________________________ >> > >> sacm mailing list >> > >> sacm@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/sacm >> > >> >> > > >> > > >> > >>=20 > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From nobody Fri Feb 14 16:53:29 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316D71A00A7 for ; Fri, 14 Feb 2014 16:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSQnnv_3EvMJ for ; Fri, 14 Feb 2014 16:53:23 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6441A001D for ; Fri, 14 Feb 2014 16:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24008; q=dns/txt; s=iport; t=1392425602; x=1393635202; h=from:to:subject:date:message-id:mime-version; bh=oCnMkgxbCKtHQitSoWaZsoDdsWqUlDv/chyMgbwZCmA=; b=lvoFzZwGK1U1dSKi3k21qh1CL2pEbCQvZ4PzDqhLKTVJhIjPFfyt8Msy uVjNFJU6Tvtu1SEQQTMlsnyr+3pzM9Y8Ua24HA1S+v+mKa4HEOgwl/bYv TcEvei8hjaDmOmllEXGyhj3enrPte1GgSPVQgRucyGNGPHnmIsGwINR6H 8=; X-Files: draft-camwinget-sacm-requirements-03.txt : 16138 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMTAO+5/lKtJV2b/2dsb2JhbABZgkJEOFeIFbg0FnSCHBCBCwELAQ42MBcQBBMOh3cNmAKwaxeOFxEBBwSFBASLUoRuhAODaYEykHGDLYFpAQcXBhw X-IronPort-AV: E=Sophos;i="4.95,848,1384300800"; d="txt'?scan'208,217";a="20635890" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 15 Feb 2014 00:53:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1F0rLWk023064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Feb 2014 00:53:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 18:53:21 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: Updated requirements draft Thread-Index: AQHPKehRFpXzM4OrOEKJ+KBerPQdoQ== Date: Sat, 15 Feb 2014 00:53:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.48] Content-Type: multipart/mixed; boundary="_004_CF23FA7D99083ncamwingciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/fSoadlFh3ySNcCM63ihHetRVg5s Subject: [sacm] Updated requirements draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:53:27 -0000 --_004_CF23FA7D99083ncamwingciscocom_ Content-Type: multipart/alternative; boundary="_000_CF23FA7D99083ncamwingciscocom_" --_000_CF23FA7D99083ncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I also missed the I/D cutoff (and have opened a ticket with IETF secretaria= t as my submission process problems persist). But here's the draft I can speak to at the meeting=85.like Dave, I'll also = post it to data tracker once it reopens. Thanks, Nancy. --_000_CF23FA7D99083ncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <892D647DE1F3E54B8C64355C3A90C530@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I also missed the I/D cutoff (and have opened a ticket with IETF secre= tariat as my submission process problems persist).
But here's the draft I can speak to at the meeting=85.like Dave, I'll = also post it to data tracker once it reopens.

Thanks, Nancy.
--_000_CF23FA7D99083ncamwingciscocom_-- --_004_CF23FA7D99083ncamwingciscocom_ Content-Type: text/plain; name="draft-camwinget-sacm-requirements-03.txt" Content-Description: draft-camwinget-sacm-requirements-03.txt Content-Disposition: attachment; filename="draft-camwinget-sacm-requirements-03.txt"; size=16138; creation-date="Sat, 15 Feb 2014 00:53:19 GMT"; modification-date="Sat, 15 Feb 2014 00:53:19 GMT" Content-ID: <3EE68206FB7CB8499E307211D3870A53@emea.cisco.com> Content-Transfer-Encoding: base64 CgoKClNBQ00gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTi4gQ2FtLVdpbmdldApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDE1LCAyMDE0CkV4cGly ZXM6IEF1Z3VzdCAxOSwgMjAxNAoKCiAgICBTZWN1cmUgQXV0b21hdGlvbiBhbmQgQ29udGludW91 cyBNb25pdG9yaW5nIChTQUNNKSBSZXF1aXJlbWVudHMKICAgICAgICAgICAgICAgICAgZHJhZnQt Y2Ftd2luZ2V0LXNhY20tcmVxdWlyZW1lbnRzLTAzCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVu dCBkZWZpbmVzIHRoZSBzY29wZSBhbmQgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgdGhlCiAgIFNl Y3VyZSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3Jpbmcgd29ya2luZyBncm91cC4g IFRoZQogICByZXF1aXJlbWVudHMgYW5kIHNjb3BlIGFyZSBiYXNlZCBvbiB0aGUgYWdyZWVkIHVw b24gdXNlIGNhc2VzIGFuZAogICBhcmNoaXRlY3R1cmUgZGVmaW5lZC4KClN0YXR1cyBvZiBUaGlz IE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkg YWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4g IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gQXVndXN0IDE5LCAyMDE0LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChj KSAyMDE0IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9y Zy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBv ZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1 bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZy b20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0 ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJv dmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKCgoKQ2FtLVdpbmdldCAgICAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEFiYnJldmlhdGVkIFRpdGxlICAgICAgICAgICAgICBG ZWJydWFyeSAyMDE0CgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAg UmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDIKICAgICAyLjEuICBSZWZlcmVuY2UgQXJjaGl0ZWN0dXJlIE1vZGVsICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgICAgMi4yLiAgR2VuZXJhbCBTQUNNIHJlcXVpcmVt ZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDIuMy4gIFJlcXVp cmVtZW50cyBiYXNlZCBvbiBVc2UgQ2FzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUK ICAgMy4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA2CiAgIDQuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA1LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgNi4gIFJl ZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3CiAgICAgNi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDYuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgQXV0aG9yJ3MgQWRkcmVz cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3Cgox LiAgSW50cm9kdWN0aW9uCgogICBUb2RheSdzIGNoYWxsZW5nZXMgb2YgZXZvbHZpbmcgdGhyZWF0 cyBhbmQgaW1wcm92ZWQgYW5hbHl0aWNzIHRvCiAgIGFkZHJlc3Mgc3VjaCB0aHJlYXRzIGhpZ2hs aWdodCBhIG5lZWQgdG8gYXV0b21hdGUgdGhlIHNlY3VyaW5nIG9mCiAgIGJvdGggaW5mb3JtYXRp b24gYW5kIHRoZSBzeXN0ZW1zIHRoYXQgc3RvcmUsIHByb2Nlc3MgYW5kIHRyYW5zbWl0IHRoZQog ICBpbmZvcm1hdGlvbi4gIFNBQ00ncyBjaGFydGVyIGZvY3VzZXMgb24gYWRkcmVzc2luZyBzb21l IG9mIHRoZXNlCiAgIGNoYWxsZW5nZXMgaW4gYSBuYXJyb3dlciBzY29wZSBieSBib3VuZGluZyB0 aGUgdGFzayB0byBhZGRyZXNzIHVzZQogICBjYXNlcyB0aGF0IHBlcnRhaW4gdG8gdGhlIHBvc3R1 cmUgYXNzZXNzbWVudCBvZiBlbmRwb2ludHMuCgogICBUaGlzIGRvY3VtZW50IGZvY3VzZXMgb24g ZGVzY3JpYmluZyB0aGUgcmVxdWlyZW1lbnRzIGZvciBmYWNpbGl0YXRpbmcKICAgdGhlIGV4Y2hh bmdlIG9mIHBvc3R1cmUgYXNzZXNzbWVudCBpbmZvcm1hdGlvbiwgaW4gcGFydGljdWxhciwgZm9y CiAgIHRoZSB1c2UgY2FzZXMgYXMgZXhlbXBsaWZpZWQgaW4gW0ktRC5pZXRmLXNhY20tdXNlLWNh c2VzXS5BbHNvLCB0aGlzCiAgIGRvY3VtZW50IHVzZXMgdGVybWlub2xvZ3kgZGVmaW5lZCBpbiBb SS1ELmlldGYtc2FjbS10ZXJtaW5vbG9neV0uCgoyLiAgUmVxdWlyZW1lbnRzCgogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgcmVxdWlyZW1lbnRzIGJhc2VkIG9uIHRoZSBTQUNNIHVzZSBjYXNlcwog ICBkZWZpbmVkIGluIFtJLUQuaWV0Zi1zYWNtLXVzZS1jYXNlc10uICBUaGlzIHNlY3Rpb24gZGVz Y3JpYmVzIHRoZQogICByZXF1aXJlbWVudHMgdXNlZCBieSBTQUNNIHRvIGFzc2VzcyBhbmQgY29t cGFyZSBjYW5kaWRhdGUgaW5mb3JtYXRpb24KICAgbW9kZWxzIGFuZCBwcm90b2NvbHMgdG8gc3Vp dCB0aGUgYXJjaGl0ZWN0dXJlLiAgVGhlc2UgcmVxdWlyZW1lbnRzCiAgIGV4cHJlc3MgY2hhcmFj dGVyaXN0aWNzIG9yIGZlYXR1cmVzIHRoYXQgYSBjYW5kaWRhdGUgcHJvdG9jb2wgb3IgZGF0YQog ICBtb2RlbCBtdXN0IGJlIGNhcGFibGUgb2Ygb2ZmZXJpbmcgc28gYXMgdG8gZW5zdXJlIHNlY3Vy aXR5IGFuZAogICBpbnRlcm9wZXJhYmlsaXR5LgoKMi4xLiAgUmVmZXJlbmNlIEFyY2hpdGVjdHVy ZSBNb2RlbAoKICAgQSBwcm9wb3NlZCBhcmNoaXRlY3R1cmUgbW9kZWwgaXMgcHJvdmlkZWQgdG8g aGlnaGxpZ2h0IHRoZSBmdW5jdGlvbnMKICAgYW5kIGZvY3VzIGZvciBTQUNNLiAgTW9yZSBzcGVj aWZpY2FsbHkgdG8gaGlnaGxpZ2h0IHRoZSB0cmFuc3BvcnQsCiAgIHByb3RvY29scyBhbmQgZGF0 YSBtb2RlbCBieSB3aGljaDoKCiAgIG8gIEVuZHBvaW50cyBjYW0gYmUgZGlzY292ZXJlZCBmb3Ig dGhlIHB1cnBvc2Ugb2YgY29sbGVjdGlvbiBvZgogICAgICBwb3N0dXJlIGF0dHJpYnV0ZXMgKG9y IHZhbHVlcykgYnkgYSBnZW5lcmFsIGNvbGxlY3RvciwgYSBwb3N0dXJlCgoKCgpDYW0tV2luZ2V0 ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMTksIDIwMTQgICAgICAgICAgICAgICAgW1Bh Z2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQgVGl0bGUgICAg ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTQKCgogICAgICBhdHRyaWJ1dGUgY29sbGVjdG9yIG9yIGEg cG9zdHVyZSBhdHRyaWJ1dGUgZXZhbHVhdG9yLiAgVGhlCiAgICAgIGNvbW11bmljYXRpb25zIGlz IHNob3duIGFzICJBIiBpbiB0aGUgZGlhZ3JhbSBiZWxvdy4KCiAgIG8gIEFuIChQb3N0dXJlKSBB c3Nlc3NtZW50IENvbnN1bWVyICh3aGljaCBjb3VsZCBhbHNvIGJlIGEgY29sbGVjdG9yKQogICAg ICBjYW4gcmV0cmlldmUgcG9zdHVyZSBhdHRyaWJ1dGVzIGVpdGhlciBkaXJlY3RseSBmcm9tIGEg UG9zdHVyZQogICAgICBBc3Nlc3NtZW50IFJlcG9zaXRvcnkgKHNob3duIGFzIEQgYmVsb3cpIG9y IGluZGlyZWN0bHkgZnJvbSBhbgogICAgICBFdmFsdWF0b3IgKHNob3duIGFzIEIgYmVsb3cpLgoK ICAgSG93IGEgc3lzdGVtIGRldGVybWluZXMgd2hhdCBwb3N0dXJlIGF0dHJpYnV0ZXMgYXJlIHRv IGJlIGNvbGxlY3RlZAogICBvciBldmFsdWF0ZWQgaXMgb3V0IG9mIHNjb3BlIGZvciBTQUNNLgoK CgoKICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICB8IEVuZHBvaW50 ICB8IDwuLi4uQS4uLi4+IHwgRXZhbHVhdG9yIHwgPC4uLi5CLi4uLj4gIHwgQXNzZXNzbWVudCBD b25zdW1lciB8CiAgICAgICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgfCAgU2Vydmlj ZSAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t fCAgIF4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4KICAgICAgICAgICAgKy0tLS0t LS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8IEMgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgICAgIHwgRW5kcG9pbnQgIHwgPC0tLS0tKyAgICAgICAgICAgdiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVwb3NpdG9yeSAgfCAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKyAg ICAgICAgICAgRCAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg UG9zdHVyZSBBc3Nlc3NtZW50IHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICBSZXBvc2l0b3J5ICAgICB8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsKCgoKCiAgICAgICAgICAg ICAgICAgICAgICAgIFNpbXBsZSBBcmNoaXRlY3R1cmFsIE1vZGVsCgogICBUaGUgZnVuY3Rpb25h bCBjb21wb25lbnRzIGluIHRoZSBwcm9wb3NlZCBhcmNoaXRlY3R1cmUgYXJlIGRlZmluZWQKICAg YXM6CgogICBvICBFbmRwb2ludDogaXMgdGhlIGVuZHBvaW50IG9mIGludGVyZXN0IHRoYXQgaXMg cG9zdHVyZSB2YWxpZGF0ZWQuCgogICBvICBFdmFsdWF0b3IgU2VydmljZTogaXMgdGhlIHNlcnZp Y2UgdGhhdCBkZXRlcm1pbmVzIHdoYXQgcG9zdHVyZQogICAgICBhdHRyaWJ1dGVzIGl0IG11c3Qg Y29sbGVjdCBhbmQgZXZhbHVhdGUgdG8gcHJvdmlkZSBhIHBvc3R1cmUKICAgICAgYXNzZXNzbWVu dCBvZiBhbiBlbmRwb2ludC4gIEluIG9yZGVyIHRvIGV2YWx1YXRlIHBvc3R1cmUsIHRoaXMKICAg ICAgc2VydmljZSBtdXN0IGRldGVybWluZSB0aGUgcG9zdHVyZSBhdHRyaWJ1dGVzIGl0IG11c3Qg YXNzZXNzOyBpbgogICAgICBhZGRpdGlvbiwgaXQgbWF5IGFsc28gcHJvdmlkZSB0aGUgY29sbGVj dGlvbiBmdW5jdGlvbiBhcyBuZWVkZWQgdG8KICAgICAgZXZhbHVhdGUgdGhlIHBvc3R1cmUgYXR0 cmlidXRlcy4gIENvbnZlcnNlbHksIHRoaXMgc2VydmljZSBuZWVkCiAgICAgIG9ubHkgcHJvdmlk ZSB0aGUgImNvbGxlY3Rpb24iIGZ1bmN0aW9uIGlmIHRoZSBwb3N0dXJlIGF0dHJpYnV0ZQogICAg ICB2YWx1ZXMgYXJlIHRoZSByZXN1bHQgb2YgYW4gYWxyZWFkeSBkZXRlcm1pbmVkIHBvc3R1cmUg YXR0cmlidXRlCgoKCkNhbS1XaW5nZXQgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOSwg MjAxNCAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgRmVicnVhcnkgMjAxNAoKCiAgICAgIGV2 YWx1YXRpb24gKGZvciBpbnN0YW5jZSwgaWYgdGhlIGVuZHBvaW50IGNhbiBwcm92aWRlIHRoYXQK ICAgICAgaW5mb3JtYXRpb24pLgoKICAgbyAgUmVwb3NpdG9yeTogaXMgdGhlIHN0b3JhZ2UgY29t cG9uZW50IGJvdW5kIHRvIHRoZSBFdmFsdWF0b3IgdGhhdAogICAgICBjb250YWlucyB0aGUgcG9z dHVyZSBhc3Nlc3NtZW50IGluZm9ybWF0aW9uLgoKICAgbyAgUG9zdHVyZSBBc3Nlc3NtZW50IFJl cG9zaXRvcnk6IGlzIGFub3RoZXIgdHlwZSBvZiByZXBvc2l0b3J5IChvciBhCiAgICAgIENvbGxl Y3RvciB0eXBlKSB0aGF0IGhvbGRzIHBvc3R1cmUgYXNzZXNzbWVudCBpbmZvcm1hdGlvbi4gIFdo aWxlCiAgICAgIG5vdCBib3VuZCB0byB0aGUgRXZhbHVhdG9yLCBpdCBpcyBhbm90aGVyIHNvdXJj ZSBvZiBwb3N0dXJlCiAgICAgIGFzc2Vzc21lbnQgaW5mb3JtYXRpb24gKGUuZy4gYSBkYXRhIGFn Z3JlZ2F0aW9uIHBvaW50IGFnZ3JlZ2F0aW5nCiAgICAgIHBvc3R1cmUgYXNzZXNzbWVudCB3aXRo IG90aGVyIGF0dHJpYnV0ZXMpIHRoYXQgY2FuIHByb3ZpZGUKICAgICAgaW5mb3JtYXRpb24gdG8g c2VydmUgU0FDTSB1c2UgY2FzZXMuCgogICBvICBBc3Nlc3NtZW50IENvbnN1bWVyOiBpcyB0aGUg c2VydmljZSB0aGF0IHJlcXVpcmVzIHRoZSBwb3N0dXJlCiAgICAgIGFzc2Vzc21lbnRzIGluZm9y bWF0aW9uIG9mIG9uZSBvciBtb3JlIGFzc2V0cy4KCiAgIFVzaW5nIHRoaXMgYXJjaGl0ZWN0dXJh bCByZWZlcmVuY2UgbW9kZWwsIHRoZSBpbnRlcmZhY2VzLCBkYXRhIG1vZGVscwogICBhbmQgdHJh bnNwb3J0cyB1c2VkIHRvIGFmZmVjdCB0aGUgcG9zdHVyZSBhc3Nlc3NtZW50LCBlLmcuIEEgaW4g dGhlCiAgIGZpZ3VyZSBhYm92ZSBoYXZlIGFscmVhZHkgYmVlbiBkZWZpbmVkIGJ5IGRpZmZlcmVu dCBtZWNoYW5pc21zLCBmb3IKICAgZXhhbXBsZSwgYW4gSUVURiBkZWZpbmVkIG9uZSB0aHJvdWdo IE5FQS4gIEFzIHRoZSBmb2N1cyBvZiBTQUNNIGlzCiAgIHRoZSBpbmZvcm1hdGlvbiBleGNoYW5n ZSB0byBvYnRhaW4gdGhlIHBvc3R1cmUgYXNzZXNzbWVudAogICBpbmZvcm1hdGlvbiwgaXQgY2Fu IGJlIGFjaGlldmVkIHRocm91Z2ggdGhlIGludGVyZmFjZXMgc2hvd24gYXMgQi4KICAgVGhhdCBp cywgaXQgaXMgbm90IGNsZWFyIHRoYXQgdGhlcmUgaXMgYSByZXF1aXJlbWVudCBmb3IgdGhlCiAg IEFzc2Vzc21lbnQgQ29uc3VtZXIgdG8gdGFwIGRpcmVjdGx5IGludG8gdGhlIFJlcG9zaXRvcnku ICBTaW1pbGFybHksCiAgIGl0IGlzIG5vdCBjbGVhciB0aGF0IFNBQ00gaXMgY2hhcnRlcmVkIHRv IGRlZmluZSB0aGUgaW50ZXJmYWNlcyBhbmQKICAgZGF0YSBtb2RlbCBmb3IgaG93IGFuIEV2YWx1 YXRvciBzdG9yZXMgYW5kIHRyYW5zcG9ydHMgdGhlIGFzc2Vzc21lbnQKICAgcmVzdWx0cyB0byB0 aGUgUmVwb3NpdG9yeS4gIFRodXMsIHRoZSBmb2N1cyBvZiB0aGUgcmVxdWlyZW1lbnRzIHdpbGwK ICAgcmV2b2x2ZSBhcm91bmQgdGhlIGRhdGEgbW9kZWxzLCBwcm90b2NvbHMgYW5kIHRyYW5zcG9y dHMgZm9yIEIsIHRoZQogICBjb21tdW5pY2F0aW9uIG9mIHBvc3R1cmUgYXNzZXNzbWVudCBmcm9t IGFuIEV2YWx1YXRvciB0byBhbgogICBBc3Nlc3NtZW50IENvbnN1bWVyLgoKMi4yLiAgR2VuZXJh bCBTQUNNIHJlcXVpcmVtZW50cwoKICAgVGhlIHVzZSBjYXNlcyBkZWZpbmVkIGluIFtJLUQuaWV0 Zi1zYWNtLXVzZS1jYXNlc10gYXBwbHkgdG8gbWFueQogICBkZXBsb3ltZW50IHNjZW5hcmlvcy4g IFRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LCBzY2FsYWJpbGl0eSBhbmQKICAgZmxleGliaWxp dHkgaW4gYW55IG9mIHRoZXNlIGRlcGxveW1lbnRzLCB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50 cwogICBhcmUgZGVmaW5lZCBmb3IgYWxsIHVzZSBjYXNlczoKCiAgIEctMDAxICBUaGUgZGF0YSBt b2RlbHMsIHByb3RvY29scyBhbmQgdHJhbnNwb3J0cyBkZWZpbmVkIGJ5IFNBQ00gbXVzdAogICAg YmUgZXh0ZW5zaWJsZSB0byBhbGxvdyBzdXBwb3J0IGZvciBub24tc3RhbmRhcmQgYW5kIGZ1dHVy ZQogICAgZXh0ZW5zaW9ucy4KCiAgIEctMDAyICBUaGUgZGF0YSBtb2RlbHMsIHByb3RvY29scyBh bmQgdHJhbnNwb3J0cyBtdXN0IGJlIHNwZWNpZmllZAogICAgd2l0aCBlbm91Z2ggZGV0YWlscyBh bmQgc3RhdGUgbWFjaGluZSB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eS4KCiAgIEctMDAzICBT QUNNIG11c3Qgc3VwcG9ydCBhIGJyb2FkIHNldCBvZiBkZXBsb3ltZW50IHNjZW5hcmlvcy4gIEFz CiAgICBzdWNoLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBzaXplIG9yIHBvc3R1cmUgYXNzZXNz bWVudCBpbmZvcm1hdGlvbgogICAgY2FuIHZhcnkgZnJvbSBhIHNpbmdsZSBhc3Nlc3NtZW50IHRo YXQgaXMgc21hbGwgaW4gKHJlY29yZCBvcgoKCgpDYW0tV2luZ2V0ICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMTksIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQgVGl0bGUgICAgICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTQKCgogICAgZGF0YWdyYW0pIHNpemUgdG8gYSB2ZXJ5IGxhcmdlIGRhdGFncmFtIG9yIGEg dmVyeSBsYXJnZSBzZXQgb2YKICAgIGFzc2Vzc21lbnRzIGFuZCBtdXN0IGJlIGFkZHJlc3NlZCBi eSB0aGUgU0FDTSBzcGVjaWZpY2F0aW9ucwogICAgZGVmaW5lZC4gIFRodXMsIHRoZSBkYXRhIG1v ZGVscywgcHJvdG9jb2xzIGFuZCB0cmFuc3BvcnRzIG11c3QgYmUKICAgIHNjYWxhYmxlLgoKICAg Ry0wMDQgIENvbnNpZGVyYXRpb25zIGZvciB0aGUgbGlnaHR3ZWlnaHQgaW1wbGVtZW50YXRpb25z IG9mIGRhdGEKICAgIG1vZGVscyBhbmQgdHJhbnNwb3J0cyBpcyByZXF1aXJlZC4gIFVzZSBjYXNl cywgZXNwZWNpYWxseSBpbiB0aGUKICAgIHZ1bG5lcmFiaWxpdHkgYXNzZXNzbWVudCBhbmQgdGhy ZWF0IGRlZmVuc2UgYXBwbGljYXRpb25zIHJlcXVpcmUKICAgIHRpbWUgY3JpdGljYWxpdHkgaW4g Ym90aCBvYnRhaW5pbmcgdGhlIGluZm9ybWF0aW9uIGFzIHdlbGwgYXMKICAgIGNvbnN1bWluZyAo ZS5nLiBwYXJzaW5nKSB0aGUgZGF0YS4gIFRoZSBhZ2lsaXR5IHJlcXVpcmVtZW50IGlzIHRvCiAg ICBlbnN1cmUgdGhhdCB0aGUgZGF0YSBtb2RlbCwgcHJvdG9jb2xzLCB0cmFuc3BvcnRzIGFuZCBp dHMKICAgIGltcGxlbWVudGF0aW9ucyBhcmUgc3VpdGFibGUgdG8gZml0IGluIGRpZmZlcmVudCBk ZXBsb3ltZW50IG1vZGVscwogICAgYW5kIHNjZW5hcmlvcy4KCiAgIEctMDA1ICBEaWZmZXJlbnQg dHJhbnNwb3J0cyBtdXN0IGJlIHN1cHBvcnRlZCB0byBhZGRyZXNzIGRpZmZlcmVudAogICAgZGVw bG95bWVudCBhbmQgdGltZSBjb25zdHJhaW50cy4gIFN1cHBvcnRpbmcgdGhlIGxpbmsgbGF5ZXIs CiAgICB0cmFuc3BvcnQgYW5kIGFwcGxpY2F0aW9uIGxheWVycy4KCiAgIEctMDA2ICBGb3IgaW50 ZXJvcGVyYWJpbGl0eSBhbmQgc2NvcGUgYm91bmRhcnksIGFuIGV4cGxpY2l0IHNldCBvZgogICAg ZGF0YSBhdHRyaWJ1dGVzIGFzIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgc2hvdWxkIGJlIGRlZmlu ZWQuICBXaGlsZQogICAgdGhlIFNBQ00gY2hhcnRlciBkZWZpbmVzIHRoZSBmb2N1cyB0byBiZSBv biBwb3N0dXJlIGFzc2Vzc21lbnQsCiAgICBhdHRyaWJ1dGVzIGNvcnJlc3BvbmRpbmcgdG8gUG9z dHVyZSBBc3Nlc3NtZW50IHNob3VsZCBiZSBkZXNjcmliZWQuCgogICBHLTAwNyAgVG8gYWRkcmVz cyBzZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucywgdGhlIGRhdGEKICAgIG1vZGVs LCBwcm90b2NvbHMgYW5kIHRyYW5zcG9ydCBtdXN0IGNvbnNpZGVyIGF1dGhvcml6YXRpb24gYmFz ZWQgb24KICAgIHJvbGVzIHRvIG9ubHkgYWxsb3cgYXV0aG9yaXplZCByZXF1ZXN0b3JzIGFuZCBw dWJsaXNoZXJzIHRvIGFjY2VzcwogICAgdGhlIGluZm9ybWF0aW9uIGJlaW5nIHJlcXVlc3RlZCBv ciBwdWJsaXNoZWQuCgoyLjMuICBSZXF1aXJlbWVudHMgYmFzZWQgb24gVXNlIENhc2VzCgogICBU aGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSByZXF1aXJlbWVudHMgdGhhdCBtYXkgYXBwbHkgdG8g aW5mb3JtYXRpb24KICAgbW9kZWxzLCBkYXRhIG1vZGVscywgcHJvdG9jb2xzIG9yIHRyYW5zcG9y dHMgYXMgaWRlbnRpZmllZCBieSB0aGUgdXNlCiAgIGNhc2VzIGluIFtJLUQuaWV0Zi1zYWNtLXVz ZS1jYXNlc10gYW5kIHJlZmVyZW5jZWQgYnkgdGhlIHNlY3Rpb24KICAgbnVtYmVycyBmcm9tIHRo YXQgZHJhZnQuCgogICBSRVEtMDAxICBVc2UgQ2FzZXMgaW4gdGhlIHdob2xlIG9mIFNlY3Rpb24g MiBkZXNjcmliZSB0aGUgbmVlZCBmb3IgYW4KICAgIEF0dHJpYnV0ZSBEaWN0aW9uYXJ5LiAgV2l0 aCBTQUNNJ3Mgc2NvcGUgZm9jdXNlZCBvbiBQb3N0dXJlCiAgICBBc3Nlc3NtZW50LCB0aGUgYXR0 cmlidXRlIGNvbGxlY3Rpb24gYW5kIGFnZ3JlZ2F0aW9uIG11c3QgaGF2ZSBhCiAgICB3ZWxsIHVu ZGVyc3Rvb2Qgc2V0IG9mIGF0dHJpYnV0ZXMgaW5jbHVzaXZlIG9mIHRoZWlyIG1lYW5pbmcgb3IK ICAgIHVzYWdlIGludGVudC4KCiAgIFJFUS0wMDIgIFVzZSBDYXNlIDIuMS4xIGRlc2NyaWJlcyB0 aGUgbmVlZCBmb3IgYW4gSW5mb3JtYXRpb24gTW9kZWwKICAgIHRvIGRyaXZlIGNvbnRlbnQgZGVm aW5pdGlvbi4gIEFzIFNBQ00gZW5kZWF2b3JzIHRvIHJldXNlIGFscmVhZHkKICAgIGV4aXN0aW5n IHN0YW5kYXJkcyB3aGljaCBtYXkgaGF2ZSB0aGVpciBvd24gZGF0YSBtb2RlbHMgZGVmaW5lZCBi eQogICAgaW5zdGFudGlhdGluZyBhbiBpbmZvcm1hdGlvbiBtb2RlbCwgdGhlIGRhdGEgbW9kZWxz IGNhbiBiZSBtYXBwZWQgdG8KICAgIFNBQ00ncyBpbmZvcm1hdGlvbiBtb2RlbC4gIFNlZSBbUkZD MzQ0NF0gZm9yIGEgZGVzY3JpcHRpb24gYW5kCiAgICBkaXN0aW5jdGlvbnMgYmV0d2VlbiBhbiBp bmZvcm1hdGlvbiBhbmQgZGF0YSBtb2RlbC4KCgoKCkNhbS1XaW5nZXQgICAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgRmVicnVh cnkgMjAxNAoKCiAgIFJFUS0wMDMgIFVzZSBDYXNlIDIuMS4xIGRlc2NyaWJlcyB0aGUgbmVlZCB0 byBpbnN0YW50aWF0ZSBhIGRhdGEKICAgIG1vZGVsIHRoYXQgY2FuIG1hcCB0byB0aGUgU0FDTSBw cm90b2NvbHMgZm9yIHBvc3R1cmUgY29udGVudAogICAgb3BlcmF0aW9ucyBzdWNoIGFzIHB1Ymxp Y2F0aW9uLCBxdWVyeSwgY2hhbmdlIGRldGVjdGlvbiBhbmQKICAgIGFzeW5jaHJvbm91cyBub3Rp ZmljYXRpb25zLgoKICAgUkVRLTAwNCAgVXNlIENhc2UgMi4xLjIgZGVzY3JpYmVzIHRoZSBuZWVk IHRvIGRpc2NvdmVyIGVuZHBvaW50cyBhbmQKICAgIHRoZWlyIGNvbXBvc2l0aW9uLgoKICAgUkVR LTAwNSAgVXNlIENhc2UgMi4xLjIgZGVzY3JpYmVzIHRoZSBuZWVkIGZvciB0aGUgZGF0YSBtb2Rl bCB0bwogICAgc3VwcG9ydCBhIHF1ZXJ5IG9wZXJhdGlvbiBiYXNlZCBvbiBhIHNldCBvZiBhdHRy aWJ1dGVzIHRvIGZhY2lsaXRhdGUKICAgIGNvbGxlY3Rpb24gb2YgaW5mb3JtYXRpb24gc3VjaCBh cyBwb3N0dXJlIGFzc2Vzc21lbnQsIGludmVudG9yeSAob2YKICAgIGVuZHBvaW50cyBvciBlbmRw b2ludCBjb21wb25lbnRzKSBhbmQgY29uZmlndXJhdGlvbiBjaGVja2xpc3QuIC4KCiAgIFJFUS0w MDYgIFVzZSBDYXNlIDIuMS4zIGRlc2NyaWJlcyB0aGUgbmVlZCBmb3IgdGhlIGRhdGEgbW9kZWwg dG8KICAgIHN1cHBvcnQgdGhlIG1lYW5zIGZvciB0aGUgaW5mb3JtYXRpb24gdG8gYmUgY29sbGVj dGVkIHRocm91Z2ggYQogICAgcXVlcnkgbWVjaGFuaXNtLiAgRnVydGhlcm1vcmUsIHRoZSBxdWVy eSBvcGVyYXRpb24gcmVxdWlyZXMKICAgIGZpbHRlcmluZyBjYXBhYmlsaXRpZXMgdG8gYWxsb3cg Zm9yIG9ubHkgYSBzdWJzZXQgb2YgaW5mb3JtYXRpb24gdG8KICAgIGJlIHJldHJpZXZlZC4gIFRo ZSBxdWVyeSBvcGVyYXRpb24gbWF5IGJlIGEgc3luY2hyb25vdXMgcmVxdWVzdCBvcgogICAgYXN5 bmNocm9ub3VzIHJlcXVlc3QuCgogICBSRVEtMDA3ICBVc2UgQ2FzZXMgMi4xLjMsIDIuMS40IGFu ZCAyLjEuNSBkZXNjcmliZSB0aGUgbmVlZCBmb3IgdGhlCiAgICBkYXRhIG1vZGVsIHRvIHN1cHBv cnQgdGhlIG1lYW5zIGZvciB0aGUgaW5mb3JtYXRpb24gdG8gYmUgcHVibGlzaGVkCiAgICBhc3lu Y2hyb25vdXNseS4gIFNpbWlsYXJseSwgdGhlIGRhdGEgbW9kZWwgbXVzdCBzdXBwb3J0IHRoZSBt ZWFucwogICAgZm9yIGEgcmVxdWVzdG9yIHRvIG9idGFpbiB1cGRhdGVzIG9yIGNoYW5nZSBtb2Rp ZmljYXRpb25zCiAgICBhc3luY2hyb25vdXNseS4gIExpa2UgdGhlIHF1ZXJ5IG9wZXJhdGlvbiwg dGhlc2UgdXBkYXRlCiAgICBub3RpZmljYXRpb25zIGNhbiBiZSBzZXQgdXAgd2l0aCBhIGZpbHRl ciB0byBhbGxvdyBmb3Igb25seSBhIHN1YnNldAogICAgb2YgcG9zdHVyZSBhc3Nlc3NtZW50IGlu Zm9ybWF0aW9uIHRvIGJlIG9idGFpbmVkLgoKICAgUkVRLTAwOCAgVXNlIENhc2VzIDIuMS40IGFu ZCAyLjEuNSBkZXNjcmliZXMgdGhlIG5lZWQgZm9yIHRoZSBkYXRhCiAgICBtb2RlbCB0byBzdXBw b3J0IHNjYWxhYmlsaXR5LiAgRm9yIGV4YW1wbGUsIHRoZSBxdWVyeSBvcGVyYXRpb24gbWF5CiAg ICByZXN1bHQgaW4gYSB2ZXJ5IGxhcmdlIHNldCBvZiBhdHRyaWJ1dGVzIGFzIHdlbGwgYXMgYSBs YXJnZSBzZXQgb2YKICAgIHRhcmdldHMuCgozLiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1 dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBCYXJiYXJhIEZyYXNlciwgSmltIEJpZWRhIGFuZCBB ZGFtCiAgIE1vbnR2aWxsZSBmb3IgcmV2aWV3aW5nIGFuZCBjb250cmlidXRpbmcgdG8gdGhpcyBk cmFmdC4KCjQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIG1lbW8gaW5jbHVkZXMgbm8g cmVxdWVzdCB0byBJQU5BLgoKNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgU0FDTS4gIEFzIHN1Y2gsIGl0IGlz CiAgIGV4cGVjdGVkIHRoYXQgc2V2ZXJhbCBkYXRhIG1vZGVscywgcHJvdG9jb2xzIGFuZCB0cmFu c3BvcnRzIG1heSBiZQogICBkZWZpbmVkIG9yIHJldXNlZCBmcm9tIGFscmVhZHkgZXhpc3Rpbmcg c3RhbmRhcmRzLiAgVGhpcyBzZWN0aW9uIHdpbGwKCgoKCkNhbS1XaW5nZXQgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAxOSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgRmVi cnVhcnkgMjAxNAoKCiAgIGhpZ2hsaWdodCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IG1h eSBhcHBseSB0byBTQUNNIGJhc2VkIG9uIHRoZQogICBhcmNoaXRlY3R1cmUgYW5kIHN0YW5kYXJk cyBhcHBsaWVkIGluIFNBQ00uCgo2LiAgUmVmZXJlbmNlcwoKNi4xLiAgTm9ybWF0aXZlIFJlZmVy ZW5jZXMKCiAgIFtJLUQuaWV0Zi1zYWNtLXRlcm1pbm9sb2d5XQogICAgICAgICAgICAgIFdhbHRl cm1pcmUsIEQuLCBNb250dmlsbGUsIEEuLCBhbmQgRC4gSGFycmluZ3RvbiwKICAgICAgICAgICAg ICAiVGVybWlub2xvZ3kgZm9yIFNlY3VyaXR5IEFzc2Vzc21lbnQiLCBkcmFmdC1pZXRmLXNhY20t CiAgICAgICAgICAgICAgdGVybWlub2xvZ3ktMDIgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKYW51YXJ5 IDIwMTQuCgogICBbSS1ELmlldGYtc2FjbS11c2UtY2FzZXNdCiAgICAgICAgICAgICAgV2FsdGVy bWlyZSwgRC4gYW5kIEQuIEhhcnJpbmd0b24sICJFbmRwb2ludCBTZWN1cml0eQogICAgICAgICAg ICAgIFBvc3R1cmUgQXNzZXNzbWVudCAtIEVudGVycHJpc2UgVXNlIENhc2VzIiwgZHJhZnQtaWV0 Zi0KICAgICAgICAgICAgICBzYWNtLXVzZS1jYXNlcy0wNSAod29yayBpbiBwcm9ncmVzcyksIE5v dmVtYmVyIDIwMTMuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIs IEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgo2LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzCgogICBbUkZDMzQ0NF0gIFByYXMsIEEuIGFuZCBKLiBTY2hvZW53YWVsZGVyLCAiT24gdGhl IERpZmZlcmVuY2UgYmV0d2VlbgogICAgICAgICAgICAgIEluZm9ybWF0aW9uIE1vZGVscyBhbmQg RGF0YSBNb2RlbHMiLCBSRkMgMzQ0NCwgSmFudWFyeQogICAgICAgICAgICAgIDIwMDMuCgogICBb UkZDNTIwOV0gIFNhbmdzdGVyLCBQLiwgS2hvc3JhdmksIEguLCBNYW5pLCBNLiwgTmFyYXlhbiwg Sy4sIGFuZCBKLgogICAgICAgICAgICAgIFRhcmRvLCAiTmV0d29yayBFbmRwb2ludCBBc3Nlc3Nt ZW50IChORUEpOiBPdmVydmlldyBhbmQKICAgICAgICAgICAgICBSZXF1aXJlbWVudHMiLCBSRkMg NTIwOSwgSnVuZSAyMDA4LgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgTmFuY3kgQ2FtLVdpbmdldAog ICBDaXNjbyBTeXN0ZW1zCiAgIDM1NTAgQ2lzY28gV2F5CiAgIFNhbiBKb3NlLCBDQSAgOTUxMzQK ICAgVVMKCiAgIEVtYWlsOiBuY2Ftd2luZ0BjaXNjby5jb20KCgoKCgoKCgoKCgoKQ2FtLVdpbmdl dCAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDE5LCAyMDE0ICAgICAgICAgICAgICAgIFtQ YWdlIDddCg== --_004_CF23FA7D99083ncamwingciscocom_-- From nobody Mon Feb 17 07:49:31 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8EC1A024B for ; Mon, 17 Feb 2014 07:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1uJEi6EMxwD for ; Mon, 17 Feb 2014 07:49:28 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B21041A03F6 for ; Mon, 17 Feb 2014 07:49:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUKADcuAlPGmAcV/2dsb2JhbABZgkIjIThXqAoDlyuBHxZ0gicBAQMSG14BDAkVViYBBBsBGYdjAQyaaoRSrDiOUINcgRQEnxuLNIMtgio X-IronPort-AV: E=Sophos; i="4.95,861,1384318800"; d="scan'208,217"; a="43241418" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Feb 2014 10:49:15 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Feb 2014 10:37:35 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 16:49:13 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: draft minutes of the February 4 virtual interim Thread-Index: Ac8r9809Y6HzFVGOS/uHpwkShOjIpQ== Date: Mon, 17 Feb 2014 15:49:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E41BC32@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BC32AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/SDeMTulnkLxCK_bj53j6fyPbx-c Subject: [sacm] draft minutes of the February 4 virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:49:30 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BC32AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft minutes of the February 4, 2014 virtual interim meeting are now a= vailable at http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes= /minutes-interim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for tak= ing the notes the minutes rely upon. Please read and let me know if anythin= g is missing or was not represented accurately. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BC32AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The draft minutes of the February 4, 2014 virtual in= terim meeting are now available at http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes/minutes-int= erim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for taking the = notes the minutes rely upon. Please read and let me know if anything is mis= sing or was not represented accurately.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BC32AZFFEXMB04globa_-- From nobody Mon Feb 17 09:17:43 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40FC1A00FE for ; Mon, 17 Feb 2014 09:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0UDdaVC-pDv for ; Mon, 17 Feb 2014 09:17:36 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4826C1A03FB for ; Mon, 17 Feb 2014 09:17:36 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id TRfJ1n0041ap0As53VHZpA; Mon, 17 Feb 2014 17:17:33 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta22.westchester.pa.mail.comcast.net with comcast id TVHZ1n00E2yZEBF3iVHZGh; Mon, 17 Feb 2014 17:17:33 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: <9904FB1B0159DA42B0B887B7FA8119CA2E41BC32@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E41BC32@AZ-FFEXMB04.global.avaya.com> Date: Mon, 17 Feb 2014 12:17:33 -0500 Message-ID: <005901cf2c04$25e1f390$71a5dab0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01CF2BDA.3D0D4B20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFKve0KY/IjN9kqJS+5gaFQ8G76cJvCh9Kg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392657453; bh=M/30h0Vy2ZgQ/stvpf2ndD//XvJhe925u5fb94FJwlI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ImkI+j6zqmllYoivvdyqSAyEG1rT4RHwYj/XodgbniCSNHbBYfnjI58lbCmEd+6GV HKLXNolObCBdwWrzaX6suVLmS3NVC6zAGkFSg72i9Q+4RSt8TDzQkfdFdzynqNhQ8r cvcLCYxLiTWGpMmh69uQaRndW4MHKUb8eg9iRBl5gNmOLPKxlB2XIlZcfc0HSmt6sB ud7EqeEDKCuqZVqasoQOM8RY8CzQv3mT1snvwSi4C5c26HQ2GYG45mDYSRqZrcss44 CGzN6e4c+KTJniO2gdk9AFY3g3u0sAMEgaAF2zbFERKTucHZEdRrfPoMY8rC3ZhaX9 /Fei8dWB6tApQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/PqmOpwK68cfnZwVdphsMubt1LSI Subject: Re: [sacm] draft minutes of the February 4 virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:17:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01CF2BDA.3D0D4B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think the following is inaccurate: "Dave Harrington and others pointed out that OSI layer numbers should not be used in the document. Instead, IETF layers should be used. Nancy agreed and promised to change this in the next version." The discussion was about "transport protocols"; Nancy included a number of protocols that are "transport protocols" in other SDOs, notably ITU-T, but are not considered transport protocols in the IETF. We should be using terminology consistent with other IETF work. David Harrington dbharrington@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, February 17, 2014 10:49 AM To: sacm@ietf.org Subject: [sacm] draft minutes of the February 4 virtual interim Hi, The draft minutes of the February 4, 2014 virtual interim meeting are now available at http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes/minutes-inte rim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for taking the notes the minutes rely upon. Please read and let me know if anything is missing or was not represented accurately. Thanks and Regards, Dan ------=_NextPart_000_005A_01CF2BDA.3D0D4B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think the following is = inaccurate:

“Dave Harrington and others pointed out = that OSI layer numbers should not be used in the document. Instead, IETF = layers should be used. Nancy agreed and promised to change this in the = next version.”

 

The discussion was = about “transport protocols”; Nancy included a number of = protocols that are “transport protocols” in other SDOs, = notably ITU-T, but are not considered transport protocols in the IETF. = We should be using terminology consistent with other IETF = work.

 

+1-603-828-1401

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Monday, February 17, 2014 10:49 AM
To: = sacm@ietf.org
Subject: [sacm] draft minutes of the February 4 = virtual interim

 

Hi,

 

The draft = minutes of the February 4, 2014 virtual interim meeting are now = available at http://www.ietf.org/proceedings/interim/2014/= 02/04/sacm/minutes/minutes-interim-2014-sacm-1. Thanks to Steve = Hanna and Dave Misell for taking the notes the minutes rely upon. Please = read and let me know if anything is missing or was not represented = accurately.

 

Thanks and Regards,

 

Dan

 

------=_NextPart_000_005A_01CF2BDA.3D0D4B20-- From nobody Tue Feb 18 09:47:11 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0491A06BA for ; Tue, 18 Feb 2014 09:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0APDiJq8WQw for ; Tue, 18 Feb 2014 09:47:05 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 94A931A025B for ; Tue, 18 Feb 2014 09:47:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUKAGKbA1OHCzIm/2dsb2JhbABWA4JCIyE4V6gkly6BHBZ0giUBAQEBAxIbXAIBCA0BAwQBAQsdBzIUCQgBAQQBEggBGYdPAxEBDJ9QpC0IiBQXjlAhFgERgh4PZoEUBIVYmUOLNIMtgio X-IronPort-AV: E=Sophos; i="4.97,502,1389762000"; d="scan'208,217"; a="49915843" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Feb 2014 12:47:01 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 18 Feb 2014 12:34:06 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 18:47:00 +0100 From: "Romascanu, Dan (Dan)" To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] draft minutes of the February 4 virtual interim Thread-Index: Ac8r9809Y6HzFVGOS/uHpwkShOjIpQANkCiAACirsvA= Date: Tue, 18 Feb 2014 17:46:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E422468@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E41BC32@AZ-FFEXMB04.global.avaya.com> <005901cf2c04$25e1f390$71a5dab0$@comcast.net> In-Reply-To: <005901cf2c04$25e1f390$71a5dab0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E422468AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/lKuEAN52GRtcI8m8Y7V8_MXnCAw Subject: Re: [sacm] draft minutes of the February 4 virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:47:08 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E422468AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, Thanks for reading this carefully. Will the following change reflect more accurately what happened in the meet= ing: OLD Dave Harrington and others pointed out that OSI layer numbers should not be= used in the document. Instead, IETF layers should be used. Nancy agreed an= d promised to change this in the next version. NEW Nancy mentioned a number of protocols that are "transport protocols" in oth= er SDOs, notably ITU-T, but are not considered transport protocols in the I= ETF . Dave Harrington, Dan and others pointed out that when talking about l= ayers for protocols the numbers and names of the layers in the IETF model s= hould be used rather than the ones in the OSI layering model. Nancy agreed = and promised to change this in the next version. Regards, Dan From: David Harrington [mailto:dbharrington@comcast.net] Sent: Monday, February 17, 2014 7:18 PM To: Romascanu, Dan (Dan); sacm@ietf.org Subject: RE: [sacm] draft minutes of the February 4 virtual interim Hi, I think the following is inaccurate: "Dave Harrington and others pointed out that OSI layer numbers should not b= e used in the document. Instead, IETF layers should be used. Nancy agreed a= nd promised to change this in the next version." The discussion was about "transport protocols"; Nancy included a number of = protocols that are "transport protocols" in other SDOs, notably ITU-T, but = are not considered transport protocols in the IETF. We should be using term= inology consistent with other IETF work. David Harrington dbharrington@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, February 17, 2014 10:49 AM To: sacm@ietf.org Subject: [sacm] draft minutes of the February 4 virtual interim Hi, The draft minutes of the February 4, 2014 virtual interim meeting are now a= vailable at http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes= /minutes-interim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for tak= ing the notes the minutes rely upon. Please read and let me know if anythin= g is missing or was not represented accurately. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E422468AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

Thanks for reading thi= s carefully.

 

Will the following cha= nge reflect more accurately what happened in the meeting:

 

OLD<= /p>

 

Dave Harrington and= others pointed out that OSI layer numbers should not be used in the docume= nt. Instead, IETF layers should be used. Nancy agreed and promised to chang= e this in the next version.

 

NEW

 

Nancy mentioned a n= umber of protocols that are “transport protocols” in other SDOs= , notably ITU-T, but are not considered transport protocols in the IETF . D= ave Harrington, Dan and others pointed out that when talking about layers for protocols the numbers and names of the layer= s in the IETF model should be used rather than the ones in the OSI layering= model. Nancy agreed and promised to change this in the next version.<= /o:p>

 

Regards,=

 

Dan

 

 

From: David Ha= rrington [mailto:dbharrington@comcast.net]
Sent: Monday, February 17, 2014 7:18 PM
To: Romascanu, Dan (Dan); sacm@ietf.org
Subject: RE: [sacm] draft minutes of the February 4 virtual interim<= o:p>

 

Hi,

 

I think the following = is inaccurate:

“Dave Harring= ton and others pointed out that OSI layer numbers should not be used in the= document. Instead, IETF layers should be used. Nancy agreed and promised t= o change this in the next version.”

 

The discussion was = about “transport protocols”; Nancy included a number of protoco= ls that are “transport protocols” in other SDOs, notably ITU-T,= but are not considered transport protocols in the IETF. We should be using terminology consistent with other IETF work.

 

David Harrington

dbharrington@comcast.net

+1-603-828-1401<= span style=3D"color:#1F497D">

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 17, 2014 10:49 AM
To: sacm@ietf.org
Subject: [sacm] draft minutes of the February 4 virtual interim=

 

Hi,

 

The draft minutes of the February 4, 2014 virtual in= terim meeting are now available at http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes/minutes-int= erim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for taking the = notes the minutes rely upon. Please read and let me know if anything is mis= sing or was not represented accurately.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E422468AZFFEXMB04globa_-- From nobody Tue Feb 18 13:02:24 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738E81A0274 for ; Tue, 18 Feb 2014 13:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGypyvsgEA-Y for ; Tue, 18 Feb 2014 13:02:21 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 21C911A051D for ; Tue, 18 Feb 2014 13:02:20 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id TuBt1n00C0Fqzac58x2H94; Tue, 18 Feb 2014 21:02:17 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id Tx2H1n0062yZEBF3Ux2HUd; Tue, 18 Feb 2014 21:02:17 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_B6569280-018B-43B3-B830-09C3CDF4F8AE" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Harrington In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E422468@AZ-FFEXMB04.global.avaya.com> Date: Tue, 18 Feb 2014 16:02:18 -0500 Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA2E41BC32@AZ-FFEXMB04.global.avaya.com> <005901cf2c04$25e1f390$71a5dab0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA2E422468@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1510) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392757337; bh=IqXXDYsXgfDUZNvZzPYGO0NSYDn/2voZtQ8TkA4F928=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=BD7pWmq+JhF+GknWPqbvTa8accGYiI91IBcRa9odESsVRhLMbtGr+QeZeTZnLP9c2 TrrpwI4dgjHo+88PjHeZziyQo59YCJ1JgMIL2fDyMnDMDH5CHbVkzZ8h3XlnK6C1cQ X5VJ0RX2pd4O0cvLNt6ROXEudPiQh3h9xbiLv12kW8wCoxcaPbm3QW61eta0mb00rI eX2MJeMdQzuht37q8wJUHMVSDvDaUYOZaQbkFJDVpZu9BJwXWqPRsSNUX6yOk5fq0+ +0h13AouQC23GUZcB6mSSZWYD7Tr0Rz6+gUqBM9jl2GK/h5qE007ydyMX3WIsLJzyw 0lCTSBGZHeRcg== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/3V9FZGlJ0McY6Fx4AfAki__Ib_g Cc: "sacm@ietf.org" Subject: Re: [sacm] draft minutes of the February 4 virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:02:23 -0000 --Apple-Mail=_B6569280-018B-43B3-B830-09C3CDF4F8AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 looks good to me. dbh On Feb 18, 2014, at 12:46 PM, "Romascanu, Dan (Dan)" = wrote: > Hi David, > =20 > Thanks for reading this carefully. > =20 > Will the following change reflect more accurately what happened in the = meeting: > =20 > OLD > =20 > Dave Harrington and others pointed out that OSI layer numbers should = not be used in the document. Instead, IETF layers should be used. Nancy = agreed and promised to change this in the next version. > =20 > NEW > =20 > Nancy mentioned a number of protocols that are =93transport protocols=94= in other SDOs, notably ITU-T, but are not considered transport = protocols in the IETF . Dave Harrington, Dan and others pointed out that = when talking about layers for protocols the numbers and names of the = layers in the IETF model should be used rather than the ones in the OSI = layering model. Nancy agreed and promised to change this in the next = version. > =20 > Regards, > =20 > Dan > =20 > =20 > From: David Harrington [mailto:dbharrington@comcast.net]=20 > Sent: Monday, February 17, 2014 7:18 PM > To: Romascanu, Dan (Dan); sacm@ietf.org > Subject: RE: [sacm] draft minutes of the February 4 virtual interim > =20 > Hi, > =20 > I think the following is inaccurate: > =93Dave Harrington and others pointed out that OSI layer numbers = should not be used in the document. Instead, IETF layers should be used. = Nancy agreed and promised to change this in the next version.=94 > =20 > The discussion was about =93transport protocols=94; Nancy included a = number of protocols that are =93transport protocols=94 in other SDOs, = notably ITU-T, but are not considered transport protocols in the IETF. = We should be using terminology consistent with other IETF work. > =20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan) > Sent: Monday, February 17, 2014 10:49 AM > To: sacm@ietf.org > Subject: [sacm] draft minutes of the February 4 virtual interim > =20 > Hi, > =20 > The draft minutes of the February 4, 2014 virtual interim meeting are = now available at = http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes/minutes-in= terim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for taking the = notes the minutes rely upon. Please read and let me know if anything is = missing or was not represented accurately. > =20 > Thanks and Regards, > =20 > Dan > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_B6569280-018B-43B3-B830-09C3CDF4F8AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 looks good to = me.

dbh

On Feb 18, 2014, at = 12:46 PM, "Romascanu, Dan (Dan)" <dromasca@avaya.com> = wrote:

Hi = David,
 
Thanks for reading this = carefully.
 
Will = the following change reflect more accurately what happened in the = meeting:
 
OLD
Dave Harrington and others pointed out that OSI layer numbers = should not be used in the document. Instead, IETF layers should be used. = Nancy agreed and promised to change this in the next = version.
 
NEW
Nancy mentioned a number of protocols that are =93transport = protocols=94 in other SDOs, notably ITU-T, but are not considered = transport protocols in the IETF . Dave Harrington, Dan and others = pointed out that when talking about layers for protocols the numbers and = names of the layers in the IETF model should be used rather than the = ones in the OSI layering model. Nancy agreed and promised to change this = in the next version.
 
 
Dan
 
From: David Harrington = [mailto:dbharrington@comcast.net] 
Sent: Monday, February 17, 2014 = 7:18 PM
To: Romascanu, Dan (Dan); sacm@ietf.org
Subject: RE: [sacm] draft minutes of = the February 4 virtual interim
 
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Monday, February 17, 2014 = 10:49 AM
To: sacm@ietf.org
Subject: [sacm] draft minutes of the = February 4 virtual interim
 
 
The draft minutes of the February 4, 2014 virtual = interim meeting are now available at http://www.ietf.org/proceedings/interim/2014/02/04/sacm/minutes/minutes-= interim-2014-sacm-1. Thanks to Steve Hanna and Dave Misell for = taking the notes the minutes rely upon. Please read and let me know if = anything is missing or was not represented = accurately.
Thanks and = Regards,
To: "Nancy Cam-Winget (ncamwing)" , Stephen Hanna , Gunnar Engelbach , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVAAAzOpAAAARPnQARgzlgAApbydgADJGEHQ Date: Wed, 19 Feb 2014 01:33:03 +0000 Message-ID: <83708abbee37498b8a61dd2272e700ba@BLUPR09MB038.namprd09.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.199] x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(57704003)(24454002)(189002)(13464003)(164054003)(51444003)(199002)(51704005)(46034005)(52604005)(479174003)(377454003)(1941001)(95666001)(83322001)(80976001)(76482001)(69226001)(76786001)(15975445006)(81686001)(53806001)(56816005)(77096001)(95416001)(74316001)(81542001)(93136001)(74366001)(92566001)(87936001)(50986001)(83072002)(59766001)(65816001)(79102001)(54316002)(2656002)(94316002)(47446002)(31966008)(47976001)(80022001)(74706001)(74876001)(33646001)(51856001)(66066001)(49866001)(46102001)(85852003)(74662001)(4396001)(76796001)(74502001)(86362001)(19580405001)(76576001)(85306002)(81816001)(56776001)(93516002)(77982001)(94946001)(87266001)(63696002)(90146001)(19580395003)(54356001)(81342001)(47736001)(24736002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.199; FPR:EE7CF1D5.ABFAA142.B8D1F16B.82E4CB41.2093E; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/wq2xoyiOsOhDz8Tg0n1YJXE-DkM Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 01:33:16 -0000 Nancy, Thanks for your feedback. I have some comments below: > -----Original Message----- > From: Nancy Cam-Winget (ncamwing) [mailto:ncamwing@cisco.com] > Sent: Friday, February 14, 2014 7:31 PM > To: Waltermire, David A.; Stephen Hanna; Gunnar Engelbach; Panos > Kampanakis (pkampana); sacm@ietf.org > Subject: Re: [sacm] Types of content >=20 > Hi Dave: >=20 > Thanks for putting more clarity, I have some comments and questions below= : >=20 > On 2/11/14 4:13 PM, "Waltermire, David A." > wrote: >=20 > >I'd like to get the discussion around this topic to a point where I > >have clear editorial direction on what text we want included in the > >updated use case draft for this Friday's submission cutoff deadline. > > > >Based on the mailing list discussions to date, I'd like to propose the > >following categories of security automation data for inclusion in the > >use cases draft: Guidance, Endpoint/Asset Attribute Data, and > >Processing Artifacts. > > > >The following sections roughly define each of the proposed categories. > >For each section some insights are provided into the how the data might > >be sourced and how often it may change. I have also included examples > >of the classes of information for each category with mappings to the > >use cases and building blocks they support to insure we have the > >necessary coverage. > > > >To move forward I need answers to the following questions: > > > >1) Do you like these groupings? If not, is there a better set of > >groupings? > [NCW] It is an improvement, but please see my further comments and > questions below. >=20 >=20 > >2) Do you like the labels for each of the groups? If not, do you have a > >better label(s)? > [NCW] I'm OK with the current groupings, though I'd like to keep the mode= l > as simple as possible. >=20 > >3) Are there other types of content that should be included? > >4) What level of detail should be included in the use cases draft > >regarding this discussion? What I have below is likely too much detail. > [NCW] I agree with Steve H. that this is probably too much details for th= e use > cases. [DAW: Putting on my editor hat... Nancy et al... Please take a look at the = -06 use case draft and let me know if the level of detail is good. I tried = to strike a balance. I'm not sure if it is the right balance though.] > > > >Thanks, > >Dave > > > >Guidance: > >------------ > >The term "guidance" was proposed by Steve Hanna and was supported by > >Gunnar Engelbach on the list. Steve proposed that this concept > >encompasses "attribute identifiers, lists of attributes that are to be > >collected and when and perhaps how, and policies about what attribute > >values are acceptable for different kinds or groups of endpoints. This > >indicates that these things (and maybe others to be added later) guide > >the attribute collection and evaluation process." I would also add that > >this should include instructions supporting data-driven evaluation > >processes. > > > >This data tends to change in units of months and days. In cases where > >assessments are made more dynamic, it may be necessary to handle > >changes in the scope of hours or minutes. This data will typically be > >provided by large organizations, product vendors, and some 3rd-parties. > >Thus, it will tend to be shared across large enterprises and customer > >communities. In some cases access may be controlled to specific > >authenticated users. In other cases, the data may be provided broadly > >with little to no access control. > > > >This would include: > > > >- Applicability Statements: Data the identifies the conditional > >applicability of an assessment (and related assessment "guidance") > >based on automated collection of endpoint posture attribute values and > >other endpoint characterizations. > > + Endpoint Identification and Assessment Planning BB: Identify > >Endpoint Targets - This supports the targeting concept allowing > >characterizations and collected posture attribute values to be > >evaluated to determine what set of endpoints should be assessed. > > > >- Collection Instructions: Data that drives the identification of the > >set of posture attributes needed to perform an assessment and the > >collection of posture attributes. > > + Endpoint Identification and Assessment Planning BB: Posture > >Attribute Identification - Used to determine the set of posture > >attributes for which values must be collected (or retrieved) to support > >the evaluation. > > + Endpoint Posture Attribute Value Collection BB: Collection > >Content Acquisition - Data is retrieved based on its relationship to > >the assessment and other applicability concepts to drive collection > >activities. > > + Endpoint Posture Attribute Value Collection BB: Posture Attribute > >Value Collection - Directives on how the posture attributes should be > >collected. This may include: events to monitor, scheduling info, > >instructions for using specific models/protocols, etc. > [NCW] I am not seeing strong distinctions of the Applicability Statements= vs. > Collection Instructions. As I see this converged through an endpoint prof= ile > that defines the attributes to be assessed for that particular endpoint. = Given > that profile, I would see how both applicability and collection duties ar= e > fulfilled. [daw: I don't think it is practical to specifically identify which attribut= es need to be assessed for every endpoint. This won't scale well to environ= ments that have many thousands of assets. It also won't scale well in envir= onments that are dynamic with new endpoints joining/leaving a network on a = regular basis. What is needed to address these challenges is a way to targe= t assessments dynamically based on logic that defines the attributes of app= licable endpoint targets in a way that allows endpoints to be targeted as t= hey are identified. We need to be able to describe classes of endpoints for= targeting. Using this kind of approach, an endpoint can be identified dynamically as t= he target of an assessment if it matches the targeted class. Then based on = the assessment policy, instructions can be sent to a collector to collect t= he appropriate posture attributes, and evaluation instructions can sent to = an evaluator to evaluate the collected data. The evaluator can then either = directly evaluate collected data and/or query previously collected data as = instructed. > >- Evaluation instructions: Data the identifies what endpoint posture > >attribute values are to be evaluated and how this evaluation should be > >performed. > > + Endpoint Identification and Assessment Planning BB: Posture > >Attribute Identification - Use to determine the set of posture > >attributes for which values are required for evaluation. > > + Posture Evaluation BB: Evaluation Content Acquisition - Data is > >retrieved based on its relationship to the assessment and other > >applicability concepts to drive evaluation activities. > > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs > >the evaluation of collected endpoint posture attribute values. This > >will likely include comparison operators and logical constructs. > >Additional instructions might indicate the required result output format= . > > > >Our information model will need to relate the concepts of applicability > >statements, collection instructions, and evaluation instructions in > >support of assessment activities. > [NCW] Why couldn't the evaluation instruction be extracted from the > endpoint assessment profile? [DAW: I believe there is a desire to decouple guidance for collection and e= valuation from policies that direct that this guidance should be applied to= a class of endpoints with specifics about how and when collection and eval= uation should be performed. This allows collection and evaluation rules to = be defined by software publishers and 3rd parties, and allows organizations= to define what events or time intervals trigger collection, and how often = evaluations should occur. Furthermore, by allowing evaluations to parameter= ized, organizations can specify specific expected values that are used for = evaluation. For example, a device and OS vendor might define collection guidance that i= s based on a standardized management protocol to identify what attributes s= hould be collected, they may also define evaluation guidance that is target= ed towards a specific use of their device (e.g. function) with recommended = expected values. A customer organization may define a corresponding collect= ion policy that requires that the identified posture attributes (by referen= cing the vendor collection guidance) be completely collected to establish a= baseline and then monitored for change events over time triggering increme= ntal collection as changes occur. The same organization may define an evalu= ation policy that is targeted to only devices on a specific LAN that requir= es evaluations to be performed daily at midnight UTC based on the current e= ffective collected posture of the device. As part of these evaluations they= override the recommended expected values for a subset of specific posture = attributes with organizationally defined stronger values. The organization = may then use different collection and evaluation timings and expected value= s for similar devices on a different LAN that has different security, opera= tional, or performance constraints. This is also a good example as to why collection and evaluation components = need to be separate architectural entities to account for the specialized i= nteractions with a collector and evaluator as described in the example.] > >Endpoint/Asset Attribute Data: > >-------------------------------------- > > > >This category includes contextual metadata pertaining to endpoints and > >the assets that they are composed of (e.g., hardware, software, > >accounts), and collected endpoint posture attributes, their associated > >values, and related context. > > > >This data tends to change in units of days, minutes, a seconds with > >posture attribute values typically changing more frequently than > >endpoint characterizations. This data tends to be organizationally and > >endpoint specific, with specific operational groups of endpoints > >tending to exhibit similar attribute profiles. This data will generally > >not be shared outside an organizational boundary and will generally > >require authentication with specific access controls. > > > >This would include: > > > >- Characterizations of endpoints: Endpoint metadata that describes the > >endpoint type, organizationally expected function/role, etc. > > + Endpoint Identification and Assessment Planning BB: Endpoint > >Characterization - Gathered through automated posture attribute > >collection, manual data entry/query, and interactions with other data > >stores. > > > >- Collected Posture Attributes: Posture attributes and associated > >values collected from endpoints representing hardware, software > >inventory, configurations, accounts/privileges, and other aspects of > endpoint state. > > + Endpoint Identification and Assessment Planning BB: Endpoint > >Component Inventory - This provides context to identify what posture > >attributes should be collected as part of the assessment based on the > >current endpoint posture (e.g., what software is installed). > > + Endpoint Posture Attribute Value Collection BB: Posture Attribute > >Value Collection - For each targeted endpoint, the set of collected > >posture attributes and associated values. The result of collection. > > + Posture Evaluation BB: Posture Attribute Value Query - The > >retrieval of a set of previously collected posture attributes and > >associated values. This may not be required if collected data is fed > >directly to an evaluator after collection. > > > >An important dimension here may be the separation between actual and > >expected posture attribute values. It may be possible to express > >guidance in a way that allows expected values to parameterized. In this > >case it will be necessary to allow for organizationally expected values > >to be associated with defined guidance (perhaps provided by a different > party). > > > >Our information model will need to relate the concepts of endpoint > >characterizations and collected posture information to the types of > >guidance data. > > > >Processing Artifacts: > >------------------------- > > > >This type of data is generated by and is specific to an individual > >assessment process. This data may be used as part of the interactions > >between SACM architectural components to drive and coordinate > >collection and evaluation activities. Its lifespan will be bounded by > >the lifespan of the assessment. It may also be exchanged and stored to > >provide historic context around an assessment activity. > > > >This would include: > > > >- Endpoint Targets: An identified set of endpoints for which an > >assessment should be performed. > > + Endpoint Identification and Assessment Planning BB: Identify > >Endpoint Targets - The endpoints targeted for an assessment. > > > >- Identified Posture Attributes > > + Endpoint Identification and Assessment Planning BB: Posture > >Attribute Identification - The required posture attributes that need to > >be collected to perform the evaluation. > > > >- Assessment Results: The resulting output generated by the evaluation > >process. > > + Posture Evaluation BB: Posture Attribute Evaluation - The results > >produced through the comparison of actual collected posture attribute > > values against their expected state. The specific output an > >evaluation criteria may be specified by the required evaluation > >instructions. > [NCW] Is it correct for me to conclude that "Processing artifacts" are > differentiated from "Endpoint attribute data" in that "Processing artifac= ts" > are basically the types of attributes that result from an "evaluation res= ult"? > My definition of "evaluation result" could be the processing result based= on > success in (endpoint) attribute collection or assessment (and the assessm= ent > could have been affected from 1 or more [endpoint] attributes)? [DAW: "Processing artifacts" are distinct from "Endpoint attribute data", a= lso called "Collected Posture Attributes" above. "Evaluation results" named= "Assessment Results" above (maybe this should be named "Evaluation Results= " for clarity) are one type of "Processing Artifact". Other types of "Proce= ssing Artifacts" include: "Endpoint Targets" which are the resolved set of = endpoints that are targeted for collection and evaluation operations, and "= Identified Posture Attributes" which are the individual posture attributes = that need to be collected from the "Endpoint Targets" as part of the collec= tion operation. I'm happy to name these differently if some other name is m= ore clear. IMHO, calling both the result of collection and the result of ev= aluation "evaluation results" will confuse these concepts and violates the = desired allowable separation we are working to achieve between collection a= nd evaluation interactions/processes.] > >Our information model will need to relate these concepts to those > >provided in the other two categories. I know this is not saying much, > >but I am tired and ready to end this email. ;-) > > > >> -----Original Message----- > >> From: Stephen Hanna [mailto:shanna@juniper.net] > >> Sent: Wednesday, February 05, 2014 10:48 PM > >> To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis > >> (pkampana); sacm@ietf.org > >> Subject: RE: [sacm] Types of content > >> > >> Gunnar Engelbach wrote: > >> > So "Guidance" is input and "collected attributes" is the immediate > >> > product? > >> > >> Right. At least, that's one way of describing it. > >> I'm thinking that guidance would include all the things that Dave was > >> previously calling "content". > >> > >> > That works. And is line with common usage. > >> > >> Good! I'm glad to hear that it makes sense to you. > >> > >> > And for the final result of applying the collected attributes to > >> > the guidance, how about "assessment results?" > >> > >> Yes, I like that also. > >> > >> > Is there a need for anything more granular? > >> > >> Probably eventually. But there also seems to be a need for broad > >>terms since people want to be able to put all the "guidance" into one > >>repository > >> (perhaps) and have a different kind of repository for "collected > >>attributes" > >> and maybe also "assessment results". > >> > >> > Mention of other terms commonly used for the same thing? > >> > >> Maybe. Listing alternative terms in common usage today can be > >> confusing since different people may use those terms differently. > >> > >> Thanks, > >> > >> Steve > >> > >> > > >> > > >> > What I frequently see: > >> > > >> > Input: > >> > Guidance > >> > Content > >> > Checklist > >> > Questionnaire > >> > Data stream > >> > Benchmark > >> > Definitions > >> > > >> > > >> > Product: > >> > Collected Attributes > >> > System Characteristics > >> > Assessment Results > >> > Posture > >> > > >> > > >> > > >> > > >> > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > >> > > The terms "content" and "data" are just too general. "SA content" > >> > > isn't much better. It seems to include any kind of data related > >> > > to security automation. In the long run, that might include lots > >> > > of things like vulnerability reports and alerts that an intrusion > >> > > has been detected and remediation or mitigation instructions. > >> > > Also reports on endpoint compliance and attributes that have been > >> > > collected from endpoints and maybe persisted. It's just not > >> > > useful to use one term for all those kinds of things. > >> > > > >> > > I think that we need a new, more specific term for the things > >> > > that Dave described below: attribute identifiers, lists of > >> > > attributes that are to be collected and when and perhaps how, and > >> > > policies about what attribute values are acceptable for different > >> > > kinds or groups of endpoints. I suggest that we use the > >> > > collective term "guidance" for these things. This indicates that > >> > > these things (and maybe others to be added > >> > > later) guide the attribute collection and evaluation process. > >> > > > >> > > We also need to have a term for attribute values that have been > >> > > collected from endpoints. I vote for "collected attributes". > >> > > These attributes might be persisted (stored) or maybe not. > >> > > Either way, they are attribute values that have been collected > >> > > from endpoints. > >> > > > >> > > Thanks, > >> > > > >> > > Steve > >> > > > >> > >> -----Original Message----- > >> > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > >> > Engelbach > >> > >> Sent: Wednesday, February 05, 2014 7:37 PM > >> > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > >> > (pkampana); > >> > >> sacm@ietf.org > >> > >> Subject: Re: [sacm] Types of content > >> > >> > >> > >> > >> > >> I would prefer to reserve the term "content" for the > >> > >> instructional documentation. That is, the documents that cause > >> > >> an action, be it legislation, prose guidance, or a set of > >> > >> machine instructions that implement that guidance. > >> > >> > >> > >> We typically use "system characteristics" when referring to > >> > collected > >> > >> items, and variations on "endpoint attributes" has been used > >> > frequently > >> > >> on this list. System characteristics are the product of > >> > >> applying content to an endpoint. > >> > >> > >> > >> Collectively it's all data. Is there a desire to have a general > >> > term > >> > >> for all data that could flow through a SACM implementation but > >> > >> is specific to SACM? > >> > >> > >> > >> > >> > >> Also, while I agree with the need to allow the ability to > >> > >> persist collected data items (and the results of posture > >> > >> evaluations), I > >> > don't > >> > >> see that as a requirement. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > >> > >>> Dictionaries of posture attributes was not intended to include > >> > >> attribute > >> > >>> values. IETF examples of this concept might include attributes > >> > >>> in a > >> > >> MIB > >> > >>> or a NETMOD model. > >> > >>> > >> > >>> I agree that we need to "persist" posture attribute values. I > >> > >>> have always been on the fence personally about calling > >> > >>> collection and evaluation results "content". I agree 100% that > >> > >>> we need to be > >> > crystal > >> > >>> clear about what we mean when we use the terms "content" and > >> > "content > >> > >>> repository". If we choose to lump all of this together as > >> > "content", > >> > >> we > >> > >>> will need to include some discussion in the use case document > >> > >>> contrasting different types of content to drive discussion of > >> > content > >> > >>> type-specific requirements. > >> > >>> > >> > >>> I also personally like Ira's feedback on using a more specific > >> > >> term(s) > >> > >>> instead of the more general "content". > >> > >>> > >> > >>> I also share the same personal view around interacting with > >> > >>> stores > >> > of > >> > >>> collected posture attribute values and evaluation results. The > >> > larger > >> > >>> data volumes and rate of change will likely require different > >> > >>> approaches. I also believe that the temporal nature of this > >> > >>> data, > >> > the > >> > >>> need to persist historic information, will be more significant > >> > >>> than other types of data that we may call "content". > >> > >>> > >> > >>> Are there other opinions on this? Does anyone feel strongly > >> > >>> that collected posture attribute values and evaluation results > >> > >>> SHOULD > >> > NOT > >> > >> be > >> > >>> considered content? > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> Dave > >> > >>> > >> > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > >> > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > >> > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > >> > >> sacm@ietf.org > >> > >>> *Subject:* RE: Types of content > >> > >>> > >> > >>> Would "dictionaries of posture attributes" include attribute > >> > >>> values > >> > >> that > >> > >>> have been collected from endpoints? > >> > >>> > >> > >>> We want to have the ability to collect attribute values from > >> > >> endpoints > >> > >>> and "persist" them, as described in section 2.1.3. So we'll > >> > >>> need to > >> > >> have > >> > >>> a repository for collected and persisted attribute values. > >> > >>> > >> > >>> If collected endpoint attribute values are considered content, > >> > let's > >> > >> say > >> > >>> so. If not, let's say that explicitly. > >> > >>> > >> > >>> My personal view is that collected endpoint attribute values > >> > >>> should > >> > >> be > >> > >>> considered content. They may be a different kind of content > >> > >>> from > >> > the > >> > >>> others due to larger volume and higher change rate. For that > >> > reason, > >> > >>> people may choose to put them into a different repository and > >> > >>> maybe > >> > >> even > >> > >>> use a different query protocol for that repository to munge the > >> > large > >> > >>> quantities of data. But they're still content. > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> Steve > >> > >>> > >> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Panos > >> > >>> Kampanakis (pkampana) > >> > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > >> > >>> *To:* Waltermire, David A.; sacm@ietf.org > >> > >>> > >> > >>> *Subject:* Re: [sacm] Types of content > >> > >>> > >> > >>> Sounds like a good summary of what "content" could mean. > >> > >>> > >> > >>> Panos > >> > >>> > >> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > >> > *Waltermire, > >> > >>> David A. > >> > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > >> > >>> *To:* sacm@ietf.org > >> > >>> *Subject:* [sacm] Types of content > >> > >>> > >> > >>> I'm working through the UC draft addressing discussion items > >> > >>> from yesterday and the previous comments we have received on > >> > >>> the list on > >> > - > >> > >> 05. > >> > >>> > >> > >>> Related to section 2.1.1, we have had many previous discussions > >> > >> around > >> > >>> the notional idea of content. There has been general agreement > >> > >>> that > >> > >> we > >> > >>> need to be more specific. Please find below an attempt to put > >> > >>> some "bounds" around different types of content. > >> > >>> > >> > >>> Is this hitting the mark, or do we need to say something > >> > >> more/different? > >> > >>> > >> > >>> The following is a snippet from a possible update to section > >> > >>> 2.1.1 > >> > >> with > >> > >>> some additional description: > >> > >>> > >> > >>> I'd appreciate any thoughts, concerns, objections before I > >> > >>> include > >> > >> the > >> > >>> changes in the draft. > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> Dave > >> > >>> > >> > >>> 2.1.1. Define, Publish, Query and Retrieve Content > >> > >>> > >> > >>> This use case describes the need for content to be defined > >> > >>> and > >> > >>> > >> > >>> published to a data store, as well as queried and > >> > >>> retrieved > >> > from > >> > >> the > >> > >>> > >> > >>> data store for the explicit use of posture collection and > >> > >> evaluation. > >> > >>> > >> > >>> The term "content" is a general concept that refers to any > >> > data > >> > >>> > >> > >>> expression that may be used as part of the process of > >> > collecting > >> > >> and > >> > >>> > >> > >>> evaluating endpoint posture. Typical types of content > >> > include: > >> > >>> > >> > >>> o Dictionaries of posture attributes (e.g. software > >> > >> installation, > >> > >>> > >> > >>> configuration, privileges) that may be collected from a > >> > given > >> > >>> > >> > >>> endpoint type that relate to installed hardware, > >> > >>> installed > >> > >>> > >> > >>> software, software configurations, accounts, > >> > >>> privileges, > >> > and > >> > >> other > >> > >>> > >> > >>> operational state. > >> > >>> > >> > >>> o Expressions that provide instructions for using a > >> > >>> specific > >> > >> API, > >> > >>> > >> > >>> management protocol, or other mechanisms to collect > >> > specific > >> > >>> > >> > >>> posture attributes from specific device types. > >> > >>> > >> > >>> o Policies that define the selected posture attributes > >> > >>> for > >> > which > >> > >>> > >> > >>> values must be collected to support one or more posture > >> > >>> > >> > >>> assessments. This may include information that targets > >> > >> collection > >> > >>> > >> > >>> to a specific set of endpoints and instructions on the > >> > >> frequency > >> > >>> > >> > >>> and/or change events (e.g., configuration changes, > >> > >>> software > >> > >>> > >> > >>> installation/uninstallation, account/privilege > >> > modifications) > >> > >> that > >> > >>> > >> > >>> will trigger collection of one or more posture attribute= s. > >> > >>> > >> > >>> o Policies that define the logical criteria to evaluate > >> > >> collected > >> > >>> > >> > >>> posture attribute values to determine if they meet > >> > >> organizational > >> > >>> > >> > >>> requirements. This may include information that > >> > >>> targets > >> > >>> > >> > >>> evaluation to a specific set of endpoints. > >> > >>> > >> > >>> > >> > >>> > >> > >>> _______________________________________________ > >> > >>> sacm mailing list > >> > >>> sacm@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/sacm > >> > >>> > >> > >> _______________________________________________ > >> > >> sacm mailing list > >> > >> sacm@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/sacm > >> > >> > >> > > > >> > > > >> > > >> > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm From nobody Wed Feb 19 05:57:25 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A531A031B for ; Tue, 18 Feb 2014 18:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-M65BHY6gbL for ; Tue, 18 Feb 2014 18:19:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7881A02AC for ; Tue, 18 Feb 2014 18:19:52 -0800 (PST) Received: from BY2PR09MB016.namprd09.prod.outlook.com (10.242.35.156) by BY2PR09MB045.namprd09.prod.outlook.com (10.242.35.142) with Microsoft SMTP Server (TLS) id 15.0.878.16; Wed, 19 Feb 2014 02:19:46 +0000 Received: from BY2PR09MB016.namprd09.prod.outlook.com ([169.254.5.95]) by BY2PR09MB016.namprd09.prod.outlook.com ([169.254.5.95]) with mapi id 15.00.0878.008; Wed, 19 Feb 2014 02:19:46 +0000 From: "Grance, Tim" To: "Waltermire, David A." , "Nancy Cam-Winget (ncamwing)" , Stephen Hanna , "Gunnar Engelbach" , "Panos Kampanakis (pkampana)" , "sacm@ietf.org" Thread-Topic: [sacm] Types of content Thread-Index: Ac8isHWVSyRLr1V0S1aTuYf1r3WzKwAEJC6wAAFlfTAAAD/IIAAC/kAAAAL7vVAAAzOpAAAARPnQARgzlgAApbydgADJGEHQAAPguq0= Date: Wed, 19 Feb 2014 02:19:45 +0000 Message-ID: <21f25fc953134f61a0564e52565fdc84@BY2PR09MB016.namprd09.prod.outlook.com> References: , <83708abbee37498b8a61dd2272e700ba@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <83708abbee37498b8a61dd2272e700ba@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.16.52] x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(52604005)(51704005)(46034005)(479174003)(13464003)(164054003)(51444003)(377454003)(24454002)(57704003)(83322001)(19580405001)(19580395003)(94316002)(86362001)(74502001)(93136001)(77982001)(95666001)(33646001)(95416001)(74366001)(76786001)(76796001)(74316001)(80976001)(76576001)(81816001)(59766001)(94946001)(92566001)(74662001)(31966008)(15975445006)(79102001)(81686001)(56776001)(47446002)(93516002)(90146001)(46102001)(4396001)(47736001)(49866001)(83072002)(63696002)(85852003)(77096001)(87936001)(2656002)(47976001)(87266001)(1941001)(50986001)(74706001)(74876001)(65816001)(66066001)(80022001)(56816005)(69226001)(51856001)(85306002)(76482001)(54356001)(54316002)(81342001)(81542001)(53806001)(24736002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB045; H:BY2PR09MB016.namprd09.prod.outlook.com; CLIP:129.6.16.52; FPR:EE7CF1D5.ABFAA142.B8D1F16B.82E4CB41.20948; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/IIxt6xWosMXbcsC5WiEHYC5gFnU X-Mailman-Approved-At: Wed, 19 Feb 2014 05:57:22 -0800 Subject: Re: [sacm] Types of content X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 02:19:58 -0000 ________________________________________ From: sacm on behalf of Waltermire, David A. Sent: Tuesday, February 18, 2014 8:33:03 PM To: Nancy Cam-Winget (ncamwing); Stephen Hanna; Gunnar Engelbach; Panos Kam= panakis (pkampana); sacm@ietf.org Subject: Re: [sacm] Types of content Nancy, Thanks for your feedback. I have some comments below: > -----Original Message----- > From: Nancy Cam-Winget (ncamwing) [mailto:ncamwing@cisco.com] > Sent: Friday, February 14, 2014 7:31 PM > To: Waltermire, David A.; Stephen Hanna; Gunnar Engelbach; Panos > Kampanakis (pkampana); sacm@ietf.org > Subject: Re: [sacm] Types of content > > Hi Dave: > > Thanks for putting more clarity, I have some comments and questions below= : > > On 2/11/14 4:13 PM, "Waltermire, David A." > wrote: > > >I'd like to get the discussion around this topic to a point where I > >have clear editorial direction on what text we want included in the > >updated use case draft for this Friday's submission cutoff deadline. > > > >Based on the mailing list discussions to date, I'd like to propose the > >following categories of security automation data for inclusion in the > >use cases draft: Guidance, Endpoint/Asset Attribute Data, and > >Processing Artifacts. > > > >The following sections roughly define each of the proposed categories. > >For each section some insights are provided into the how the data might > >be sourced and how often it may change. I have also included examples > >of the classes of information for each category with mappings to the > >use cases and building blocks they support to insure we have the > >necessary coverage. > > > >To move forward I need answers to the following questions: > > > >1) Do you like these groupings? If not, is there a better set of > >groupings? > [NCW] It is an improvement, but please see my further comments and > questions below. > > > >2) Do you like the labels for each of the groups? If not, do you have a > >better label(s)? > [NCW] I'm OK with the current groupings, though I'd like to keep the mode= l > as simple as possible. > > >3) Are there other types of content that should be included? > >4) What level of detail should be included in the use cases draft > >regarding this discussion? What I have below is likely too much detail. > [NCW] I agree with Steve H. that this is probably too much details for th= e use > cases. [DAW: Putting on my editor hat... Nancy et al... Please take a look at the = -06 use case draft and let me know if the level of detail is good. I tried = to strike a balance. I'm not sure if it is the right balance though.] > > > >Thanks, > >Dave > > > >Guidance: > >------------ > >The term "guidance" was proposed by Steve Hanna and was supported by > >Gunnar Engelbach on the list. Steve proposed that this concept > >encompasses "attribute identifiers, lists of attributes that are to be > >collected and when and perhaps how, and policies about what attribute > >values are acceptable for different kinds or groups of endpoints. This > >indicates that these things (and maybe others to be added later) guide > >the attribute collection and evaluation process." I would also add that > >this should include instructions supporting data-driven evaluation > >processes. > > > >This data tends to change in units of months and days. In cases where > >assessments are made more dynamic, it may be necessary to handle > >changes in the scope of hours or minutes. This data will typically be > >provided by large organizations, product vendors, and some 3rd-parties. > >Thus, it will tend to be shared across large enterprises and customer > >communities. In some cases access may be controlled to specific > >authenticated users. In other cases, the data may be provided broadly > >with little to no access control. > > > >This would include: > > > >- Applicability Statements: Data the identifies the conditional > >applicability of an assessment (and related assessment "guidance") > >based on automated collection of endpoint posture attribute values and > >other endpoint characterizations. > > + Endpoint Identification and Assessment Planning BB: Identify > >Endpoint Targets - This supports the targeting concept allowing > >characterizations and collected posture attribute values to be > >evaluated to determine what set of endpoints should be assessed. > > > >- Collection Instructions: Data that drives the identification of the > >set of posture attributes needed to perform an assessment and the > >collection of posture attributes. > > + Endpoint Identification and Assessment Planning BB: Posture > >Attribute Identification - Used to determine the set of posture > >attributes for which values must be collected (or retrieved) to support > >the evaluation. > > + Endpoint Posture Attribute Value Collection BB: Collection > >Content Acquisition - Data is retrieved based on its relationship to > >the assessment and other applicability concepts to drive collection > >activities. > > + Endpoint Posture Attribute Value Collection BB: Posture Attribute > >Value Collection - Directives on how the posture attributes should be > >collected. This may include: events to monitor, scheduling info, > >instructions for using specific models/protocols, etc. > [NCW] I am not seeing strong distinctions of the Applicability Statements= vs. > Collection Instructions. As I see this converged through an endpoint prof= ile > that defines the attributes to be assessed for that particular endpoint. = Given > that profile, I would see how both applicability and collection duties ar= e > fulfilled. [daw: I don't think it is practical to specifically identify which attribut= es need to be assessed for every endpoint. This won't scale well to environ= ments that have many thousands of assets. It also won't scale well in envir= onments that are dynamic with new endpoints joining/leaving a network on a = regular basis. What is needed to address these challenges is a way to targe= t assessments dynamically based on logic that defines the attributes of app= licable endpoint targets in a way that allows endpoints to be targeted as t= hey are identified. We need to be able to describe classes of endpoints for= targeting. Using this kind of approach, an endpoint can be identified dynamically as t= he target of an assessment if it matches the targeted class. Then based on = the assessment policy, instructions can be sent to a collector to collect t= he appropriate posture attributes, and evaluation instructions can sent to = an evaluator to evaluate the collected data. The evaluator can then either = directly evaluate collected data and/or query previously collected data as = instructed. > >- Evaluation instructions: Data the identifies what endpoint posture > >attribute values are to be evaluated and how this evaluation should be > >performed. > > + Endpoint Identification and Assessment Planning BB: Posture > >Attribute Identification - Use to determine the set of posture > >attributes for which values are required for evaluation. > > + Posture Evaluation BB: Evaluation Content Acquisition - Data is > >retrieved based on its relationship to the assessment and other > >applicability concepts to drive evaluation activities. > > + Posture Evaluation BB: Posture Attribute Evaluation - Instructs > >the evaluation of collected endpoint posture attribute values. This > >will likely include comparison operators and logical constructs. > >Additional instructions might indicate the required result output format= . > > > >Our information model will need to relate the concepts of applicability > >statements, collection instructions, and evaluation instructions in > >support of assessment activities. > [NCW] Why couldn't the evaluation instruction be extracted from the > endpoint assessment profile? [DAW: I believe there is a desire to decouple guidance for collection and e= valuation from policies that direct that this guidance should be applied to= a class of endpoints with specifics about how and when collection and eval= uation should be performed. This allows collection and evaluation rules to = be defined by software publishers and 3rd parties, and allows organizations= to define what events or time intervals trigger collection, and how often = evaluations should occur. Furthermore, by allowing evaluations to parameter= ized, organizations can specify specific expected values that are used for = evaluation. For example, a device and OS vendor might define collection guidance that i= s based on a standardized management protocol to identify what attributes s= hould be collected, they may also define evaluation guidance that is target= ed towards a specific use of their device (e.g. function) with recommended = expected values. A customer organization may define a corresponding collect= ion policy that requires that the identified posture attributes (by referen= cing the vendor collection guidance) be completely collected to establish a= baseline and then monitored for change events over time triggering increme= ntal collection as changes occur. The same organization may define an evalu= ation policy that is targeted to only devices on a specific LAN that requir= es evaluations to be performed daily at midnight UTC based on the current e= ffective collected posture of the device. As part of these evaluations they= override the recommended expected values for a subset of specific posture = attributes with organiz ationally defined stronger values. The organization may then use different= collection and evaluation timings and expected values for similar devices = on a different LAN that has different security, operational, or performanc= e constraints. This is also a good example as to why collection and evaluation components = need to be separate architectural entities to account for the specialized i= nteractions with a collector and evaluator as described in the example.] > >Endpoint/Asset Attribute Data: > >-------------------------------------- > > > >This category includes contextual metadata pertaining to endpoints and > >the assets that they are composed of (e.g., hardware, software, > >accounts), and collected endpoint posture attributes, their associated > >values, and related context. > > > >This data tends to change in units of days, minutes, a seconds with > >posture attribute values typically changing more frequently than > >endpoint characterizations. This data tends to be organizationally and > >endpoint specific, with specific operational groups of endpoints > >tending to exhibit similar attribute profiles. This data will generally > >not be shared outside an organizational boundary and will generally > >require authentication with specific access controls. > > > >This would include: > > > >- Characterizations of endpoints: Endpoint metadata that describes the > >endpoint type, organizationally expected function/role, etc. > > + Endpoint Identification and Assessment Planning BB: Endpoint > >Characterization - Gathered through automated posture attribute > >collection, manual data entry/query, and interactions with other data > >stores. > > > >- Collected Posture Attributes: Posture attributes and associated > >values collected from endpoints representing hardware, software > >inventory, configurations, accounts/privileges, and other aspects of > endpoint state. > > + Endpoint Identification and Assessment Planning BB: Endpoint > >Component Inventory - This provides context to identify what posture > >attributes should be collected as part of the assessment based on the > >current endpoint posture (e.g., what software is installed). > > + Endpoint Posture Attribute Value Collection BB: Posture Attribute > >Value Collection - For each targeted endpoint, the set of collected > >posture attributes and associated values. The result of collection. > > + Posture Evaluation BB: Posture Attribute Value Query - The > >retrieval of a set of previously collected posture attributes and > >associated values. This may not be required if collected data is fed > >directly to an evaluator after collection. > > > >An important dimension here may be the separation between actual and > >expected posture attribute values. It may be possible to express > >guidance in a way that allows expected values to parameterized. In this > >case it will be necessary to allow for organizationally expected values > >to be associated with defined guidance (perhaps provided by a different > party). > > > >Our information model will need to relate the concepts of endpoint > >characterizations and collected posture information to the types of > >guidance data. > > > >Processing Artifacts: > >------------------------- > > > >This type of data is generated by and is specific to an individual > >assessment process. This data may be used as part of the interactions > >between SACM architectural components to drive and coordinate > >collection and evaluation activities. Its lifespan will be bounded by > >the lifespan of the assessment. It may also be exchanged and stored to > >provide historic context around an assessment activity. > > > >This would include: > > > >- Endpoint Targets: An identified set of endpoints for which an > >assessment should be performed. > > + Endpoint Identification and Assessment Planning BB: Identify > >Endpoint Targets - The endpoints targeted for an assessment. > > > >- Identified Posture Attributes > > + Endpoint Identification and Assessment Planning BB: Posture > >Attribute Identification - The required posture attributes that need to > >be collected to perform the evaluation. > > > >- Assessment Results: The resulting output generated by the evaluation > >process. > > + Posture Evaluation BB: Posture Attribute Evaluation - The results > >produced through the comparison of actual collected posture attribute > > values against their expected state. The specific output an > >evaluation criteria may be specified by the required evaluation > >instructions. > [NCW] Is it correct for me to conclude that "Processing artifacts" are > differentiated from "Endpoint attribute data" in that "Processing artifac= ts" > are basically the types of attributes that result from an "evaluation res= ult"? > My definition of "evaluation result" could be the processing result based= on > success in (endpoint) attribute collection or assessment (and the assessm= ent > could have been affected from 1 or more [endpoint] attributes)? [DAW: "Processing artifacts" are distinct from "Endpoint attribute data", a= lso called "Collected Posture Attributes" above. "Evaluation results" named= "Assessment Results" above (maybe this should be named "Evaluation Results= " for clarity) are one type of "Processing Artifact". Other types of "Proce= ssing Artifacts" include: "Endpoint Targets" which are the resolved set of = endpoints that are targeted for collection and evaluation operations, and "= Identified Posture Attributes" which are the individual posture attributes = that need to be collected from the "Endpoint Targets" as part of the collec= tion operation. I'm happy to name these differently if some other name is m= ore clear. IMHO, calling both the result of collection and the result of ev= aluation "evaluation results" will confuse these concepts and violates the = desired allowable separation we are working to achieve between collection a= nd evaluation interactions/processes.] > >Our information model will need to relate these concepts to those > >provided in the other two categories. I know this is not saying much, > >but I am tired and ready to end this email. ;-) > > > >> -----Original Message----- > >> From: Stephen Hanna [mailto:shanna@juniper.net] > >> Sent: Wednesday, February 05, 2014 10:48 PM > >> To: Gunnar Engelbach; Waltermire, David A.; Panos Kampanakis > >> (pkampana); sacm@ietf.org > >> Subject: RE: [sacm] Types of content > >> > >> Gunnar Engelbach wrote: > >> > So "Guidance" is input and "collected attributes" is the immediate > >> > product? > >> > >> Right. At least, that's one way of describing it. > >> I'm thinking that guidance would include all the things that Dave was > >> previously calling "content". > >> > >> > That works. And is line with common usage. > >> > >> Good! I'm glad to hear that it makes sense to you. > >> > >> > And for the final result of applying the collected attributes to > >> > the guidance, how about "assessment results?" > >> > >> Yes, I like that also. > >> > >> > Is there a need for anything more granular? > >> > >> Probably eventually. But there also seems to be a need for broad > >>terms since people want to be able to put all the "guidance" into one > >>repository > >> (perhaps) and have a different kind of repository for "collected > >>attributes" > >> and maybe also "assessment results". > >> > >> > Mention of other terms commonly used for the same thing? > >> > >> Maybe. Listing alternative terms in common usage today can be > >> confusing since different people may use those terms differently. > >> > >> Thanks, > >> > >> Steve > >> > >> > > >> > > >> > What I frequently see: > >> > > >> > Input: > >> > Guidance > >> > Content > >> > Checklist > >> > Questionnaire > >> > Data stream > >> > Benchmark > >> > Definitions > >> > > >> > > >> > Product: > >> > Collected Attributes > >> > System Characteristics > >> > Assessment Results > >> > Posture > >> > > >> > > >> > > >> > > >> > On 2/5/2014 9:13 PM, Stephen Hanna wrote: > >> > > The terms "content" and "data" are just too general. "SA content" > >> > > isn't much better. It seems to include any kind of data related > >> > > to security automation. In the long run, that might include lots > >> > > of things like vulnerability reports and alerts that an intrusion > >> > > has been detected and remediation or mitigation instructions. > >> > > Also reports on endpoint compliance and attributes that have been > >> > > collected from endpoints and maybe persisted. It's just not > >> > > useful to use one term for all those kinds of things. > >> > > > >> > > I think that we need a new, more specific term for the things > >> > > that Dave described below: attribute identifiers, lists of > >> > > attributes that are to be collected and when and perhaps how, and > >> > > policies about what attribute values are acceptable for different > >> > > kinds or groups of endpoints. I suggest that we use the > >> > > collective term "guidance" for these things. This indicates that > >> > > these things (and maybe others to be added > >> > > later) guide the attribute collection and evaluation process. > >> > > > >> > > We also need to have a term for attribute values that have been > >> > > collected from endpoints. I vote for "collected attributes". > >> > > These attributes might be persisted (stored) or maybe not. > >> > > Either way, they are attribute values that have been collected > >> > > from endpoints. > >> > > > >> > > Thanks, > >> > > > >> > > Steve > >> > > > >> > >> -----Original Message----- > >> > >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar > >> > Engelbach > >> > >> Sent: Wednesday, February 05, 2014 7:37 PM > >> > >> To: Waltermire, David A.; Stephen Hanna; Panos Kampanakis > >> > (pkampana); > >> > >> sacm@ietf.org > >> > >> Subject: Re: [sacm] Types of content > >> > >> > >> > >> > >> > >> I would prefer to reserve the term "content" for the > >> > >> instructional documentation. That is, the documents that cause > >> > >> an action, be it legislation, prose guidance, or a set of > >> > >> machine instructions that implement that guidance. > >> > >> > >> > >> We typically use "system characteristics" when referring to > >> > collected > >> > >> items, and variations on "endpoint attributes" has been used > >> > frequently > >> > >> on this list. System characteristics are the product of > >> > >> applying content to an endpoint. > >> > >> > >> > >> Collectively it's all data. Is there a desire to have a general > >> > term > >> > >> for all data that could flow through a SACM implementation but > >> > >> is specific to SACM? > >> > >> > >> > >> > >> > >> Also, while I agree with the need to allow the ability to > >> > >> persist collected data items (and the results of posture > >> > >> evaluations), I > >> > don't > >> > >> see that as a requirement. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On 2/5/2014 6:33 PM, Waltermire, David A. wrote: > >> > >>> Dictionaries of posture attributes was not intended to include > >> > >> attribute > >> > >>> values. IETF examples of this concept might include attributes > >> > >>> in a > >> > >> MIB > >> > >>> or a NETMOD model. > >> > >>> > >> > >>> I agree that we need to "persist" posture attribute values. I > >> > >>> have always been on the fence personally about calling > >> > >>> collection and evaluation results "content". I agree 100% that > >> > >>> we need to be > >> > crystal > >> > >>> clear about what we mean when we use the terms "content" and > >> > "content > >> > >>> repository". If we choose to lump all of this together as > >> > "content", > >> > >> we > >> > >>> will need to include some discussion in the use case document > >> > >>> contrasting different types of content to drive discussion of > >> > content > >> > >>> type-specific requirements. > >> > >>> > >> > >>> I also personally like Ira's feedback on using a more specific > >> > >> term(s) > >> > >>> instead of the more general "content". > >> > >>> > >> > >>> I also share the same personal view around interacting with > >> > >>> stores > >> > of > >> > >>> collected posture attribute values and evaluation results. The > >> > larger > >> > >>> data volumes and rate of change will likely require different > >> > >>> approaches. I also believe that the temporal nature of this > >> > >>> data, > >> > the > >> > >>> need to persist historic information, will be more significant > >> > >>> than other types of data that we may call "content". > >> > >>> > >> > >>> Are there other opinions on this? Does anyone feel strongly > >> > >>> that collected posture attribute values and evaluation results > >> > >>> SHOULD > >> > NOT > >> > >> be > >> > >>> considered content? > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> Dave > >> > >>> > >> > >>> *From:*Stephen Hanna [mailto:shanna@juniper.net] > >> > >>> *Sent:* Wednesday, February 05, 2014 6:10 PM > >> > >>> *To:* Panos Kampanakis (pkampana); Waltermire, David A.; > >> > >> sacm@ietf.org > >> > >>> *Subject:* RE: Types of content > >> > >>> > >> > >>> Would "dictionaries of posture attributes" include attribute > >> > >>> values > >> > >> that > >> > >>> have been collected from endpoints? > >> > >>> > >> > >>> We want to have the ability to collect attribute values from > >> > >> endpoints > >> > >>> and "persist" them, as described in section 2.1.3. So we'll > >> > >>> need to > >> > >> have > >> > >>> a repository for collected and persisted attribute values. > >> > >>> > >> > >>> If collected endpoint attribute values are considered content, > >> > let's > >> > >> say > >> > >>> so. If not, let's say that explicitly. > >> > >>> > >> > >>> My personal view is that collected endpoint attribute values > >> > >>> should > >> > >> be > >> > >>> considered content. They may be a different kind of content > >> > >>> from > >> > the > >> > >>> others due to larger volume and higher change rate. For that > >> > reason, > >> > >>> people may choose to put them into a different repository and > >> > >>> maybe > >> > >> even > >> > >>> use a different query protocol for that repository to munge the > >> > large > >> > >>> quantities of data. But they're still content. > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> Steve > >> > >>> > >> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Panos > >> > >>> Kampanakis (pkampana) > >> > >>> *Sent:* Wednesday, February 05, 2014 5:25 PM > >> > >>> *To:* Waltermire, David A.; sacm@ietf.org > >> > >>> > >> > >>> *Subject:* Re: [sacm] Types of content > >> > >>> > >> > >>> Sounds like a good summary of what "content" could mean. > >> > >>> > >> > >>> Panos > >> > >>> > >> > >>> *From:*sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of > >> > *Waltermire, > >> > >>> David A. > >> > >>> *Sent:* Wednesday, February 05, 2014 10:38 PM > >> > >>> *To:* sacm@ietf.org > >> > >>> *Subject:* [sacm] Types of content > >> > >>> > >> > >>> I'm working through the UC draft addressing discussion items > >> > >>> from yesterday and the previous comments we have received on > >> > >>> the list on > >> > - > >> > >> 05. > >> > >>> > >> > >>> Related to section 2.1.1, we have had many previous discussions > >> > >> around > >> > >>> the notional idea of content. There has been general agreement > >> > >>> that > >> > >> we > >> > >>> need to be more specific. Please find below an attempt to put > >> > >>> some "bounds" around different types of content. > >> > >>> > >> > >>> Is this hitting the mark, or do we need to say something > >> > >> more/different? > >> > >>> > >> > >>> The following is a snippet from a possible update to section > >> > >>> 2.1.1 > >> > >> with > >> > >>> some additional description: > >> > >>> > >> > >>> I'd appreciate any thoughts, concerns, objections before I > >> > >>> include > >> > >> the > >> > >>> changes in the draft. > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> Dave > >> > >>> > >> > >>> 2.1.1. Define, Publish, Query and Retrieve Content > >> > >>> > >> > >>> This use case describes the need for content to be defined > >> > >>> and > >> > >>> > >> > >>> published to a data store, as well as queried and > >> > >>> retrieved > >> > from > >> > >> the > >> > >>> > >> > >>> data store for the explicit use of posture collection and > >> > >> evaluation. > >> > >>> > >> > >>> The term "content" is a general concept that refers to any > >> > data > >> > >>> > >> > >>> expression that may be used as part of the process of > >> > collecting > >> > >> and > >> > >>> > >> > >>> evaluating endpoint posture. Typical types of content > >> > include: > >> > >>> > >> > >>> o Dictionaries of posture attributes (e.g. software > >> > >> installation, > >> > >>> > >> > >>> configuration, privileges) that may be collected from a > >> > given > >> > >>> > >> > >>> endpoint type that relate to installed hardware, > >> > >>> installed > >> > >>> > >> > >>> software, software configurations, accounts, > >> > >>> privileges, > >> > and > >> > >> other > >> > >>> > >> > >>> operational state. > >> > >>> > >> > >>> o Expressions that provide instructions for using a > >> > >>> specific > >> > >> API, > >> > >>> > >> > >>> management protocol, or other mechanisms to collect > >> > specific > >> > >>> > >> > >>> posture attributes from specific device types. > >> > >>> > >> > >>> o Policies that define the selected posture attributes > >> > >>> for > >> > which > >> > >>> > >> > >>> values must be collected to support one or more posture > >> > >>> > >> > >>> assessments. This may include information that targets > >> > >> collection > >> > >>> > >> > >>> to a specific set of endpoints and instructions on the > >> > >> frequency > >> > >>> > >> > >>> and/or change events (e.g., configuration changes, > >> > >>> software > >> > >>> > >> > >>> installation/uninstallation, account/privilege > >> > modifications) > >> > >> that > >> > >>> > >> > >>> will trigger collection of one or more posture attribute= s. > >> > >>> > >> > >>> o Policies that define the logical criteria to evaluate > >> > >> collected > >> > >>> > >> > >>> posture attribute values to determine if they meet > >> > >> organizational > >> > >>> > >> > >>> requirements. This may include information that > >> > >>> targets > >> > >>> > >> > >>> evaluation to a specific set of endpoints. > >> > >>> > >> > >>> > >> > >>> > >> > >>> _______________________________________________ > >> > >>> sacm mailing list > >> > >>> sacm@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/sacm > >> > >>> > >> > >> _______________________________________________ > >> > >> sacm mailing list > >> > >> sacm@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/sacm > >> > >> > >> > > > >> > > > >> > > >> > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From nobody Sat Feb 22 03:56:22 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9842F1A00D4 for ; Sat, 22 Feb 2014 03:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUZRRh9KpzwT for ; Sat, 22 Feb 2014 03:56:18 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id D6D431A0051 for ; Sat, 22 Feb 2014 03:56:16 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee153088fd3090-58090; Sat, 22 Feb 2014 19:53:56 +0800 (CST) X-RM-TRANSID: 2ee153088fd3090-58090 Received: from [192.168.0.101] (unknown[222.130.243.232]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee153088fd256d-65d27; Sat, 22 Feb 2014 19:53:56 +0800 (CST) X-RM-TRANSID: 2ee153088fd256d-65d27 From: =?utf-8?B?6b2Q5pe76bmP?= Content-Type: multipart/alternative; boundary="Apple-Mail=_CF2BD39E-0B55-4661-8A49-BF21A9211CFD" Message-Id: <8B11C20A-1BBF-4F7F-9101-57EDA319C74D@chinamobile.com> Date: Sat, 22 Feb 2014 19:58:08 +0800 To: sacm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/IhUjws7zGWAZLhXJp2WruAs3HS8 Subject: [sacm] New Version Notification of draft-zhuang-sacm-telereq-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 11:56:20 -0000 --Apple-Mail=_CF2BD39E-0B55-4661-8A49-BF21A9211CFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi all, Due to the submission problem, we submitted a new version of = telecommunication requirement draft with secretary=A1=AFs help just now: = draft-zhuang-sacm-telereq-00.=20 Your review and comments are valuable and welcome. The information for this draft is as below: Name: draft-zhuang-sacm-telereq Revision: 00 Title: Telecommunication Requirement Document date: 2014-02-08 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/id/draft-zhuang-sacm-telereq-00.txt Status: https://datatracker.ietf.org/doc/draft-zhuang-sacm-telereq/ Htmlized: http://tools.ietf.org/html/draft-zhuang-sacm-telereq-00 Abstract =20 This memo documents an additional use cases based on the endpoint = security posture assessment-enterprise use cases. =46rom all use cases, we can=20= drive common functional capabilities and requirements to guide = development=20 the standards for security posture assessment of the = telecommunication and enterprise equipment. BRs, Minpeng= --Apple-Mail=_CF2BD39E-0B55-4661-8A49-BF21A9211CFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi = all,

Due to the submission problem, we submitted a new version of = telecommunication requirement draft with secretary=A1=AFs help just now: = draft-zhuang-sacm-telereq-00. 

Your review and = comments are valuable and welcome.

The = information for this draft is as = below:

Name: = draft-zhuang-sacm-telereq
Revision: = 00
Title: Telecommunication Requirement
Document date: = 2014-02-08
Group: Individual = Submission
Pages: 8
URL:
http://ww= w.ietf.org/id/draft-zhuang-sacm-telereq-00.txt
Status:
https= ://datatracker.ietf.org/doc/draft-zhuang-sacm-telereq/
Htmlized:http://to= ols.ietf.org/html/draft-zhuang-sacm-telereq-00


Ab= stract   
   This memo documents an = additional use cases based on the endpoint security
  =  posture assessment-enterprise use cases. =46rom all use cases, we = can 
   drive common functional capabilities = and requirements to guide development 
   the = standards for security posture assessment of the = telecommunication
   and enterprise = equipment.


BRs,
Minpeng
= --Apple-Mail=_CF2BD39E-0B55-4661-8A49-BF21A9211CFD-- From nobody Sat Feb 22 07:34:38 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527331A0102 for ; Sat, 22 Feb 2014 07:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_jAqch3S3p9 for ; Sat, 22 Feb 2014 07:34:35 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 6F36F1A00FD for ; Sat, 22 Feb 2014 07:34:35 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id VTZJ1n0040xGWP85FTaXBL; Sat, 22 Feb 2014 15:34:31 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.westchester.pa.mail.comcast.net with comcast id VTaW1n00r2yZEBF3YTaWun; Sat, 22 Feb 2014 15:34:31 +0000 From: "ietfdbh" To: Date: Sat, 22 Feb 2014 10:34:30 -0500 Message-ID: <019601cf2fe3$94698a20$bd3c9e60$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8v270isI1WPLwOQEmz123IlqnCnA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393083271; bh=vZLTxZW+E3D7N8JELByOCTEIQpeORR6Z6rGtfBT/fUg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=V7779gRmi6n0YT2jFCjZJCp1ltlAl5090SMkc8+/3sXTfozEvxYCi9e4nW7x7vssv qyj45TZduT5i+78ijcORO6dpeCTTtVSWpckCRq0FJj3uZ0niEOntbgqdI5SE0ciFlc JWTolnA4vvRd1KVXs2WJlfruqUINxZ+4end9Y5KYuOJn96qmHGgKXJB9MdzUm7xLNh ktjvkfDZg+zs/Ol1PO0GeTcmWqchPY5Ktn/K7fV65VGh1crseZIQnFC2aKekW4VhoJ BwwgqmkYnAzSoW1BuBjL1vcGZzVftLFDXSpTG0cQ5bGSUO4VNYl2vW8L9M1PCSjwaC 26cssp7OnPMWA== Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/g-uofGWXGCtt9x5TWuEFTDPhjqU Cc: sacm@ietf.org Subject: [sacm] draft-zhuang-sacm-telereq-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 15:34:37 -0000 Hi, There are a number of spelling errors in the draft. At tools.ietf.org, there is a link to a spell-checker for internet-drafts (http://tools.ietf.org/tools/idspell/webservice) I quickly reviewed this draft, and have two comments. 1) The Introduction says " SACM will create an automated tool for security assessment about network devices in enterprise scenario." That is inaccurate. SACM is not expected to create any tools; the IETF does not typically create tools. SACM will define standards to enable assessment of endpoint posture. Those standards might prove helpful, if somebody chooses to create an automated tool for security assessment. 2) The use cases described here seem to be the same as for enterprises. I would expect that a use cases for telecomm would focus more on use cases that are different than for enterprises, and the document could explain how and why the needs are different. Hope this helps, David Harrington ietfdbh@comcast.net +1-603-828-1401 From nobody Sun Feb 23 04:57:07 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802711A00DE for ; Sun, 23 Feb 2014 04:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd_WUWOs0H1e for ; Sun, 23 Feb 2014 04:57:04 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id F36751A00CD for ; Sun, 23 Feb 2014 04:57:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAGLvCVOHCzIm/2dsb2JhbABZgkIjITtXwF2BBhZ0gicBAQMSG14BDAkVViYBBBsah2MBDJc/hFKrTBMEjhAjg1yBFASfJINwh0eDLYIq X-IronPort-AV: E=Sophos; i="4.97,529,1389762000"; d="scan'208,217"; a="50684834" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Feb 2014 07:57:03 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Feb 2014 07:43:58 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Sun, 23 Feb 2014 13:57:01 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: important information for the sacm meeting in London Thread-Index: Ac8wlr4le/EihBa7QdSCi0C8HpGCqA== Date: Sun, 23 Feb 2014 12:57:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E433721@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E433721AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/823dD3W7vzCtx3O3FjvdwClQDtQ Subject: [sacm] important information for the sacm meeting in London X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 12:57:05 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E433721AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda for the SACM meeting in London is available at https= ://datatracker.ietf.org/meeting/89/agenda/sacm/. Submission deadline for th= e final agenda is tomorrow Monday 2/14 - so please let us know if there are= any changes or additions. We need two note takers for the minutes. Early volunteering would be highly= appreciated. Thanks and Regards, Adam and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E433721AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda for the SACM meeting in Londo= n is available at https://datatracker.ietf.org/meeting/89/agenda/sacm/. Sub= mission deadline for the final agenda is tomorrow Monday 2/14 – so pl= ease let us know if there are any changes or additions.

 

We need two note takers for the minutes. Early volun= teering would be highly appreciated.

 

Thanks and Regards,

 

Adam and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E433721AZFFEXMB04globa_--