Security Automation and Continuous Monitoring
charter-ietf-sacm-03

   In accordance with existing IETF processes, the group will communicate
   with and invite participation from other relevant standards bodies and regulatory
   organizations

Is there any sense of what bodies and organizations might be relevant?  Surely we know some now, and can mention them.  Suppose the WG decided that none were relevant; would that be acceptable?

I support work in this area. I have to say, however, not having had the opportunity to attend the meetings on this matter or read the proposals, that I found it hard to read the draft charter. It was not crystal clear to me what the working group will do, even after having read it.

Joel how about:

OLD:

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 and can be used or re-used to meet the goals of more than one working group.

NEW:

The working group will communicate with non-IETF organizations working on related specifications and will encourage industry participation in the development of the WG's documents.  Other organizations involved in the initial sacm space include ISO/IEC and TCG as well as government agencies such as NIST.

spt 
--------------
I'm ok with this.


What other SDO's or existing external work does this integrate?

----

Changing my position until we discuss this on the call.

Subject: Re: [sacm] sacm charter review

Hi Sean,

A list of organizations that are involved in the area, as identified in this
discussion includes: 

- TCG
- DMTF
- FIRST
- The Open Group
- ISO/IEC
- W3C
- OASIS
- OMG
- NIST
- MITRE
- 3GPP

It's up to the IESG to decide if we should list these (or some of them)
explicitly, or we should leave to the WG after its formation is approved to
initiate communication and invite participation. 

Regards,

Dan

   - An Informational document on Use Cases
   - An Informational document on Requirements
   - An Informational document on SACM Architecture

Unlike the standards track documents, which are well-specified, describing exactly what is going to be produced, these are not. I'd like to understand why there are three documents. It seems to me that Use Cases would simply be examples for the Requirements, and the Requirements would simply define the SACM Architecture. Is that right, or is the Requirements document really a "rules for writing the protocol document" document? It seems to me these could and should all be folded into one document, namely the Architecture document. But I'd also like to hear what the purpose of the Architecture document is. If it's a higher-level layout of how the protocol documents fit together and how a SACM system can be built using the protocol documents, that should probably be a standards track document instead of Informational. But if it's simply an overview of the system, then again I don't understand why it is different than the Requirements or Use Cases document.

So far, these items look like make-work items. Without better explanation, they could cause the WG to spin on them for quite some time.

I agree with Barry that the last paragraph on re-chartering should go away.

All that said, while I'd prefer these things to be addressed before it goes for IETF Review, I don't object to it going forward. If this were going for approval, I might feel differently.

If you could identify the other SDOs you expect to work closely with, that would be helpful, especially to the IAB.

It would be great if this text wasn't at the bottom of the proposed charter when it's sent out:

This message and attachments may contain confidential information. If it appears
that this message was sent to you by mistake, any retention, dissemination,
distribution or copying of this message and attachments is strictly prohibited.
Please notify the sender immediately and permanently delete the message and any
attachments.