Re: [sacm] SACM Architecture Draft

Adam Montville <> Fri, 15 February 2019 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42B7B124408 for <>; Fri, 15 Feb 2019 04:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ywJBHBqrCgzi for <>; Fri, 15 Feb 2019 04:05:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72945130E73 for <>; Fri, 15 Feb 2019 04:05:13 -0800 (PST)
Received: by with SMTP id i20so16160652otl.0 for <>; Fri, 15 Feb 2019 04:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=S14DlOl6y16wzW1g341iCKrC21PA4h3lYkZ2JcEjQqo=; b=HhYQOuZEyIhqwaRiLQON+KFYPs4bDVzXeOPWRFkVDapHNDKfk/pA4/022qCpNtdIyK +1F9cxBu8zA1ZZmlkNfNU2FHXdvHOMc2C10zSd+frWtBiycpfuEwpS2qSqZw3WQiLuEx iKiy4R4AwbO+KvM6A7F8Re/3V1IlTrxouaPj+zhyvedY8mbCx9EEMWAVFvVkTl5eW74K c+QMKP80o3qCk6sx9SDKfB/LT62iE1ckPTFrrZ2Me87uEICP50IMidbFZWJXI7jxAPFn yuVDF1tvXmIt7rOMUEaKZo1s04KPKB/Y9MdIW9I3XDbdEK7fvFnsuKnc2i50cOsREh2L CbHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=S14DlOl6y16wzW1g341iCKrC21PA4h3lYkZ2JcEjQqo=; b=B6VAamLhvQtxe63c5KUkuwx15WST5vofG1Rd6qoSkX4pQF86ujc/IXwVin+tL/7oAX ypW3ADGrRUqN2DccbJf5b/nMHohrsETTsLnH8MxFBIEzbOVhJNYQsLm2uxrwinUzsm9g kNxpzOrMWw1bqQDQqq9BPGfznGxywSAJs+LEF/Wxb1mCsz33OBjCIMI5Wc0al8cI5QHo QXsXRDL/+it54Vu4IwI7+ossacUtAV+gQGUAvPDiVrOfJXcgedqiNbvWGx9mP+7KmJG9 4d0T2fRXW3l+FPMjBBGPrcB+Bz4K+O2yn6IXNZs1JpKiIwWBdY4ArQPOiraqjscA7Tsi lpow==
X-Gm-Message-State: AHQUAuankTZSIFXgRmjYMSf0b8ewHIQKcOx4fW+YTlM21M0bhKvHOY6p QPQjku/SQw0SkXkr8vO+CuA=
X-Google-Smtp-Source: AHgI3IZO8uAPPShdXKAVNQ1rT1FAGFgR/IIVWZvqo7PzEv0aCs9SaGbwGgM0T+xyYmezNZZpQt5o7Q==
X-Received: by 2002:a9d:6546:: with SMTP id q6mr5806677otl.288.1550232312240; Fri, 15 Feb 2019 04:05:12 -0800 (PST)
Received: from imac-2043-amontville.lan ( []) by with ESMTPSA id t77sm94492oie.26.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 04:05:11 -0800 (PST)
From: Adam Montville <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D9D67E3-F4D2-41F6-84DB-F44087F797D9"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 15 Feb 2019 06:05:10 -0600
In-Reply-To: <>
To: Jarrett Lu <>
References: <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [sacm] SACM Architecture Draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Feb 2019 12:05:16 -0000

Hi Jarret, 

Thank you for reading through the draft. Happy to talk about some of these things today during the interim. I think we would prefer that interfaces/capabilities are first described abstractly — irrespective of any specific messaging solution — and then use XMPP-Grid+ as an implementation example.

Kind regards,


> On Feb 14, 2019, at 7:27 PM, Jarrett Lu <>; wrote:
> Hi Adam & SACM,
> I read the (active) architecture draft, and I believe it's a good one. The hackathon work reflected in the draft definitely carries some weight. 
> Some architecture entities could be expanded and described at a more abstract level. For example, this draft appears to equate "capabilities" with set of interfaces. Are SACM capabilities supposed to be discoverable? If so, how should it be represented? If capabilities/functional interfaces are described in more general terms, and use XMPP-grid+ as an example of how it meets the functional requirements, this may make it appear less solution-centric. 
> I vote for including workflows in the architecture document. It just reads better that way. It will increase the document size and takes longer to finish. As long as good progress is being made, is it really urgent to finish and publisher the architecture document.
> I think the Security Consideration section of the old architecture draft is pretty good. Do XMPP-grid XEPs adress the MitM, transport integrity and confidentiality concerns mentioned there?
> Regards.
> - Jarrett
> On 12/27/18 01:29 PM, Adam Montville wrote:
>> Dear SACM,
>> Happy (belated) Holidays and a Happy New Year to you!
>> At our recent virtual interim meeting I promised to post a note to the list regarding our architecture draft to do three things:
>> Request review
>> Indicate whether we (the authors) believe it's on the right track
>> Assuming 2 is good, a list of what's left to be done.
>> So, we're going to start with 2, move on to 3, and then end with 1...
>> Bill and I both believe that the architecture draft is, indeed, on the right track. Henk, and possibly others (Nancy?), have described this draft as being too solutions-specific. Section 3, "Architectural Overview" is intended to be the place in this draft to describe the abstract ideas in the architecture. Section 3.1 talks a little bit about the roles of the SACM Components, and Section 3.2 provides the known information about an XMPP-based instantiation of the architecture (note Appendix A maps this instantiation back to our SACM requirements, RFC8248). 
>> Assuming that we are on the right track, then here's what we think yet needs to be done:
>> Document specific Components, Capabilities, Interfaces, and Workflows
>> IT Asset Management could probably stand to be fleshed out
>> Vulnerability Management is reasonable documented in this draft, but may need work
>> Configuration management probably needs to be fleshed out as well (needs to be tied to SACM Use Cases)
>> Determine where to document the above (in this draft or in new drafts), which will determine how long this draft takes to complete.
>> Prague hackathon to continue the trend of discovering an XMPP-based solution
>> TODOs in the draft
>> Privacy Considerations
>> Security Considerations
>> Flesh out our IANA Considerations
>> Will likely result in additional draft work
>> Clearly, there's a lot to be done here, and we really need your specific, actionable feedback on this draft. Feel free to reach out here or to either of us directly.
>> This draft in GitHub: <> 
>> This draft on the SACM documents page: <>
>> Kind regards,
>> Adam & Bill
>> _______________________________________________
>> sacm mailing list
>> <>
>> <>
> _______________________________________________
> sacm mailing list