Re: [sacm] SACM Architecture Draft

Jarrett Lu <> Fri, 15 February 2019 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B10F3130E79 for <>; Thu, 14 Feb 2019 17:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 V0rE2L3BlrGF for <>; Thu, 14 Feb 2019 17:28:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A16F5130DFA for <>; Thu, 14 Feb 2019 17:28:25 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id x1F1NvGu120176 for <>; Fri, 15 Feb 2019 01:28:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2018-07-02; bh=QpnIbI3N1rOdn0i/k98Y9/I8AdP0rjHjZAw1fzpUKAk=; b=2GolKbU14qxEW6us3hnERQVeZhX9jX28pT15RF5nf6m7iNLPKShC2C/QQbDB6BMTnBfS lzK6MtKS1Ls1NygeIabaDIqPFZmD6g6pozQmedLn9FTtB553UNnmrtIn5hS0A1Q/816g g1BPY3EUPRZPmst9Zn2phbaqleWaaxfJGNe9U5eDIGj2WwExNSLxYqwtm2fm9PXrmBrg N9C/32nyXC68djLH+0qyNrWJt8SCMc3WBgbGDN5k0BRc7jtz83luiPQ7Re5wU4kyqllQ /P+oXfUk6xioJaQx0XwJs4Gi+9QZi8Gr25ttMdtgvNoYr1mw+r/7v0KtwUOmuq4Ka9kq 7w==
Received: from ( []) by with ESMTP id 2qhreeb79u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Fri, 15 Feb 2019 01:28:24 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x1F1SNK0005424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Fri, 15 Feb 2019 01:28:24 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x1F1SNMM026747 for <>; Fri, 15 Feb 2019 01:28:23 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Feb 2019 01:28:23 +0000
References: <>
From: Jarrett Lu <>
Message-ID: <>
Date: Thu, 14 Feb 2019 17:27:27 -0800
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------07383B26E5918208C46BF345"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9167 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902150008
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 01:28:28 -0000

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?


- 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:
>  1. Request review
>  2. Indicate whether we (the authors) believe it's on the right track
>  3. 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
>       o IT Asset Management could probably stand to be fleshed out
>       o Vulnerability Management is reasonable documented in this
>         draft, but may need work
>       o 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
>       o Privacy Considerations
>       o Security Considerations
>   * Flesh out our IANA Considerations
>       o 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