Subject: Re: [sacm] Draft updated charter for SACM

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 19 Sep 2017 18:07:27 +0000

Please see my comments below:

On 9/18/17, 11:08 AM, "sacm on behalf of Banghart, Stephen A. (Fed)" <[email-masked] on behalf of [email-masked]> wrote:

    All,
    
    After discussion with a few other SACM document authors this version of the new charter proposal was put together. The changes throughout are minimal; the primary change is several additions to the work items section that covers other work currently being done in the WG.
    
    Does anyone have any thoughts/comments/concerns on this proposed draft update? 
    
    Thanks,
    Stephen Banghart
    
    ------------------------------------------------------------------------------------------
    
    SACM Charter Proposal
    2017-09-12
    
    Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols and models aiding collection and evaluation of endpoint attributes enable automation, thus freeing practitioners to focus on high priority tasks .  
    
    At its core, posture assessment  consists of five basic steps, which the working group desires to fulfill  in an innovative, automated manner capable of avoiding ad hoc or scheduled assessments:
    
    1. Describe target endpoints
    2. Determine specific endpoint elements  to assess 
    3. Collect and make available specified elements' actual values 
    4. Compare actual element values to expected element values 
    5. Make results available
    
    This working group will focus on collection, evaluation, and orchestration and communication, as described herein. 
    
    A. Collection. The WG will define a standardized way to provide two types of imperative guidance to collectors over varying collection mechanisms: 
    
    1) Which target endpoints to collect from, and
    2) What to collect from these target endpoints. 
    
    When classified , a set of instructions (such as vulnerability description data, YANG filter expressions, Windows Management Instrumentation classes, etc.) can be brokered to the appropriate collectors using the control plane functions  defined by "C. Orchestration and Communication" (below). Detecting and classifying desired attributes beforehand may require orchestrating functions that go beyond the set of capabilities a collector can provide, and will inform the requirements and characteristics for "C. Orchestration and Communication". The working group recognizes that manual configuration of targets and corresponding collection profiles will not scale and does not seem to be a viable option.
    
    B. Evaluation. The working group will standardize a criteria language enabling evaluation of actual endpoint posture information against desired endpoint posture information to produce a standardized result. This extensible language will support complex Boolean statements, comparison operators, logical flow statements, and functions for string manipulation. Additionally, the working group will seek to discover an approach that allows data from any posture collection mechanism to be generically evaluated.
    
    C. Orchestration and Communication. The working group will define a set of control plane functions to enable the discovery and orchestration between devices that can provide the requisite information  sought by posture collectors, posture evaluators, data repositories, and other SACM architectural components. 
    
    Due to the breadth of this work, the working group will address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing work. 
[NCW] I think we need to incorporate https://tools.ietf.org/html/draft-ietf-sacm-terminology as we need to have a well understood set of definitions beyond “endpoint” and “posture”
    
    Specific work items will include the following: 
    
    -  The WG will define a way to provide two types of imperative guidance to the correct SACM collectors: 1) Which target endpoints to collect from and 2) what to collect from these target endpoints. When classified, a set of instructions, such as vulnerability description data or YANG filter expressions, can be brokered to the appropriate collectors. Detecting and classifying beforehand might require orchestrating functions that go beyond the set of capabilities a SACM collector can provide. 
    
    -  The WG will describe a criteria language capable of being evaluated against endpoint posture information to produce a standardized result. The language will support complex Boolean statements, comparison operators, and functions for string manipulation; and will be extensible enough to be applicable to the full range of collected posture attributes. Additionally, this document will describe an approach that allows data from any posture collection mechanism to be evaluated.
    
    - The WG will define a control plane function to enable the discovery and orchestration between devices that can provide the requisite information sought by posture collectors, posture evaluators or both. As an example, a document that describes an instance of such a control plane and transfer protocol for data, is through the use of XMPP and extensions as needed to demonstrate XMPP’s applicability to SACM. 
    
    - A method of expressing software metadata is needed that is suitable for use by constrained devices. The WG will create a standards track document that defines a CBOR-based format that represents software metadata to include software identification, file hashes, and other descriptive information. This format will be derived from the ISO/IEC 19770-2 Software Identification (SWID) tag standard.
[NCW]  I am not sure why this is called out explicitly as software metadata could also be represented with the Yang model?  Perhaps the intent is to show this as one example for how it can be expressed?  That is, there are other representations that the IETF is looking at that could also be leveraged.
    
    - To support collection of posture information from traditional computing devices (e.g., servers, laptops, etc.), the WG will create standards track documents describing mechanisms for the collection and delivery of information about installed software on an endpoint by extending IETF NEA.

    - To provide for the integration of multiple standards to support posture information collection, the WG will define best practices  for the collection of posture information from endpoints and its delivery to a collector, from which it can be distributed using the SACM messaging standards. 
[NCW] This seems to
    
    -The WG will define standards track documents describing extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE) that provide IANA registrations and requirements to support the sharing of software, configuration information, and other forms of imperative guidance.
[NCW] Similar to my previous comment, about CBOR/SWID,  there can be other means for providing information exchange.  For example, using Yang model and leveraging NETCONFs work for the information exchange.
    
    Additionally, the working group will describe: 1) a SACM Architecture including protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system, and 2) a SACM Information Model.  

    > -----Original Message-----
    > From: sacm [mailto:[email-masked]] On Behalf Of Karen
    > O'Donoghue
    > Sent: Tuesday, September 12, 2017 12:48 PM
    > To: [email-masked]
    > Subject: [sacm] Draft updated charter for SACM
    > 
    > Folks,
    > 
    > Below is a draft update to our charter based on discussion at the last IETF and
    > some subsequent private discussions. Comments welcome. Please
    > remember that we plan to call out specific drafts using the milestone process
    > and not include them in the base charter.
    > 
    > Regards,
    > Karen
    > 
    > ***************
    > 
    > SACM Charter Proposal
    > 2017-09-12
    > 
    > Securing information and the systems that store, process, and transmit that
    > information is a challenging task for organizations of all sizes, and many
    > security practitioners spend much of their time on manual processes.
    > Standardized protocols and models aiding collection and evaluation of
    > endpoint attributes enable automation, thus freeing practitioners to focus on
    > high priority tasks.
    > 
    > At its core, posture assessment consists of five basic steps, which the
    > working group desires to fulfill in an innovative, automated manner capable
    > of avoiding ad hoc or scheduled assessments:
    > 
    > 1. Describe target endpoints
    > 2. Determine specific endpoint elements to assess 3. Collect and make
    > available specified elements' actual values 4. Compare actual element values
    > to expected element values 5. Make results available
    > 
    > This working group will focus on collection, evaluation, and orchestration and
    > communication, as described herein.
    > 
    > A. Collection. The WG will define a standardized way to provide two types of
    > imperative guidance to collectors over varying collection mechanisms:
    > 
    > 1) Which target endpoints to collect from, and
    > 2) What to collect from these target endpoints.
    > 
    > When classified, a set of instructions (such as vulnerability description data,
    > YANG filter expressions, Windows Management Instrumentation classes,
    > etc.) can be brokered to the appropriate collectors using the control plane
    > functions defined by "C. Orchestration and Communication" (below).
    > Detecting and classifying desired attributes beforehand may require
    > orchestrating functions that go beyond the set of capabilities a collector can
    > provide, and will inform the requirements and characteristics for "C.
    > Orchestration and Communication". The working group recognizes that
    > manual configuration of targets and corresponding collection profiles will not
    > scale and does not seem to be a viable option.
    > 
    > B. Evaluation. The working group will standardize a criteria language enabling
    > evaluation of actual endpoint posture information against desired endpoint
    > posture information to produce a standardized result. This extensible
    > language will support complex Boolean statements, comparison operators,
    > logical flow statements, and functions for string manipulation. Additionally,
    > the working group will seek to discover an approach that allows data from
    > any posture collection mechanism to be generically evaluated.
    > 
    > C. Orchestration and Communication. The working group will define a set of
    > control plane functions to enable the discovery and orchestration between
    > devices that can provide the requisite information sought by posture
    > collectors, posture evaluators, data repositories, and other SACM
    > architectural components.
    > 
    > Due to the breadth of this work, the working group will address enterprise
    > use cases pertaining to the assessment of endpoint posture (using the
    > definitions of Endpoint and Posture from RFC 5209). The working group will,
    > whenever reasonable and possible, reuse existing work.
    > 
    > Specific work items will include the following:
    > 
    > - Collection: The WG will define a way to provide two types of imperative
    > guidance to the correct SACM collectors: 1) Which target endpoints to collect
    > from and 2) what to collect from these target endpoints. When classified, a
    > set of instructions, such as vulnerability description data or YANG filter
    > expressions, can be brokered to the appropriate collectors. Detecting and
    > classifying beforehand might require orchestrating functions that go beyond
    > the set of capabilities a SACM collector can provide.
    > 
    > - Evaluation: The working group will describe a criteria language capable of
    > being evaluated against endpoint posture information to produce a
    > standardized result. The language will support complex Boolean statements,
    > comparison operators, and functions for string manipulation; and will be
    > extensible enough to be applicable to the full range of collected posture
    > attributes. Additionally, this document will describe an approach that allows
    > data from any posture collection mechanism to be evaluated.
    > 
    > - Messaging: The WG will define a control plane function to enable the
    > discovery and orchestration between devices that can provide the requisite
    > information sought by posture collectors, posture evaluators or both. As an
    > example, a document that describes an instance of such a control plane and
    > transfer protocol for data, is through the use of XMPP and extensions as
    > needed to demonstrate XMPP’s applicability to SACM.
    > 
    > Additionally, the working group will describe: 1) a SACM Architecture
    > including protocol requirements and their associated use cases as well as a
    > description of how SACM protocols fit together into a system, and 2) a SACM
    > Information Model.
    > 
    > _______________________________________________
    > sacm mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/sacm
    _______________________________________________
    sacm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sacm

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Sep 2017 20:41:14 +0000

Comments inline below.

Thanks,
Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Nancy Cam-
> Winget (ncamwing)
> Sent: Tuesday, September 19, 2017 2:07 PM
> To: Banghart, Stephen A. (Fed) <[email-masked]>;
> [email-masked]
> Subject: Re: [sacm] Draft updated charter for SACM
> 
> On 9/18/17, 11:08 AM, "sacm on behalf of Banghart, Stephen A. (Fed)"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     All,
> 
>     After discussion with a few other SACM document authors this version of
> the new charter proposal was put together. The changes throughout are
> minimal; the primary change is several additions to the work items section
> that covers other work currently being done in the WG.
> 
>     Securing information and the systems that store, process, and transmit
> that information is a challenging task for organizations of all sizes, and many
> high priority tasks .
>     A. Collection. The WG will define a standardized way to provide two types
> of imperative guidance to collectors over varying collection mechanisms:
> 
>     When classified , a set of instructions (such as vulnerability description
> data, YANG filter expressions, Windows Management Instrumentation
> classes, etc.) can be brokered to the appropriate collectors using the control
> plane functions  defined by "C. Orchestration and Communication" (below).
>     B. Evaluation. The working group will standardize a criteria language
> enabling evaluation of actual endpoint posture information against desired
> endpoint posture information to produce a standardized result. This
> extensible language will support complex Boolean statements, comparison
> operators, logical flow statements, and functions for string manipulation.
> Additionally, the working group will seek to discover an approach that allows
> data from any posture collection mechanism to be generically evaluated.
> 
>     C. Orchestration and Communication. The working group will define a set
> of control plane functions to enable the discovery and orchestration
> between devices that can provide the requisite information  sought by
> posture collectors, posture evaluators, data repositories, and other SACM
> [NCW] I think we need to incorporate https://tools.ietf.org/html/draft-ietf-
> sacm-terminology as we need to have a well understood set of definitions
> beyond “endpoint” and “posture”

[daw: When you suggest incorporating sacm-terminology, are you suggesting to add it as a work item? I am in favor of adding terminology as a work item, but I am concerned with referencing unstable terminology in the charter. We don't want the meaning of the charter to change over time.]

>     -  The WG will define a way to provide two types of imperative guidance to
> the correct SACM collectors: 1) Which target endpoints to collect from and 2)
> what to collect from these target endpoints. When classified, a set of
> instructions, such as vulnerability description data or YANG filter expressions,
> can be brokered to the appropriate collectors. Detecting and classifying
> beforehand might require orchestrating functions that go beyond the set of
> capabilities a SACM collector can provide.
> 
>     -  The WG will describe a criteria language capable of being evaluated
> against endpoint posture information to produce a standardized result. The
> and functions for string manipulation; and will be extensible enough to be
> applicable to the full range of collected posture attributes. Additionally, this
> document will describe an approach that allows data from any posture
> collection mechanism to be evaluated.
> 
>     - The WG will define a control plane function to enable the discovery and
> orchestration between devices that can provide the requisite information
> sought by posture collectors, posture evaluators or both. As an example, a
> document that describes an instance of such a control plane and transfer
> protocol for data, is through the use of XMPP and extensions as needed to
> demonstrate XMPP’s applicability to SACM.
> 
>     - A method of expressing software metadata is needed that is suitable for
> use by constrained devices. The WG will create a standards track document
> that defines a CBOR-based format that represents software metadata to
> include software identification, file hashes, and other descriptive
> information. This format will be derived from the ISO/IEC 19770-2 Software
> Identification (SWID) tag standard.
> [NCW]  I am not sure why this is called out explicitly as software metadata
> could also be represented with the Yang model?  Perhaps the intent is to
> show this as one example for how it can be expressed?  That is, there are
> other representations that the IETF is looking at that could also be leveraged.

[daw: This work item description is for the draft-ietf-sacm-coswid work, which is SWID tag based. Doing this work is not mutually exclusive with work on YANG-based software models. I personally believe both should be worked on. By including this work item, I wanted to make sure we identified an existing portion of adopted SACM work as something we plan to complete under this revised charter. This does not exclude working on YANG models in SACM or elsewhere that relate to software.]

> 
>     - To support collection of posture information from traditional computing
> devices (e.g., servers, laptops, etc.), the WG will create standards track
> documents describing mechanisms for the collection and delivery of
> information about installed software on an endpoint by extending IETF NEA.
> 
>     - To provide for the integration of multiple standards to support posture
> information collection, the WG will define best practices  for the collection of
> posture information from endpoints and its delivery to a collector, from
> which it can be distributed using the SACM messaging standards.
> [NCW] This seems to
> 
>     -The WG will define standards track documents describing extensions to
> the Resource-Oriented Lightweight Information Exchange (ROLIE) that
> provide IANA registrations and requirements to support the sharing of
> software, configuration information, and other forms of imperative
> guidance.
> [NCW] Similar to my previous comment, about CBOR/SWID,  there can be
> other means for providing information exchange.  For example, using Yang
> model and leveraging NETCONFs work for the information exchange.

[daw: This work item addresses 	draft-banghart-sacm-rolie-softwaredescriptor (which has been adopted) and 	
draft-mandm-sacm-rolie-configuration-checklist. The ROLIE-based software descriptor model supports vendor-to-enterprise exchange of CBOR/XML SWID information (a type of imperative guidance), which can be used to provide golden measurements, to construct vulnerability detection data, and other security automation/assessment related use cases. Configuration setting checklists expressed in a machine readable form are another example of imperative guidance that can be exchanged over ROLIE with the definition of a proper extension. This imperative guidance can be used to drive collection and evaluation by defining what needs to be gathered and what the expected state must be according to policy. ROLIE exchanges are different than the exchanges supported by NETCONF and SWIMA, which are focused on endpoint-to-enterprise exchanges of current state. Both the vendor-to-enterprise and the endpoint-to-enterprise exchanges are needed in my view, since they support different aspects of the assessment workflow.]

---

From: Adam Montville <[email-masked]>
Date: Thu, 21 Sep 2017 22:17:08 +0000

Would any of the additions/questions be addressed if we adhered to Karen's
initial reminder that "we plan to call out specific drafts using the
milestone process and not include them in the base charter"?

On Tue, Sep 19, 2017 at 1:41 PM Waltermire, David A. (Fed) <
[email-masked]> wrote:

> >     This working group will focus on collection, evaluation, and
> orchestration
> > and communication, as described herein.
> >
> [daw: When you suggest incorporating sacm-terminology, are you suggesting
> to add it as a work item? I am in favor of adding terminology as a work
> item, but I am concerned with referencing unstable terminology in the
> charter. We don't want the meaning of the charter to change over time.]
>
> >
> [daw: This work item description is for the draft-ietf-sacm-coswid work,
> which is SWID tag based. Doing this work is not mutually exclusive with
> work on YANG-based software models. I personally believe both should be
> worked on. By including this work item, I wanted to make sure we identified
> an existing portion of adopted SACM work as something we plan to complete
> under this revised charter. This does not exclude working on YANG models in
> SACM or elsewhere that relate to software.]
>
> >
> [daw: This work item addresses
> draft-banghart-sacm-rolie-softwaredescriptor (which has been adopted) and
> draft-mandm-sacm-rolie-configuration-checklist. The ROLIE-based software
> descriptor model supports vendor-to-enterprise exchange of CBOR/XML SWID
> information (a type of imperative guidance), which can be used to provide
> golden measurements, to construct vulnerability detection data, and other
> security automation/assessment related use cases. Configuration setting
> checklists expressed in a machine readable form are another example of
> imperative guidance that can be exchanged over ROLIE with the definition of
> a proper extension. This imperative guidance can be used to drive
> collection and evaluation by defining what needs to be gathered and what
> the expected state must be according to policy. ROLIE exchanges are
> different than the exchanges supported by NETCONF and SWIMA, which are
> focused on endpoint-to-enterprise exchanges of current state. Both the
> vendor-to-enterprise and the endpoint-to-enterprise exchanges are needed in
> my view, since they support different aspects of the assessment workflow.]
>
> >
> >     > Below is a draft update to our charter based on discussion at the
> last IETF
> > and
> >     > remember that we plan to call out specific drafts using the
> milestone
> > process
> > that
> >     > endpoint attributes enable automation, thus freeing practitioners
> to
> > focus on
> >     > high priority tasks.
> >     >
> >     > available specified elements' actual values 4. Compare actual
> element
> > values
> >     > This working group will focus on collection, evaluation, and
> orchestration
> > and
> >     > When classified, a set of instructions (such as vulnerability
> description
> > data,
> >     > etc.) can be brokered to the appropriate collectors using the
> control
> > plane
> >     > orchestrating functions that go beyond the set of capabilities a
> collector
> > can
> >     > manual configuration of targets and corresponding collection
> profiles will
> > not
> > enabling
> > of
> >     > definitions of Endpoint and Posture from RFC 5209). The working
> group
> > will,
> >     > guidance to the correct SACM collectors: 1) Which target endpoints
> to
> > collect
> >     > from and 2) what to collect from these target endpoints. When
> classified,
> > a
> >     > expressions, can be brokered to the appropriate collectors.
> Detecting
> > and
> >     > classifying beforehand might require orchestrating functions that
> go
> > beyond
> >     > - Evaluation: The working group will describe a criteria language
> capable
> > of
> >     > attributes. Additionally, this document will describe an approach
> that
> > allows
> >     > information sought by posture collectors, posture evaluators or
> both. As
> > an
> >     > example, a document that describes an instance of such a control
> plane
> > and
> >     > including protocol requirements and their associated use cases as
> well as
> > a
> >     > description of how SACM protocols fit together into a system, and
> 2) a
> > SACM
> >     > Information Model.
> >     >

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 22 Sep 2017 00:42:29 +0000

Hi Adam,
Thanks for that reminder….and yes, that was the gist of my comments.  That is, the charter is to define the intent of goals vs. calling out explicit drafts as those are best addressed in milestones….I am fine with the first proposed set of changes posted by Karen.  In general, I felt the additions are more suited for milestones.

                Nancy.

From: Adam Montville <[email-masked]>
Date: Thursday, September 21, 2017 at 3:17 PM
To: "Waltermire, David A. (Fed)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Banghart, Stephen A. (Fed)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sacm] Draft updated charter for SACM

Would any of the additions/questions be addressed if we adhered to Karen's initial reminder that "we plan to call out specific drafts using the milestone process and not include them in the base charter"?

On Tue, Sep 19, 2017 at 1:41 PM Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
Comments inline below.

Thanks,
Dave

> From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nancy Cam-
> Winget (ncamwing)
> To: Banghart, Stephen A. (Fed) <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>     All,
>

>     > From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Karen
>     > O'Donoghue
>     > To: [email-masked]<mailto:[email-masked]>
>     > [email-masked]<mailto:[email-masked]>
>     [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 22 Sep 2017 14:14:28 +0000

The charter should describe the work we are planning to do. The milestones should reflect the timing. Given that this group has suffered from a lack of agreement around what we are working on, I think it is prudent to be more concrete about our work items in the charter. I know of other WGs that do this when it serves their needs. I think we should keep and refine the work items text to get to a consensus position on what work needs to be done.

All of the work listed either is being worked on or has interested parties that are willing to do the work. This is another good reason to move forward with these work items.

Regards,
Dave

-------- Original Message --------
From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, September 21, 2017 8:42 PM -0400
To: Adam Montville <[email-masked]>, "Waltermire, David A. (Fed)" <[email-masked]>, "Banghart, Stephen A. (Fed)" <[email-masked]>, [email-masked]
Subject: Re: [sacm] Draft updated charter for SACM

Hi Adam,

                Nancy.

Thanks,
Dave

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 22 Sep 2017 15:12:05 +0000

The draft charter as it stands does not call out any specific drafts, but rather work items that the group is interested in. The version that Karen sent out on the 12th included 5 such items, one for collection, one for evaluation, one for messaging, one for a SACM architecture, and one for a SACM information model. My edits included 4 additional items, bringing the total list to 9.

I agree that the milestones system would be the perfect place to call out specific drafts and the timing around them.

-Stephen

From: Waltermire, David A. (Fed)
Sent: Friday, September 22, 2017 10:14 AM
To: Nancy Cam-Winget (ncamwing) <[email-masked]>; Adam Montville <[email-masked]>; Banghart, Stephen A. (Fed) <[email-masked]>; [email-masked]
Subject: Re: [sacm] Draft updated charter for SACM

Regards,
Dave

-------- Original Message --------
From: "Nancy Cam-Winget (ncamwing)" <[email-masked]<mailto:[email-masked]>>
Date: Thu, September 21, 2017 8:42 PM -0400
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "Waltermire, David A. (Fed)" <[email-masked]<mailto:[email-masked]>>, "Banghart, Stephen A. (Fed)" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Draft updated charter for SACM
Hi Adam,
Thanks for that reminder....and yes, that was the gist of my comments.  That is, the charter is to define the intent of goals vs. calling out explicit drafts as those are best addressed in milestones....I am fine with the first proposed set of changes posted by Karen.  In general, I felt the additions are more suited for milestones.

                Nancy.

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 21, 2017 at 3:17 PM
To: "Waltermire, David A. (Fed)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Banghart, Stephen A. (Fed)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Draft updated charter for SACM

Thanks,
Dave

> beyond "endpoint" and "posture"

> demonstrate XMPP's applicability to SACM.
>

>     > needed to demonstrate XMPP's applicability to SACM.
>     >

---

From: Adam Montville <[email-masked]>
Date: Fri, 22 Sep 2017 16:44:53 +0000

Yes, what you say is technically true - the work items in the charter do
not talk to specific drafts. But, the descriptions are detailed enough to
draw very straight lines to specific drafts.

It's up to the group what we want to do, I'm sure. To me, it matters less
where these things go and more about whether the group has agreement. But,
I do like the idea of abstract characteristics in the charter and specifics
in the milestones.

Adam

On Fri, Sep 22, 2017 at 8:12 AM Banghart, Stephen A. (Fed) <
[email-masked]> wrote:

> The draft charter as it stands does not call out any specific drafts, but
> rather work items that the group is interested in. The version that Karen
> sent out on the 12th included 5 such items, one for collection, one for
> evaluation, one for messaging, one for a SACM architecture, and one for a
> SACM information model. My edits included 4 additional items, bringing the
> total list to 9.
>
>
>
> I agree that the milestones system would be the perfect place to call out
> specific drafts and the timing around them.
>
>
>
> -Stephen
>
>
>
> *From:* Waltermire, David A. (Fed)
> *Sent:* Friday, September 22, 2017 10:14 AM
> *To:* Nancy Cam-Winget (ncamwing) <[email-masked]>; Adam Montville <
> [email-masked]>; Banghart, Stephen A. (Fed) <
> [email-masked]>; [email-masked]
>
>
> *Subject:* Re: [sacm] Draft updated charter for SACM
>
>
>
> The charter should describe the work we are planning to do. The milestones
> should reflect the timing. Given that this group has suffered from a lack
> of agreement around what we are working on, I think it is prudent to be
> more concrete about our work items in the charter. I know of other WGs that
> do this when it serves their needs. I think we should keep and refine the
> work items text to get to a consensus position on what work needs to be
> done.
>
>
>
> All of the work listed either is being worked on or has interested parties
> that are willing to do the work. This is another good reason to move
> forward with these work items.
>
>
>
> Regards,
>
> Dave
>
>
>
> To: Adam Montville <[email-masked]>, "Waltermire, David A.
> (Fed)" <[email-masked]>, "Banghart, Stephen A. (Fed)" <
> [email-masked]>, [email-masked]
> Thanks for that reminder….and yes, that was the gist of my comments.  That
> is, the charter is to define the intent of goals vs. calling out explicit
> drafts as those are best addressed in milestones….I am fine with the first
> proposed set of changes posted by Karen.  In general, I felt the additions
> are more suited for milestones.
>
>
>
>                 Nancy.
>
>
>
> *From: *Adam Montville <[email-masked]>
> *Date: *Thursday, September 21, 2017 at 3:17 PM
> *To: *"Waltermire, David A. (Fed)" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "Banghart, Stephen A. (Fed)" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [sacm] Draft updated charter for SACM
>
>
>
> collector can

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Mon, 25 Sep 2017 11:37:52 -0400

I suspect the place we are all getting confused is where the draft charter
states: "Specific work items will include the following:". Presumably, what
follows is work items the group intend to complete. I think Stephen's edits
were merely an attempt to ensure that those items also included work the
group has already adopted.

We need to decide if we want this charter to include any work items at all.
If so, we should include all the work items we have adopted, at a minimum.
If folks have additional work they intend to bring to SACM, and want to
include those items in the charter, I am open to that.

If we decide that we do not want to include specific work items in the
charter text, then everything from "Specific work items will include the
following" through to the end of the charter should be struck, and we
should spend some time ensuring that adopted and proposed work items are
abstractly included in the earlier text of the charter.

+1 to Eric's proposed edits to the charter text.

Jess

On Fri, Sep 22, 2017 at 12:44 PM, Adam Montville <[email-masked]
> wrote:

>> The charter should describe the work we are planning to do. The
>> milestones should reflect the timing. Given that this group has suffered
>> from a lack of agreement around what we are working on, I think it is
>> prudent to be more concrete about our work items in the charter. I know of
>> other WGs that do this when it serves their needs. I think we should keep
>> and refine the work items text to get to a consensus position on what work
>> needs to be done.
>>
>>
>>
>> All of the work listed either is being worked on or has interested
>> parties that are willing to do the work. This is another good reason to
>> move forward with these work items.
>>
>>
>>
>> Regards,
>>
>> Dave
>>
>>
>>
>> Thanks for that reminder….and yes, that was the gist of my comments.
>> That is, the charter is to define the intent of goals vs. calling out
>> explicit drafts as those are best addressed in milestones….I am fine with
>> the first proposed set of changes posted by Karen.  In general, I felt the
>> additions are more suited for milestones.
>>
>>
>>
>>                 Nancy.
>>
>>
>>
>> Would any of the additions/questions be addressed if we adhered to
>> Karen's initial reminder that "we plan to call out specific drafts using
>> the milestone process and not include them in the base charter"?
>>
>>
>>
>>
>>
>> >     > working group desires to fulfill in an innovative, automated
>> manner
>> > capable
>> >     > A. Collection. The WG will define a standardized way to provide
>> two
>> > types of
>> >     > guidance to the correct SACM collectors: 1) Which target
>> endpoints to
>> > collect