Re: [sacm] ECP Architecture Diagram Feedback

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 10 April 2018 11:24 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E670126D05 for <sacm@ietfa.amsl.com>; Tue, 10 Apr 2018 04:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bsjgUcSrytMc for <sacm@ietfa.amsl.com>; Tue, 10 Apr 2018 04:24:19 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C34126CF6 for <sacm@ietf.org>; Tue, 10 Apr 2018 04:24:18 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w3ABOE13022278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <sacm@ietf.org>; Tue, 10 Apr 2018 13:24:15 +0200
Received: from [134.102.166.246] (134.102.166.246) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.389.1; Tue, 10 Apr 2018 13:24:09 +0200
To: sacm@ietf.org
References: <DM5PR0901MB2197070C2CF8BA9A4283251CA5A60@DM5PR0901MB2197.namprd09.prod.outlook.com> <D0D3E5A5-2D22-4B3A-AD3E-27386CC43887@gmail.com> <DM5PR0901MB2197CA6B3C285DD17A0D1C04A5A50@DM5PR0901MB2197.namprd09.prod.outlook.com> <CAOxmg6tbzQBpqubuxn5DPFe1mcB7gjhX3hr5g8A4hMoexyki-A@mail.gmail.com> <DM5PR0901MB21977263C87CA80E2D277750A5A40@DM5PR0901MB2197.namprd09.prod.outlook.com> <CAOxmg6s1GMnbZO2pzR2baNJ_MCPwqacdcjm+8yA5Tjkh0-+fNQ@mail.gmail.com> <DM5PR0901MB21971D0D935BD3A6BB1E7A42A5BF0@DM5PR0901MB2197.namprd09.prod.outlook.com> <CAOxmg6tsRNVdbDQbm0qmcY=6_WqE4vXtJeHM0oxok5BzAntvEA@mail.gmail.com> <4aba97cd-f2fd-2c0f-8b2d-53379a5c74c6@sit.fraunhofer.de> <CAOxmg6vLPvFRtZBCzb_79ezJz2iX2EE1upQtNafMGsANRQpd7w@mail.gmail.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <46e44aad-7112-94a8-0b98-905a606ec38e@sit.fraunhofer.de>
Date: Tue, 10 Apr 2018 13:23:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAOxmg6vLPvFRtZBCzb_79ezJz2iX2EE1upQtNafMGsANRQpd7w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.166.246]
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/52EILILYDgf8jEwENpIE2YT8rUw>
Subject: Re: [sacm] ECP Architecture Diagram Feedback
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2018 11:24:24 -0000

Hello Sherif,

I assume that only the "gray" upper part of your diagram is a flow chart 
and the blocks in the lower part compose a workflow of data on the data 
plane between components? Is that correct?

If so, the workflow illustrated can be mapped to the current (and in 
this case also the original/generic) SACM architecture. The dedicated 
data flows depicted (again, assuming that the black arrows in the lower 
part of the diagram are somehow data flows - although the direction of 
arrows seems to contradict that assumption at some points) between green 
boxes would be mapped to an n-2-m message distribution system (e.g. a 
message broker, message bus, multi-client pub/sub) using the common SACM 
data and interaction model.

Arrows from boxes "not green", e.g. "pink" and "orange" boxes, would be 
covered by SACM components with the collector (or reporter) role, using 
existing open or proprietary transfer methods (or also the common SACM 
data and interaction model, if applicable).

Orange arrows would either be brokered peer-2-peer data flows that do 
not use the common SACM data and interaction model, or the external 
("not green") components would have to be enrolled with appropriate 
imperative guidance via methods that are out of scope (e.g. manually) to 
communicate with green boxes (SACM components) via orange arrows (not 
the common SACM data and interaction model).

In most scenarios (approx. everything larger than the S in SME, for 
example), would probably use more than one "Repo", I assume.


Some exemplary mapping:

"We know the assets I need to account for." -> TE Repo
"We are performing the necessary security assessments." -> Evaluator 
requiring a specific Imperative Guidance Repo (OVAL and the 
Vulnerability Assessment Scenario evolving from it might provide a more 
specific repo component name already)
"We are scouring the findings based on risk." -> Another Evaluator 
requiring another specific Imperative Guidance Repo.
"We are reporting the issues..." -> this would be a specific SACM Report 
component, or a TE Characterization Repo

Remediation is not a target of our current phase.

About the things we might need:

"A data model that can map a finding/vulnerability to a fix 
(patch/config change etc..)." -> I think we are working to provide the 
basis for exactly that (amongst other goals)

"An automated process for detection" -> which would be the evaluation 
task (or a conditional concatenation of multiple, staged evaluation tasks)

"An automated process for fixing issues" -> which will be a future goal 
in a future phase (please correct me, if I am telling fairy tales here)

"An orchestration system to provide tech teams with the ability to 
automatically detect and fix when and where it makes sense." -> the 
composite that is a SACM Domain per se provides a distributed 
orchestration capability by itself. As per comment above, at some point 
a dedicated orchestrator is probably required to make best use of 
resources and avoid bottlenecks in the data flow between components (or 
detect attacks that try to "play the system itself").



Viele Grüße,

Henk








On 04/10/2018 01:11 AM, Sherif Mansour wrote:
> Thanks Henk,
> 
> The image below should help explain where I am going with this (I hope). 
> The green blocks are what I think are covered by SACM, the over all 
> eco-system has a few more players that I have colored differently. Its 
> easier to walkthrough via the phone.
> 
> However I think this can be simplified by the follwing story:
> 
> As a technology team, we want to be able to detect all security findings 
> on our endpoints/enviroment and rate each finding based on the risk so 
> that we can remediate the fidnings in a prioritiesed and timely fashion 
> before they are exploited by an adversary.
> 
> This in turn means:
> 
>   * We know the assets I need to account for. Hence the Reference Data
>   * We are performing the neccsary security assesments. Hence the
>     Security tools
>   * We are socuring the findings based on risk. Hence Repo (missed the
>     evaluator in the diagram apologies).
>   * We are reporting the issues to the right people at the right time.
>     Hence the reporting system & bug tracker integration (some tech
>     teams would want the data into their reporting systems to action).
>   * We have a recommandations/guidance on how to fix those issues.
> 
> If we think of the ideal future state, we would not want to slow tech 
> team members down. We would want to get to the minimum ammount of time 
> between discovering an issue and remediating it hence self healing.
> 
> We would need a few things:
> 
>   * A data model that can map a finding/vulnerability to a fix
>     (patch/config change etc..).
>   * An automated process for detection
>   * An automated process for fixing issues
>   * An orchstration sytem to provide tech teams with the ability to
>     automaticically detect and fix when and where it makes sense.
> 
> Hope this helps
> 
> 
> 
> -Sherif
> 
> 
> On Mon, Apr 9, 2018 at 5:19 PM, Henk Birkholz 
> <henk.birkholz@sit.fraunhofer.de 
> <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
> 
>     Hi all,
> 
>     well, it is both. You don not necessarily need an orchestrator, if
>     every SACM component can discover and provide IE by itself and each
>     SACM component is enrolled with or can always discover its intended
>     imperative guidance. At a given scale this can become very confusing
>     and bottlenecks can arise. Hence, using (again scalable mesh) of
>     orchestrators seems a good approach :)
> 
>     If an external entity (I think this is Jenkins in the example below,
>     a user outside the SACM domain) wants to trigger a workflow of
>     tasks, we need an "external" interface. In fact, this can be the
>     same type of interface that is used between SACM components, but it
>     must not necessarily. In fact, there might be good reasons fot it
>     not to be the same kind of protocol/API/interaction model, but
>     again, it may most certainly be the same.
> 
>     An Orchestrator, as a minimum, takes on the control plane function
>     of instantiating SACM tasks on specific SACM components - on behalf
>     of triggers (or actually, events) that are created by a SACM
>     component or an external entity. The frequency of sets of actions
>     (instantiated tasks) in SACM ranges from ad-hoc, to conditional,
>     scheduled, and continuously.
> 
>     Viele Grüße,
> 
>     Henk
> 
>     On 04/09/2018 05:05 PM, Sherif Mansour wrote:
> 
>         Hi Dan,
>         Let me respond later this evening, I am also happy to call if
>         you have a minute.
> 
>         On Mon, 9 Apr 2018 at 3:48 pm, Haynes Jr., Dan
>         <dhaynes@mitre.org <mailto:dhaynes@mitre.org>
>         <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>> wrote:
> 
>              Thanks for the clarification Sherif!____
> 
>              __ __
> 
>              So, it sounds like beyond just a pub/sub interface for
>         communicating
>              with other components, you want it to also be able to
>         manage jobs
>              among other things. Does the list of current SACM tasks
>         (collection,
>              endpoint characterization, endpoint classification, evaluation)
>              sound like the jobs you would want it to manage? The SACM
>         tasks are
>              defined here
>             
>         (https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____
>         <https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____>
> 
>              __ __
> 
>              Are there other capabilities that you would specifically
>         like to see
>              in the orchestrator?____
> 
>              __ __
> 
>              Also, how do others envision the orchestrator working?____
> 
>              __ __
> 
>              Thanks,
> 
>              Danny____
> 
>              __ __
> 
>              *From:* Sherif Mansour [mailto:cherifmansour@gmail.com
>         <mailto:cherifmansour@gmail.com>
>              <mailto:cherifmansour@gmail.com
>         <mailto:cherifmansour@gmail.com>>]
> 
>              *Sent:* Saturday, April 07, 2018 6:18 AM
> 
> 
>              *To:* Haynes Jr., Dan <dhaynes@mitre.org
>         <mailto:dhaynes@mitre.org> <mailto:dhaynes@mitre.org
>         <mailto:dhaynes@mitre.org>>>
>              *Cc:* Montville, Adam W <adam.w.montville@gmail.com
>         <mailto:adam.w.montville@gmail.com>
>              <mailto:adam.w.montville@gmail.com
>         <mailto:adam.w.montville@gmail.com>>>; sacm@ietf.org
>         <mailto:sacm@ietf.org>
>              <mailto:sacm@ietf.org <mailto:sacm@ietf.org>>
>              *Subject:* Re: [sacm] ECP Architecture Diagram Feedback____
> 
>              __ __
> 
>              In a devops model, you generally want to move from “the
>         team that
>              does stuff for other people” to “the team that builds
>         capabilities
>              for others”.____
> 
>              __ __
> 
>              In that case, stage-1 might look a little different. You
>         would start
>              with the Orchastrator. So there would be a Jenkins job the
>         fires,
>              hits the orchestrator, asks it to check a few end points,
>         reads the
>              results than makes an informed decision. There are several
>         use cases
>              for self service testing the main one right is to make sure end
>              points have been hardened and there sre currently no known show
>              stopers before the assets “hits the factory floor”. ____
> 
>              __ __
> 
>              Ideally we want to get to a stage of self healing. ____
> 
>              __ __
> 
>              Where a dev/sysadmin/other would ping the orchestrator to
>         check an
>              asset(s) identify issues, if those issues are mapped to
>         specific
>              “fixes” then the customer is also given the option to
>         automagically
>              schedule a patch/fix.____
> 
>              __ __
> 
>              All this means that the interface between the orchestrator and
>              external parties needs to be thought out. The main value of the
>              orchestrator is vendor independent management and self service
>              automation.____
> 
>              __ __
> 
>              On Wed, 4 Apr 2018 at 9:12 pm, Haynes Jr., Dan
>         <dhaynes@mitre.org <mailto:dhaynes@mitre.org>
>              <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>>
>         wrote:____
> 
>                  Hi Sherif,____
> 
>                  ____
> 
>                  I think as long as we have standardized interfaces whether
>                  directly (posture manager <-> repository, evaluator <–>
>                  repository) or indirectly through the orchestrator, we
>         should be
>                  able to swap posture managers in and out. One concern
>         is that I
>                  am not sure we want to require an orchestrator in order
>         to store
>                  information in the repository as the repository may be
>                  co-located with the posture manager or the orchestrator
>         may be
>                  unnecessary for smaller or more limited networks. By
>         keeping the
>                  components as-is with both direct and indirect
>         interfaces, the
>                  architecture of the solution can be arranged in a
>         manner that
>                  best supports the needs of the organization.  One
>         approach that
>                  might help is if we break out the diagram into
>         different stages.____
> 
>                  ____
> 
>                  Stage 1 – Reporting endpoint information to the
>         repository via
>                  the server. Note: the repository may be co-located with
>         posture
>                  manager on the server.____
> 
>                  ____
> 
>                                   Posture Manager          Endpoint____
> 
>                                   +---------------+       
>         +---------------+____
> 
>                                   |               |       
>         |               |____
> 
>                                   | +-----------+ |        |
>         +-----------+ |____
> 
>                                   | | Posture   | |        | | Posture  
>         | |____
> 
>                                   | | Validator | |        | | Collector
>         | |____
> 
>                                   | +-----------+ |        |
>         +-----------+ |____
> 
>                                   |      |        |        |     
>         |        |____
> 
>                                   |      |        |        |     
>         |        |____
> 
>                  Repository      |      |        |        |     
>         |        |____
> 
>                  +--------+      | +-----------+ |<-------|
>         +-----------+ |____
> 
>                  |        |      | | Posture   | | report | | Posture  
>         | |____
> 
>                  |        |      | | Collection| |        | |
>         Collection| |____
> 
>                  |        |<-----| | Manager   | |        | | Engine   
>         | |____
> 
>                  |        | store| +-----------+ |        |
>         +-----------+ |____
> 
>                  |        |      |               |       
>         |               |____
> 
>                  |        |      |               |       
>         |               |____
> 
>                  +--------+      +---------------+       
>         +---------------+____
> 
>                  ____
> 
>                  Stage 2 -  Evaluator queries information from the
>         repository. If
>                  needed, the evaluator queries the endpoint for
>         information via
>                  the posture manager.____
> 
>                    ____
> 
>             Posture Manager          Endpoint____
> 
>             +---------------+        +---------------+____
> 
>                                                   |              
>         |        |               |____
> 
>             | +-----------+ |        | +-----------+ |____
> 
>             | | Posture   | |        | | Posture   | |____
> 
>             | | Validator | |        | | Collector | |____
> 
>             | +-----------+ |        | +-----------+ |____
> 
>             |      |        |        |      |        |____
> 
>             |      |        |        |      |        |____
> 
>                  Evaluator       Repository      |      |       
>         |        |      |        |____
> 
>                  +------+        +--------+      | +-----------+
>         |<-------| +-----------+ |____
> 
>                  |      |        |        |      | | Posture   | |
>         report | | Posture   | |____
> 
>                  |      |        |        |      | | Collection|
>         |        | | Collection| |____
> 
>                  |      |<-----> |        |<-----| | Manager   | |
>         query  | | Engine    | |____
> 
>                  |      |request/|        | store| +-----------+
>         |------->| +-----------+ |____
> 
>                  |      |respond |        |      |
>                        |        |               |____
> 
>                  |      |        |        |      |              
>         |        |               |____
> 
>                  +------+        +--------+     
>         +---------------+        +---------------+____
> 
>                  ____
> 
>                  Stage 3 – Evaluator, repository, and posture manager
>         sharing
>                  information via the orchestrator.____
> 
>                  ____
> 
>                                   Orchestrator____
> 
>                  +-----------------------------------------------+____
> 
>                  |           |____
> 
>                  |                   |____
> 
>                  +-----------------------------------------------+____
> 
>                      ^                ^                   ^____
> 
>                      |pub/sub         |pub/sub            |pub/sub____
> 
>                      |                |                   |____
> 
>                      |                |                   |____
> 
>                      |                |                   v____
> 
>                      |                |             Posture
>         Manager          Endpoint____
> 
>                      |                |          
>         +---------------+        +---------------+____
> 
>                      |                |           |              
>         |        |               |____
> 
>                      |                |           | +-----------+
>         |        | +-----------+ |____
> 
>                      |                |           | | Posture   |
>         |        | | Posture   | |____
> 
>                      |                |           | | Validator |
>         |        | | Collector | |____
> 
>                      |                |           | +-----------+
>         |        | +-----------+ |____
> 
>                      |                |           |      |       
>         |        |      |        |____
> 
>                      v                v           |      |       
>         |        |      |        |____
> 
>                  Evaluator       Repository      |      |       
>         |        |      |        |____
> 
>                  +------+        +--------+      | +-----------+
>         |<-------| +-----------+ |____
> 
>                  |      |        |        |      | | Posture   | |
>         report | | Posture   | |____
> 
>                  |      |        |        |      | | Collection|
>         |        | | Collection| |____
> 
>                  |      |        |        |      | | Manager   | |
>         query  | | Engine    | |____
> 
>                  |      |        |        |      | +-----------+
>         |------->| +-----------+ |____
> 
>                  |      |        |        |      |              
>         |        |               |____
> 
>                  |      |        |        |      |              
>         |        |               |____
> 
>                  +------+        +--------+     
>         +---------------+        +---------------+____
> 
>                  ____
> 
>                  Regarding the invisible box of reference data, yes, the
>                  repository would support it. I don’t believe there is
>         anything
>                  in the draft that prevents that type of data form being
>         stored. ____
> 
>                  ____
> 
>                  Also, I agree that there should be an interface between the
>                  out-of-scope reporting system and the repository. This will
>                  eventually be supported by the interface that we create for
>                  accessing the repository.____
> 
>                  ____
> 
>                  Lastly, can you provide more information on how you see
>         this
>                  integrating into the DevOps model?____
> 
>                  ____
> 
>                  Thanks,
> 
>                  Danny____
> 
>                  ____
> 
>                  *From:* Sherif Mansour [mailto:cherifmansour@gmail.com
>         <mailto:cherifmansour@gmail.com>
>                  <mailto:cherifmansour@gmail.com
>         <mailto:cherifmansour@gmail.com>>]
>                  *Sent:* Tuesday, April 03, 2018 5:36 PM____
> 
> 
>                  *To:* Haynes Jr., Dan <dhaynes@mitre.org
>         <mailto:dhaynes@mitre.org>
>                  <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>>____
> 
>                  *Cc:* Montville, Adam W <adam.w.montville@gmail.com
>         <mailto:adam.w.montville@gmail.com>
>                  <mailto:adam.w.montville@gmail.com
>         <mailto:adam.w.montville@gmail.com>>>; sacm@ietf.org
>         <mailto:sacm@ietf.org>
>                  <mailto:sacm@ietf.org <mailto:sacm@ietf.org>>____
> 
> 
>                  *Subject:* Re: [sacm] ECP Architecture Diagram Feedback____
> 
>                  ____
> 
>                  Hi Danny,____
> 
>                  I would recommend that the Orchestrator sits between
>         the posture
>                  manager and repository. This is for a few reasons, some
>         tactical
>                  and some strategic:____
> 
>                    * Strategically (Long term), it allows you to switch
>         between
>                      posture managers without having to do much (if any)
>         changes
>                      on the repository, in their all it means is it will be
>                      pulling data through the orchatrator, it just
>         happens to be
>                      from a different tool.____
>                    * Tactically (short term), is is because these
>         connections
>                      currently do not exist, so if you have many posture
>         managers
>                      you need to develop different integration in
>         several areas
>                      (one connection for the orchestrator & repository). By
>                      leveraging the orchastrator, you only need to
>         create a singe
>                      integration with the posture manager, it simply
>         just needs
>                      more features (i.e. the ability to pull security
>         end point
>                      findings, both in raw vendor specific data or in a
>         uniform
>                      agreed data model).____
> 
>                  The second point is that there are a few "invisible"
>         boxes. The
>                  first is reference data, a lot of the repository data
>         would be
>                  enriched with information that is specific to the
>         organization
>                  such as the team which owns specific assets or the
>         context to
>                  which they are used. Now, on thing that is out of scope
>         is the
>                  reporting, I am aware this is out of scope, but an
>         organisation
>                  has not moved the needle in terms of security if they have
>                  detected security issues but not resolved them. It is
>         therefore
>                  natural that there is an interface somewhere between the
>                  repository and a reporting system. __ __
> 
>                  Finally one key benefit of the orchestrator is
>         automation and
>                  self service, there for an interface to allow it to
>         work in a
>                  devops model would also increase its value, if the
>         interface can
>                  (easily) integrate with Jenkins/Bamboo, or chef recipes /
>                  Ansible playbooks, this would go a long way for
>         adoption.____
> 
>                  -Sherif____
> 
>                  ____
> 
>                  ____
> 
>                  ____
> 
>                  ____
> 
>                  On Tue, Apr 3, 2018 at 7:36 PM, Haynes Jr., Dan
>                  <dhaynes@mitre.org <mailto:dhaynes@mitre.org>
>         <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>> wrote:____
> 
>                      Hi Adam,____
> 
>                      ____
> 
>                      I hope it was a good trip out there and that you
>         were able
>                      to see some of the sights!____
> 
>                      ____
> 
>                      As far as scoping and the diagram, I think it’s worth
>                      nothing that all the components in it are in scope
>         for ECP.
>                      It is just a matter of when we actually get to creating
>                      drafts for them (if that makes any sense). I think
>         what you
>                      are looking for is a diagram that shows what we are
>                      currently working on? Or, maybe I am
>         misunderstanding your
>                      comments?____
> 
>                      ____
> 
>                      Thanks,
> 
>                      Danny ____
> 
>                      ____
> 
>                      *From:* Adam Montville
>         [mailto:adam.w.montville@gmail.com
>         <mailto:adam.w.montville@gmail.com>
>                      <mailto:adam.w.montville@gmail.com
>         <mailto:adam.w.montville@gmail.com>>]
>                      *Sent:* Monday, April 02, 2018 3:33 PM
>                      *To:* Haynes Jr., Dan <dhaynes@mitre.org
>         <mailto:dhaynes@mitre.org>
>                      <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>>
>                      *Cc:* sacm@ietf.org <mailto:sacm@ietf.org>
>         <mailto:sacm@ietf.org <mailto:sacm@ietf.org>>
>                      *Subject:* Re: [sacm] ECP Architecture Diagram
>         Feedback____
> 
>                      ____
> 
>                      Hi Danny,____
> 
>                      ____
> 
>                      We missed you in London. I think the diagram is ok,
>         but I do
>                      have scoping questions (just sent to the list)
>         which may
>                      suggest some modification to the diagram once
>         resolved. If
>                      the way I'm interpreting the ECP draft at this point is
>                      close to accurate, then it might be a good idea to
>         add a
>                      horizontal scoping line between the left hand and
>         the right
>                      hand of the diagram, where the posture manager is
>         the first
>                      component on the right-hand side. Alternatively, an
>         in-scope
>                      boundary box could be drawn around the appropriate
>                      components.____
> 
>                      ____
> 
>                      What really matters is whether the diagram accurately
>                      depicts the intended scope of the draft from the
>         authors'
>                      perspectives, and whether a typical reader would
>         see it that
>                      way.____
> 
>                      ____
> 
>                      Adam____
> 
>                      ____
> 
>                          On Apr 2, 2018, at 1:32 PM, Haynes Jr., Dan
>                          <dhaynes@mitre.org <mailto:dhaynes@mitre.org>
>         <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>> wrote:____
> 
>                          ____
> 
>                          Hi Everyone,
> 
>                          At IETF 101, we presented an updated architecture
>                          diagram [1] that was based on feedback from the
>                          September virtual interim [2][3] and was
>         included in the
>                          ECP -01 draft [4]. During the meeting, we did not
>                          receive any feedback on the architecture
>         diagram.____
> 
>                          ____
> 
>                          As a result, we just wanted to follow-up on the
>         list and
>                          see if there was any feedback or objections to the
>                          updated ECP architecture diagram that was
>         proposed.____
> 
>                          ____
> 
>                          Thanks,
> 
>                          Danny____
> 
>                          ____
> 
>                          ____
> 
>                         
>         [1]https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see
>         <https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see>
>                          slide 4)____
> 
>                         
>         [2]https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see
>         <https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see>
>                          slide 5)____
> 
>                         
>         [3]https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see
>         <https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see>
>                          page 1 and 2)____
> 
>                         
>         [4]https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____
>         <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____>
> 
>                          ____
> 
>                          _______________________________________________
>                          sacm mailing list
>         sacm@ietf.org <mailto:sacm@ietf.org> <mailto:sacm@ietf.org
>         <mailto:sacm@ietf.org>>
>         https://www.ietf.org/mailman/listinfo/sacm____
>         <https://www.ietf.org/mailman/listinfo/sacm____>
> 
>                      ____
> 
> 
>                      _______________________________________________
>                      sacm mailing list
>         sacm@ietf.org <mailto:sacm@ietf.org> <mailto:sacm@ietf.org
>         <mailto:sacm@ietf.org>>
>         https://www.ietf.org/mailman/listinfo/sacm____
>         <https://www.ietf.org/mailman/listinfo/sacm____>
> 
>                  ____
> 
> 
> 
>         _______________________________________________
>         sacm mailing list
>         sacm@ietf.org <mailto:sacm@ietf.org>
>         https://www.ietf.org/mailman/listinfo/sacm
>         <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
>     _______________________________________________
>     sacm mailing list
>     sacm@ietf.org <mailto:sacm@ietf.org>
>     https://www.ietf.org/mailman/listinfo/sacm
>     <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> 
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>