Subject: Re: [sacm] Proposed text for the SACM WG charter

From: Sean Turner <[email-masked]>
Date: Thu, 02 May 2013 13:04:06 -0400

On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote:
>
> Hi Sean,
>
> Following the second BOF in Orlando and your instructions, we have reached consensus on the mailing list on requesting the formation of a SACM Working Group, as well as on the proposed text for the future Working Group charter as listed below. Please forward this to the IESG for approval and let us know what are the next steps.
>
> Thanks and Regards,
>
> Kathleen and Dan

Apologies for taking so long to get back to everyone on this.
I've been trying to piece together my thoughts on this charter
coupled with a lot of input I've gathered or that was
unsolicited.

<concerns>

These are for background so no need to reply to these. I think
these can all be addressed by charter text:

1. The comment I've received most often when discussing this
charter is "what are they going to do that's not already being
done in nea or mile."  We need to make that clear.  I'm sure
we'll get dinged by somebody about mentioning other WGs in the
charter because they might close/etc but I think explicitly
explaining how the work done elsewhere in the IETF relates to
this possible work is warranted in this case because I've been
asked about this so many times.  I think it can be said that sacm
is about using mile, nea, and likely other to do more and we
should say that somewhere.

2. 2nd most asked question "what exactly are they going to do?"
This, I think, is easily addressed by including more about what
exactly is entailed in "enabling endpoint assessment."

3. The next I've been struggling with.  The 2nd paragraph about
reusing existing "stuff" and the paragraph about doing a survey
to determine which "stuff" could meet our needs are intertwined.
I think the phrase "whenever possible" might address my concern
about adopting other's work because the WG can't just
take "stuff" developed elsewhere; those that developed the
"thing" may need give it to us to adopt.  Because as everybody
should be well aware of: nothing you submit to an SDO will emerge
unchanged when it gets published by the SDO.

4. This is a rubberstamping exercise. We're going to work from
requirements, then folks will champion solutions, and then the wg
will pick from those solutions.

</concerns>

Now on to the charter itself.  I split it up into sections.
Sections start with <sectionname> and end with </sectionname>.
"spt:" is before points I'd like to make.

<charter: composed of preamble, description, and g&m>

<preamble>

spt: chairs, ADs, mailing list looks fine so I took it out for
brevity.

spt: BTW - I've recruited more than a few possible chairs.
If you're interested in becoming a WG chair, the first step is to
ask.  Note: if you're planning on authoring some of the drafts,
you might be out of the running because we normally try to avoid
author/chair conflicts as much as possible.

</preamble>

<description: will be composed of a) intro, b) summary
of work we're going to do, c) what we're not going to do,
d) deliverables, and e) misc>

<intro>

   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
   processes to collect, verify, and update security system
   configurations would allow easier automation of the processes.
   Automating these routine tasks would free security
   practitioners to focus on high priority tasks, and should
   improve operators' ability to prioritize risk based on timely
   information about threats and vulnerabilities. This working
   group (wg) will define security automation protocols and data
   format standards in support of information security processes
   and practices. These standards will help security practitioners
   be more effective by automating routine tasks related to client
   and server security freeing them to focus on more advanced
   tasks. The initial focus of this wg is to address enterprise
   use cases pertaining to the assessment of endpoint posture
   (using the definitions of Endpoint and Posture from RFC 5209).

spt: I think the intro is good, what I'd like to see next is some
text about what "assesment of endpoint posture" entails but
that'll go in the <summary of work we're going to do> section.
Few folks are going to take the time to read all the documents
and putting it in the charter will end this line of questioning.
This discussion continues in the <summary of work we're going to
do> section.

</intro>

<reuse>

   The working group will, whenever reasonable and possible, reuse
   existing protocols, mechanisms, information and data models. Of
   particular interest to this working group are the security
   automation specifications supporting asset, change,
   configuration, and vulnerability management.

spt: This needs to be merged with the last paragraph in the
<deliverables> section.

</reuse>

<summary of the work we're going to do>

   The working group will define:

   1. A set of standards to enable assessment of endpoint posture.
   This area of focus provides for necessary language and data
   format specifications.

   2. A set of standards for interacting with repositories of
   content related to assessment of endpoint posture.

spt: Instead of this numbered list I'd like as much text as it
takes to explain what is entailed in the assessment of endpoint
posture and why we need repository protocols.  This is what
people are going to want to know when reading this charter.  I
think this is the important part of the pact you're making with
the IESG.  What ought these next two paragraph say:

   Assessment of endpoint posture entails ...

   Repository protocols are needed to ...

</summary of the work we're going to do>

<what we're not going to do>

spt: Here's where I'd like some discussion about the NEA-based
protocols and how they can and can't be used, whether they are
"the" protocols and if not why not.

   NEA-based protocols provide ... but we're doing ...

spt: I'd also like to give some lip service to the MILE-based
protocols and how they'll fit in.  Even if it's that's for a
later stage I'd argue we need to include it now so that it's
clear we're not trying to overlap.

   MILE-based/like protocols/formats provide ... and will fit in
   the overall SACM architecture ...

spt: Is there anything we can say about the existing management
protocols such as SNMP/NETCONF?

spt: We'll have a motherhood and apple pie statement later about
reuse so no need to put it in this section.

</what we're not going to do>

<deliverables>

   sacm will achieve the following deliverables:

   - An Informational document on Use Cases

   - An Informational document on Requirements

spt: Are the use cases and deliverables about sacm or just the
endpoint assessment bit?

   - An Informational document on SACM Architecture

spt: The architecture document is where you can go nuts and
explain the grand vision.

   - A standards-track document specifying a protocol and data
   format for retrieving configuration and policy information for
   driving data collection and analysis

spt: Yeah so the above bullet needs to be introduced in the
<summary of work we're going to do> section.

spt: Are you sure the data format and protocol will be in one
draft?

spt: Is it really "a protocol" or is it "protocols"?

   - A standards-track document specifying a protocol and data
   format for collecting actual endpoint posture

spt: strike "actual"

spt: Is it really "a protocol" or is it "protocols"?  Is it nea?

spt: Are you sure the data format and protocol will be in one
draft?

   The working group will create an overview of related standards
   work Internet-Draft which will document existing work in the
   IETF or in other SDOs which can be used as-is or as a starting
   point for developing solutions to the SACM requirements. The
   working group may decide to make of this document an
   Informational RFC, but this is not a mandatory deliverable.

spt: Funny I would have liked to have had this survey draft long
ago ;)

spt: I'm trying to see how this optional deliverable relates to
the requirements draft and the mandate to reuse whenever
protocols possible.  What I've seen happen: WG documents
requirements, solutions are documented (disclose IPR step here),
authors of those solutions make their case to the WG as to why
their solution is the best, wg then decides which to choose.

spt: I don't want to limit this to SDO-developed work.  First I
don't want to get in to defining an SDO and second there might
exist a non-SDO that has done great work and that is willing to
further develop their work in the IETF.

spt: Normally, I'd not impose this restriction but based on the
number of "rubberstamp" questions I think the requirements draft
is pretty darn important; seems like it needs to be done first or
shortly after the use cases and architecture.  I made that point
in the provided text and moved the milestones around.

spt: This is slightly tweaking the two paragraphs you had:

   There already exist protocols and data formats (i.e.,
   solutions) at various levels of maturity and industry adoption
   that might be embraced to solve aspects of the SACM charter
   beyond those NEA-based protocols and MILE-based
   protocols/formats.   To assist the wg when its comparing
   possible solutions against the wg-defined requirements, a draft
   will be produced that documents sacm-related IETF-developed
   (e.g., NEA and MILE) and non-IETF-developed solutions.  This
   draft may or may not progress out of the wg but it will
   complete and the wg will progress the use cases, requirements
   and architecture drafts to the IESG prior to shifting its focus
   to protocol work.

</deliverables>

<misc>

   The working group will work in close coordination with other
   WGs in the IETF (including but not limited to MILE and NEA) in
   order to create solutions that do not overlap (for example for
   the repository access protocol) and can be used or re-used to
   meet the goals of more than one working group.

I know we discussed wgs previously, but here I think we can leave
them out:

   Close coordination with other WGs in the IETF is needed to
   avoid duplicative and overlapping solutions (e.g., management
   and repository protocols).

spt: Hopefully with the earlier additions to the <what we're
going to do> section this paragraph won't come so quite out of
the blue.

   In accordance with existing IETF processes, the group will
   communicate with and invite participation from other relevant
   standards bodies and regulatory organizations, and if necessary
   reuse existing liaison relationships or request the
   establishment of new liaison relationships.

spt: IAB alert!  What regulatory organizations are we talking
about here?  You don't have to burn this list in the charter, but
you'd better give me a preliminary list so that I can pre-grease
the IAB's wheels on this issue.

   After the work items in the current charter have been submitted
   to and approved by the IESG, the WG will recharter or close.

spt: Because I don't want this to go on forever, I'd like to do
something a little more radical: let's put a 2 year limit on the
charter.  The milestones seem to think we'll be done by then so
let's burn it in the charter:

   After the work items in the current charter have been submitted
   to and approved by the IESG or after two years from the date of
   approval of this charter, the WG will recharter or close.

</misc>

</description>

<g&m>

spt: some minor tweaks:

   Goals and Milestones

   Sep 2013 - Adopt Use Case draft (informational)

   Oct 2013 - Adopt Requirements draft (informational)

   Oct 2013 - Adopt SACM Architecture draft (informational)

   Nov 2013 - Adopt overview of sacm-related work draft
   (informational)

spt: To line up with the earlier comment I want at least want a
WGLC of the use cases, requirements, and architecture to do out
before protocol data formats.

   Apr 2014 - Submit Use Cases for consideration as Informational
   RFC

   Apr 2014 - Submit Requirements for consideration as
   Informational RFC

   Apr 2014 - Submit SACM Architecture for consideration as
   Informational RFC

   May 2014 - Adopt protocol and data format draft for retrieving
   configuration and policy information for driving data
   collection and analysis (standards track)

   May 2014 - Adopt a protocol and data format for collecting
   endpoint posture

   Oct 2014 - Submit a protocol and data format for retrieving
   configuration and policy information for driving data
   collection and analysis for consideration as standards-track
   RFC

   Oct 2014 - Submit a protocol and data format for collecting
   actual endpoint posture for consideration as standards-track
   RFC

</g&m>

</charter>

spt

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 2 May 2013 17:21:45 +0000

Sean,

Thanks for your helpful comments. One quick question.

> will pick from those solutions.

Did you mean that this SHOULD NOT be a rubberstamping
exercise or it SHOULD be one? Please clarify.

Given the preceding sentences, which explain that
"nothing you submit to an SDO will emerge unchanged
when it gets published by the SDO", I assume that
you mean SACM SHOULD NOT be a rubberstamping exercise
and the charter SHOULD say so. I agree with that view.

I have a bunch of other questions or comments
related to your other comments below but I
figured I'd get this quick question answered
first.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
> Sent: Thursday, May 02, 2013 1:04 PM
> To: [email-masked]
> Subject: Re: [sacm] Proposed text for the SACM WG charter
> 
> > Following the second BOF in Orlando and your instructions, we have
> reached consensus on the mailing list on requesting the formation of a
> SACM Working Group, as well as on the proposed text for the future
> Working Group charter as listed below. Please forward this to the IESG
> for approval and let us know what are the next steps.
> >
> > Thanks and Regards,
> >
> > Kathleen and Dan
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Sean Turner <[email-masked]>
Date: Thu, 02 May 2013 13:48:35 -0400

> exercise or it SHOULD be one? Please clarify.

Some people think it is going to be one.  It SHOULD NOT be one and I 
think forcing the requirements to get done first SHOULD make others feel 
more comfortable that it won't be.

spt

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 2 May 2013 16:33:47 -0400

FYI - We did have at least one volunteer (graciously) confirm that she would work on the requirements document and a second that is reaching out to Nancy Cam-Winget to assist.  This should help.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Thursday, May 02, 2013 1:49 PM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [sacm] Proposed text for the SACM WG charter

spt

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 2 May 2013 18:40:42 -0400

Hi,

I think it makes sense to consider requirements first.
However, I think you need to be careful that the requirements don't imply a
particular solution.
It is common practice to write RFP specs to favor a particular vendor's
solution, and eliminating all others.
Requirements can lead to a rubber-stamping approach.

Requirements for a greenfield solution might differ from requirements that
permit use of existing technologies.
I would hate to see SACM "require" a new protocol be designed for their
"special case" requirements.
(I've seen this a few times in twenty years of IETF work ;-)
Often thinking about the problem a little differently can make existing
technologies a viable solution.

SNMPv3 invented their own security protocol because the protocol designers
(incl. me) "required" no 3rd-party dependencies.
And SNMPv3 designers "required" the ability to support multiple messaging
models, security models, user-based access controls, and other options.
But operators preferred SSH- and TLS-based solutions so they didn't have to
maintain yet another security infrastructure.
And there have been no other optional messaging models to date, and many of
the other "required" features are never used.
So we need to make sure the requirements are real and not unnecessary
nice-to-haves.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean
Turner
Sent: Thursday, May 02, 2013 1:49 PM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [sacm] Proposed text for the SACM WG charter

On 5/2/13 1:21 PM, Stephen Hanna wrote:
> Did you mean that this SHOULD NOT be a rubberstamping exercise or it 
> SHOULD be one? Please clarify.

Some people think it is going to be one.  It SHOULD NOT be one and I think
forcing the requirements to get done first SHOULD make others feel more
comfortable that it won't be.

spt

> Given the preceding sentences, which explain that "nothing you submit 
> to an SDO will emerge unchanged when it gets published by the SDO", I 
> assume that you mean SACM SHOULD NOT be a rubberstamping exercise and 
> the charter SHOULD say so. I agree with that view.
>
> I have a bunch of other questions or comments related to your other 
> comments below but I figured I'd get this quick question answered 
> first.
>
> Thanks,
>
> Steve
>
>> reached consensus on the mailing list on requesting the formation of 
>> a SACM Working Group, as well as on the proposed text for the future 
>> Working Group charter as listed below. Please forward this to the 
>> IESG for approval and let us know what are the next steps.
>>>
>>> Thanks and Regards,
>>>
>>> Kathleen and Dan
>>
>> coupled with a lot of input I've gathered or that was unsolicited.
>>
>> <concerns>
>>
>> These are for background so no need to reply to these. I think these 
>> can all be addressed by charter text:
>>
>> 1. The comment I've received most often when discussing this charter 
>> is "what are they going to do that's not already being done in nea or 
>> mile."  We need to make that clear.  I'm sure we'll get dinged by 
>> somebody about mentioning other WGs in the charter because they might 
>> close/etc but I think explicitly explaining how the work done 
>> elsewhere in the IETF relates to this possible work is warranted in 
>> this case because I've been asked about this so many times.  I think 
>> it can be said that sacm is about using mile, nea, and likely other 
>> to do more and we should say that somewhere.
>>
>> reusing existing "stuff" and the paragraph about doing a survey to 
>> determine which "stuff" could meet our needs are intertwined.
>> I think the phrase "whenever possible" might address my concern about 
>> adopting other's work because the WG can't just take "stuff" 
>> developed elsewhere; those that developed the "thing" may need give 
>> it to us to adopt.  Because as everybody should be well aware of: 
>> nothing you submit to an SDO will emerge unchanged when it gets 
>> published by the SDO.
>>
>> ask.  Note: if you're planning on authoring some of the drafts, you 
>> might be out of the running because we normally try to avoid 
>> <description: will be composed of a) intro, b) summary of work we're 
>> going to do, c) what we're not going to do,
>> text about what "assesment of endpoint posture" entails but that'll 
>> go in the <summary of work we're going to do> section.
>> Few folks are going to take the time to read all the documents and 
>> putting it in the charter will end this line of questioning.
>> spt: Instead of this numbered list I'd like as much text as it takes 
>> to explain what is entailed in the assessment of endpoint posture and 
>> why we need repository protocols.  This is what people are going to 
>> want to know when reading this charter.  I think this is the 
>> important part of the pact you're making with the IESG.  What ought 
>> these next two paragraph say:
>>
>> protocols and how they can and can't be used, whether they are "the" 
>> protocols and if not why not.
>>
>> protocols and how they'll fit in.  Even if it's that's for a later 
>> stage I'd argue we need to include it now so that it's clear we're 
>> not trying to overlap.
>>
>> spt: The architecture document is where you can go nuts and explain 
>> the grand vision.
>>
>> spt: Yeah so the above bullet needs to be introduced in the <summary 
>> of work we're going to do> section.
>>
>> spt: Are you sure the data format and protocol will be in one draft?
>>
>> spt: Are you sure the data format and protocol will be in one draft?
>>
>> spt: Funny I would have liked to have had this survey draft long ago 
>> ;)
>>
>> spt: I'm trying to see how this optional deliverable relates to the 
>> requirements draft and the mandate to reuse whenever protocols 
>> possible.  What I've seen happen: WG documents requirements, 
>> solutions are documented (disclose IPR step here), authors of those 
>> solutions make their case to the WG as to why their solution is the 
>> best, wg then decides which to choose.
>>
>> spt: I don't want to limit this to SDO-developed work.  First I don't 
>> want to get in to defining an SDO and second there might exist a 
>> non-SDO that has done great work and that is willing to further 
>> develop their work in the IETF.
>>
>> number of "rubberstamp" questions I think the requirements draft is 
>> pretty darn important; seems like it needs to be done first or 
>> shortly after the use cases and architecture.  I made that point in 
>> the provided text and moved the milestones around.
>>
>> spt: Hopefully with the earlier additions to the <what we're going to 
>> do> section this paragraph won't come so quite out of the blue.
>>
>> spt: IAB alert!  What regulatory organizations are we talking about 
>> here?  You don't have to burn this list in the charter, but you'd 
>> better give me a preliminary list so that I can pre-grease the IAB's 
>> wheels on this issue.
>>
>> charter.  The milestones seem to think we'll be done by then so let's 
>> burn it in the charter:
>>
>> spt: To line up with the earlier comment I want at least want a WGLC 
>> of the use cases, requirements, and architecture to do out before 
>> protocol data formats.
>>

---

From: Sean Turner <[email-masked]>
Date: Thu, 02 May 2013 21:14:58 -0400

> So we need to make sure the requirements are real and not unnecessary

Dave,

Because this is not an entirely greenfield design I so absolutely want 
to make it clear now to everybody that we're going to have to do some 
kind of beauty contest.  And, I really want to make sure that we don't 
end up writing the requirements in such a way as to pigeonhole us into a 
solution.  You, others, and myself will need to make sure we don't stray 
from that goal.  Obviously, I'd like to ensure reality is injected in 
the process.

If we get to a place where there's one unopposed solution and there's a 
couple of tweaks required to meet the wg requirements, I hope the 
proponents of the solution will see the benefit in making those tweaks. 
  I'd fully expect the proponent to fight (possibly a lot) on making 
willy-nilly changes, but if the wg consensus is to make a change then 
the authors of the wg draft really need to make that change - that's 
just how we do it.

If we get to a place where there's more than one solution that seemingly 
meets the requirement, then I truly hope that the proponents won't take 
their marbles and go home and will work together to bring something kind 
of merged/compromised solution forward.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 02 May 2013 21:15:49 -0400

That's good news.

spt

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 3 May 2013 10:49:55 +0000

Sean,

I completely agree with what you wrote. We should agree
on requirements based on our use cases then select the
best proposal among the several we'll probably receive.
We may choose to combine two proposals and we'll definitely
end up changing whatever we choose.

However, I have often found that there needs to be some
interplay between requirements definition and designing
the solution. A strictly sequential approach often leads
to a suboptimal design. We may find that a particular
requirement just can't be met or that a new one is needed.
I'm not suggesting that we make the requirements limp as
a noodle or that we design them to favor one solution.
I'm just suggesting that we should not send the requirements
to the IESG before we have decided on a solution. I'd like
to see the milestone for sending the requirements to the
IESG come AFTER the adoption of the protocols and formats.

Thanks,

Steve

> Sent: Thursday, May 02, 2013 9:15 PM
> To: ietfdbh
> Cc: Stephen Hanna; [email-masked]
> think
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of Sean Turner
> charter
> about
> takes
> ago
> don't
> WGLC

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 May 2013 13:10:53 +0000

Hi, 

I am trying to decompose Sean's input and his requests for clarification into smaller pieces, so that we can deliver a charter text that is more clear on the scope and goals and the relations with other work. 

> spt: Instead of this numbered list I'd like as much text as it takes to
> explain what is entailed in the assessment of endpoint posture and why
> we need repository protocols.  This is what people are going to want to
> know when reading this charter.  I think this is the important part of
> the pact you're making with the IESG.  What ought these next two
> paragraph say:
> 
> spt: Here's where I'd like some discussion about the NEA-based protocols
> and how they can and can't be used, whether they are "the" protocols and
> if not why not.
> 
> spt: I'd also like to give some lip service to the MILE-based protocols
> and how they'll fit in.  Even if it's that's for a later stage I'd argue
> we need to include it now so that it's clear we're not trying to
> overlap.
> 
> spt: We'll have a motherhood and apple pie statement later about reuse
> so no need to put it in this section.
> 

Can Steve or somebody else try to draft the details required by Sean and see if we can get consensus around them? 

Thanks and Regards,

Dan

---

From: Randy Turner <[email-masked]>
Date: Tue, 14 May 2013 10:52:54 -0700

I would paraphrase Steve's comment by saying that requirements should not be stipulated if they are not technically feasible.  Therefore, when a requirement is proposed, there should be (preferably) a few alternatives (not just one) about how this requirement could be realized in a reasonable/sensible fashion.  Or it could be that the requirement is "self-evident" as far as engineering a solution, which would require much less discussion about  the "how".

Randy