Subject: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

From: Sean Turner <[email-masked]>
Date: Thu, 27 Jun 2013 09:34:14 -0400

Another block.

Since the call is in about 2 hours I don't really expect to resolve 
these now, but be thinking about how we might address Benoit's points. 
These kind of comments should come as no surprise being that he's the 
management AD and management is the proposed wg's name.

spt

-------- Original Message --------
Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK 
and COMMENT)
Date: Thu, 27 Jun 2013 06:18:24 -0700
From: Benoit Claise <[email-masked]>
To: The IESG <[email-masked]>

Benoit Claise has entered the following ballot position for
charter-ietf-sacm-00-06: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

"The working group will, whenever reasonable and possible, reuse
existing
protocols, mechanisms, information and data models."

Fine. Now, I really would like to see an information model document (see
RFC 3444) as a deliverable.
And then the mapping to protocol/data model.

I had to read the charter multiple times to get an idea of the "security
information" might mean... Software version, patches, vulnerabilities.
Maybe it's defined by "The initial focus of this work is to address
enterprise use cases pertaining to the
assessment of endpoint posture (using the definitions of Endpoint and
Posture from RFC 5209).".
And I'm still not quite sure. Hence the importance of the information
model as a milestone.

"An example of such an endpoint posture assessment could include, but is
not
limited to, the following general steps:
1. Identify endpoints
2. Determine specific endpoint elements to assess
3. Collect actual value of elements
4. Compare actual element values to expected element values
5. Report results"
Then I see in the next sentence of the charter: "policy management"

The WG scope is (too) huge: inventory management + monitoring + fault
management + policy management?
Please don't re-invent monitoring and fault management.
Is policy management in scope or not? I guess no.
And inventory: I understand that it means device inventory, but I see
later also "vulnerability identifiers".
Clearly mentions what's in scope and what is not.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"Repository protocols are needed to store, update, and retrieve
configuration
checks and other types of content required for posture assessment (see
step 2
above)."
I don't know what a repository protocol is.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 27 Jun 2013 10:03:37 -0400

Hi Sean,

The second one could be changed to repository access protocol and you can list a RESTful interface as an example.

For the first, reuse will make the scope possible.  There is no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mappings or relationships between existing methods.  In some cases, we may need to select from proposed methods, improve or combine them.

Thanks,
Kathleen 

Sent from my iPhone

On Jun 27, 2013, at 9:34 AM, "Sean Turner" <[email-masked]> wrote:

> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Adam Montville <[email-masked]>
Date: Thu, 27 Jun 2013 14:15:49 +0000

Agree.

This domain is problematic in describing scope for the reasons I have previously mentioned - assessing posture (a security use case) is something that undoubtedly touches a lot of other related areas and efforts.  As Kathleen points out, reuse is a key to managing scope.

Adam

________________________________________
From: [email-masked] [[email-masked]] on behalf of Moriarty, Kathleen [[email-masked]]
Sent: Thursday, June 27, 2013 7:04 AM
To: Sean Turner
Cc: [email-masked]
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

Hi Sean,

Thanks,
Kathleen

Sent from my iPhone

...

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.

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Jun 2013 10:30:40 -0400

A couple of people have asked what block means.  It's like a discuss on 
a draft that's up for IESG evaluation.  If it's not addressed (and it's 
reasonable and other support it) then the draft does not progress.  So 
for sacm that means so far we have two we have to address.  I'll try my 
best on the call, but we may need to make some changes to make the other 
ADs comfortable with the charter.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Jun 2013 10:35:11 -0400

> The second one could be changed to repository access protocol and you can list a RESTful interface as an example.

I'm also thinking that we could indent everything from:

An example ... to ... Boolean logic. and move the 2. after the paragraph 
that ends Boolean logic to keep them points about 1 and 2 together. 
Then it'd flow from #2 to what the repository was.  Then again, it might 
just be a terminology thing: you say tomato I say tomato ;)

> For the first, reuse will make the scope possible.  There is no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mapping…

That's what I told him via jabber, but we'll still do it on the call. 
This is mostly about making sure that everybody agrees (the wg and the 
iesg) about the contract we're getting in to.  If we overstep or miss 
the mark we'll hear about it.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 27 Jun 2013 14:40:20 +0000

>From the operational perspective what I believe Benoit would like to see added is a deliverable that looks like: 

- A standards-track document specifying the informational model for endpoints data posture and its mapping into the protocol and data format for
collecting actual endpoint posture

We can argue that the information model can be part of the SACM architecture document. 

Do we need a data model deliverable now? Maybe this can be the object of a later charter. This phase being focused on defining the architecture (including information model), protocols and data formats (data modeling language) - a later phase or another WG can deal with the data models specific to the various functions. 

I would also observe that we did not define Milestones in the proposed charter. I am surprised that no AD raised a BLOCK about it. 

Should it be something like: 

- Initial submission of SACM Architecture Internet-Draft - October 2013
- Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft - January 2014
- Initial submission of protocol and data format for collecting endpoint posture Internet-Draft - January 2014
- Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC - May 2014
- Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard - September 2014
- Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard - September 2014

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam Montville
> Sent: Thursday, June 27, 2013 5:16 PM
> To: Moriarty, Kathleen; Sean Turner
> Cc: [email-masked]
> This domain is problematic in describing scope for the reasons I have
> previously mentioned - assessing posture (a security use case) is
> something that undoubtedly touches a lot of other related areas and
> efforts.  As Kathleen points out, reuse is a key to managing scope.
> 
> Adam
> 
> From: [email-masked] [[email-masked]] on behalf of
> Moriarty, Kathleen [[email-masked]]
> The second one could be changed to repository access protocol and you
> can list a RESTful interface as an example.
> 
> For the first, reuse will make the scope possible.  There is no
> intention of reinventing the wheel, but rather to provide uniform ways
> to perform these functions where we may need to create mappings or
> relationships between existing methods.  In some cases, we may need to
> select from proposed methods, improve or combine them.
> 
> Thanks,
> Kathleen
> 
> Sent from my iPhone
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > existing protocols, mechanisms, information and data models."
> >
> > Fine. Now, I really would like to see an information model document
> > (see RFC 3444) as a deliverable.
> > I had to read the charter multiple times to get an idea of the
> > "security information" might mean... Software version, patches,
> vulnerabilities.
> > enterprise use cases pertaining to the assessment of endpoint posture
> > (using the definitions of Endpoint and Posture from RFC 5209).".
> > "An example of such an endpoint posture assessment could include, but
> > is not limited to, the following general steps:
> > 1. Identify endpoints
> > 2. Determine specific endpoint elements to assess 3. Collect actual
> > value of elements 4. Compare actual element values to expected element
> > values 5. Report results"
> > configuration checks and other types of content required for posture
> > assessment (see step 2 above)."
> 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.

---

From: <[email-masked]>
Date: Thu, 27 Jun 2013 14:48:40 +0000

I would think that should be a part of the architecture document and if it needed expanding then we could break it out later.

The Milestones are listed in the draft charter at http://datatracker.ietf.org/wg/sacm/charter/

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: <Romascanu>, "Dan (Dan)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 27, 2013 4:40 PM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

Dan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Adam Montville
Sent: Thursday, June 27, 2013 5:16 PM
To: Moriarty, Kathleen; Sean Turner
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-
06: (with BLOCK and COMMENT)
Agree.
This domain is problematic in describing scope for the reasons I have
previously mentioned - assessing posture (a security use case) is
something that undoubtedly touches a lot of other related areas and
efforts.  As Kathleen points out, reuse is a key to managing scope.
Adam
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of
Moriarty, Kathleen [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, June 27, 2013 7:04 AM
To: Sean Turner
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-
06: (with BLOCK and COMMENT)
Hi Sean,
The second one could be changed to repository access protocol and you
can list a RESTful interface as an example.
For the first, reuse will make the scope possible.  There is no
intention of reinventing the wheel, but rather to provide uniform ways
to perform these functions where we may need to create mappings or
relationships between existing methods.  In some cases, we may need to
select from proposed methods, improve or combine them.
Thanks,
Kathleen
Sent from my iPhone
On Jun 27, 2013, at 9:34 AM, "Sean Turner" <[email-masked]<mailto:[email-masked]>> wrote:
> From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
> To: The IESG <[email-masked]<mailto:[email-masked]>>
>
vulnerabilities.
> [email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Thu, 27 Jun 2013 15:20:16 +0000

This seems to be the real issue.  We could wait and break it out later (I assume "it" is the data model information), but then it looks like we don't really know what we're going to deliver because we don't have it explicitly listed.

I am amenable to adding the deliverable as Dan has proposed.  Such a deliverable could end up being a full-on technical specification or an applicability statement referencing existing work.

Adam

________________________________
From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, June 27, 2013 7:49 AM
To: [email-masked]; Adam Montville; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

Kent Landfield

Dan

-----Original Message-----
vulnerabilities.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 27 Jun 2013 15:55:13 +0000

Sorry, I was looking at another page which did not have the milestones listed.

Just to make sure that we have the same understanding about the differentiation made between information model and data model - Benoit is using the terminology defined by http://www.rfc-editor.org/rfc/rfc3444.txt

Regards,

Dan

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, June 27, 2013 6:20 PM
To: [email-masked]; Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

Adam

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of [email-masked]<mailto:[email-masked]> [[email-masked]]
Sent: Thursday, June 27, 2013 7:49 AM
To: [email-masked]<mailto:[email-masked]>; Adam Montville; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)
I would think that should be a part of the architecture document and if it needed expanding then we could break it out later.

Kent Landfield

Dan

-----Original Message-----
vulnerabilities.

...

---

From: Eric Walker <[email-masked]>
Date: Thu, 27 Jun 2013 08:57:31 -0700

Hi,

I have been following this conversation from the sidelines.  I do not mind
a document that makes reference to existing work as an initial step, but my
hope is that the IETF will eventually take full ownership of whatever it is
that SACM covers, in the event that it forms as a working group.

Eric

From:	Adam Montville <[email-masked]>
To:	"[email-masked]" <[email-masked]>,
            "[email-masked]" <[email-masked]>,
            "[email-masked]" <[email-masked]>,
            "[email-masked]" <[email-masked]>
Cc:	"[email-masked]" <[email-masked]>
Date:	06/27/2013 08:34 AM
Subject:	Re: [sacm] Fwd: Benoit Claise's Block on
            charter-ietf-sacm-00-06: (with BLOCK and COMMENT)
Sent by:	[email-masked]

This seems to be the real issue.  We could wait and break it out later (I
assume "it" is the data model information), but then it looks like we don't
really know what we're going to deliver because we don't have it explicitly
listed.

I am amenable to adding the deliverable as Dan has proposed.  Such a
deliverable could end up being a full-on technical specification or an
applicability statement referencing existing work.

Adam

From: [email-masked] [[email-masked]] on behalf of
[email-masked] [[email-masked]]
Sent: Thursday, June 27, 2013 7:49 AM
To: [email-masked]; Adam Montville; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06:
(with BLOCK and COMMENT)

I would think that should be a part of the architecture document and if it
needed expanding then we could break it out later.

The Milestones are listed in the draft charter at
http://datatracker.ietf.org/wg/sacm/charter/

Kent Landfield

Web: www.mcafee.com

From: <Romascanu>, "Dan (Dan)" <[email-masked]>
Date: Thursday, June 27, 2013 4:40 PM
To: Adam Montville <[email-masked]>, Kathleen Moriarty <
[email-masked]>, Sean Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06:
(with BLOCK and COMMENT)

      From the operational perspective what I believe Benoit would like to
      see added is a deliverable that looks like:

      - A standards-track document specifying the informational model for
      endpoints data posture and its mapping into the protocol and data
      format for
      collecting actual endpoint posture

      We can argue that the information model can be part of the SACM
      architecture document.

      Do we need a data model deliverable now? Maybe this can be the object
      of a later charter. This phase being focused on defining the
      architecture (including information model), protocols and data
      formats (data modeling language) - a later phase or another WG can
      deal with the data models specific to the various functions.

      I would also observe that we did not define Milestones in the
      proposed charter. I am surprised that no AD raised a BLOCK about it.

      - Initial submission of SACM Architecture Internet-Draft - October
      2013
      - Initial submission of protocol and data format for retrieving
      configuration and policy information for driving data collection and
      analysis Internet-Draft - January 2014
      - Initial submission of protocol and data format for collecting
      endpoint posture Internet-Draft - January 2014
      - Submit SACM Architecture Internet-Draft to the IESG for
      consideration as Informational RFC - May 2014
      - Submit protocol and data format for retrieving configuration and
      policy information for driving data collection and analysis
      Internet-Draft to the IESG for consideration as Proposed Standard -
      September 2014
      - Submit protocol and data format for collecting endpoint posture
      Internet-Draft to the IESG for consideration as Proposed Standard -
      September 2014

      Dan

            -----Original Message-----
            From: [email-masked] [mailto:[email-masked]] On
            Behalf Of
            Adam Montville
            Sent: Thursday, June 27, 2013 5:16 PM
            To: Moriarty, Kathleen; Sean Turner
            Cc: [email-masked]
            Subject: Re: [sacm] Fwd: Benoit Claise's Block on
            charter-ietf-sacm-00-
            06: (with BLOCK and COMMENT)
            Agree.
            This domain is problematic in describing scope for the reasons
            I have
            previously mentioned - assessing posture (a security use case)
            is
            something that undoubtedly touches a lot of other related areas
            and
            efforts.  As Kathleen points out, reuse is a key to managing
            scope.
            Adam
            ________________________________________
            From: [email-masked] [[email-masked]] on behalf
            of
            Moriarty, Kathleen [[email-masked]]
            Sent: Thursday, June 27, 2013 7:04 AM
            To: Sean Turner
            Cc: [email-masked]
            Subject: Re: [sacm] Fwd: Benoit Claise's Block on
            charter-ietf-sacm-00-
            06: (with BLOCK and COMMENT)
            Hi Sean,
            The second one could be changed to repository access protocol
            and you
            can list a RESTful interface as an example.
            For the first, reuse will make the scope possible.  There is no
            intention of reinventing the wheel, but rather to provide
            uniform ways
            to perform these functions where we may need to create mappings
            or
            relationships between existing methods.  In some cases, we may
            need to
            select from proposed methods, improve or combine them.
            Thanks,
            Kathleen
            Sent from my iPhone
            On Jun 27, 2013, at 9:34 AM, "Sean Turner" <[email-masked]>
            vulnerabilities.
            _______________________________________________
            sacm mailing list
            [email-masked]
            https://www.ietf.org/mailman/listinfo/sacm
            ...
            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.
            _______________________________________________
            sacm mailing list
            [email-masked]
            https://www.ietf.org/mailman/listinfo/sacm
      _______________________________________________
      sacm mailing list
      [email-masked]
      https://www.ietf.org/mailman/listinfo/sacm

...

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.
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Jun 2013 12:11:52 -0400

We're all thinking the same thing because that's what I suggested his 
counter point was that the information will grow while the architecture 
draft ought to remain fixed.  I can see it go either way.  I'll see if 
he'll buy off on Dan's proposal.  We can always merge or split drafts later.

As to the milestones I like to make 'em think, but I'll add your 
suggestions ;)

spt

On 6/27/13 11:20 AM, Adam Montville wrote:
> This seems to be the real issue.  We could wait and break it out later
> (I assume "it" is the data model information), but then it looks like we
> don't really know what we're going to deliver because we don't have it
> explicitly listed.
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> *Sent:* Thursday, June 27, 2013 7:49 AM
> *To:* [email-masked]; Adam Montville; [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [sacm] Fwd: Benoit Claise's Block on
> I would think that should be a part of the architecture document and if
> it needed expanding then we could break it out later.
>
> *Kent Landfield*
> *McAfee | An Intel Company*
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> To: Adam Montville <[email-masked]
> <mailto:[email-masked]>>, Kathleen Moriarty
> <[email-masked] <mailto:[email-masked]>>, Sean
> Turner <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>      From the operational perspective what I believe Benoit would like
>     to see added is a deliverable that looks like:
>
>     Do we need a data model deliverable now? Maybe this can be the
>     object of a later charter. This phase being focused on defining the
>         From: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]] On Behalf Of
>         Adam Montville
>         Cc: [email-masked] <mailto:[email-masked]>
>         From: [email-masked] <mailto:[email-masked]>
>         [[email-masked] <mailto:[email-masked]>] on behalf of
>         Cc: [email-masked] <mailto:[email-masked]>
>         > From: Benoit Claise <[email-masked] <mailto:[email-masked]>>
>         > To: The IESG <[email-masked] <mailto:[email-masked]>>
>         >
>         >[email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Jun 2013 12:16:03 -0400

I love the instant gratification of jabber.  Benoit's point was the 
mapping should be in the DM so if we simply went to:

A standards-track document specifying the informational model for 
endpoints data posture

he'd be happy

spt

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 27 Jun 2013 12:16:18 -0400

Hi,

I have found it difficult to suss out just what this WG plans to standardize
for information.
"Security automation" covers a huge scope, and despite pressing for more
details, including to document in the use-cases document, I have been unable
to get much of anything that better scopes the information involved.
In my requests for use cases, I keep getting emails that say "you should
look at the work being done in <pick their favorite> organization."
Few have actually contributed proposals for IETF consideration, or provided
details useable for use cases.

The information model is a major area of discussion yet to be discussed, and
it could be contentious.
I think the information model should be a separate document from the
architecture.
That helps keep each effort manageable.

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 27 Jun 2013 16:19:07 +0000

Yes, this would be an advantage - plus it would allow an evolution of the IM that is not tied into the architecture document. 

Regards,

Dan

> From: ietfdbh [mailto:[email-masked]]
> Sent: Thursday, June 27, 2013 7:16 PM
> To: Romascanu, Dan (Dan); 'Adam Montville'; 'Moriarty, Kathleen'; 'Sean
> Turner'
> Cc: [email-masked]
> I have found it difficult to suss out just what this WG plans to
> standardize for information.
> details, including to document in the use-cases document, I have been
> unable to get much of anything that better scopes the information
> involved.
> Few have actually contributed proposals for IETF consideration, or
> provided details useable for use cases.
> 
> The information model is a major area of discussion yet to be discussed,
> and it could be contentious.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 27 Jun 2013 12:37:44 -0400

Hi,

As for a use case and how the work is scoped down, here is an example.

Currently, security teams need to follow hardening guides and lock down system and applications on each system (or device), an image of that system, or through a vendor provided management system specific to that vendor.  The compliance and audit teams have to assess those controls, often through some manual tasks on a regular basis for all different regulations or just reporting cycles.

We would like a uniform method to set, monitor and enforce security controls across platforms and vendors.  The regulatory controls and high-level control frameworks have already been defined.  We also have guidance on what needs to be locked down on systems to meet a desired assurance level.  We have methods to configure devices (numerous ones).  We need a common way to map between these existing protocols with a common language to enable consistent monitoring and management.  We need to aggregate this data and assess the overall security state of a system as well as the network.  That's where the protocols come in to play for repositories, etc.  if we can provide the consistent capability, then vendors and security professionals can help with the per-product mappings to get us away from the manual hardening, assessment and reporting.  

I am sure there are other use cases, but thought this might be a helpful explanation.

Thanks,
Kathleen 

Sent from my iPhone

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 27 Jun 2013 12:58:03 -0400

> > management AD and management is the proposed wg's name.

Why is this work not being proposed in the OPS/NM Area, which typically is
responsible for management protocols and management data modeling languages,
to execute on the operational requirements identified by operators? Aren't
they likely to have the best expertise on the existing standard management
protocols and DMLs available, as well as expertise on existing data models?
That area, with the NMRG and IAB, has done extensive work understanding user
(operator) requirements relevant to this work, such as RFC3198 Terminology
for Policy-based Management, RFC3535 Overview of the 2002 IAB Network
Management Workshop, RFC3444 On the Difference between Information Models
and Data Models, multiple management-related information models, and of
course lots of data models. 

Importantly, OPS/NM also has pretty extensive knowledge of what has and has
not worked in the past regarding IETF standard management protocols and
DMLs, especially policy-driven management.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 27 Jun 2013 13:08:55 -0400

Wherever it winds up is fine with me.  Please remember that the group bringing the work in also has experience and 50 implementations of some of the proposed work.  They do want to benefit from the experience of various groups in the IETF.

Thank you,
Kathleen 

Sent from my iPhone

---

From: Sean Turner <[email-masked]>
Date: Fri, 28 Jun 2013 00:19:14 -0400

I cut the wrong text in.  Benoit pointed this out and I've pasted the 
right version in.

spt

On 6/27/13 11:55 AM, Romascanu, Dan (Dan) wrote:
> Just to make sure that we have the same understanding about the
> differentiation made between information model and data model – Benoit
> is using the terminology defined by
> http://www.rfc-editor.org/rfc/rfc3444.txt
>
> Regards,
>
> Dan
>
> *From:*Adam Montville [mailto:[email-masked]]
> *Sent:* Thursday, June 27, 2013 6:20 PM
> *To:* [email-masked]; Romascanu, Dan (Dan);
> [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [sacm] Fwd: Benoit Claise's Block on
> *From:[email-masked] <mailto:[email-masked]>
> [[email-masked]] on behalf of [email-masked]
> <mailto:[email-masked]> [[email-masked]]
> *To:* [email-masked] <mailto:[email-masked]>; Adam Montville;
> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *From: *<Romascanu>, "Dan (Dan)" <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Thursday, June 27, 2013 4:40 PM
> *To: *Adam Montville <[email-masked]
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Subject: *Re: [sacm] Fwd: Benoit Claise's Block on

---

From: Sean Turner <[email-masked]>
Date: Fri, 28 Jun 2013 00:25:10 -0400

Dave,

I've done some editing 
(https://datatracker.ietf.org/doc/charter-ietf-sacm/) and based on 
Benoit's input the informational model is in fact a separate draft.  I 
have not included a submit to the IESG date because I'm not sure when 
that might be but I'm hoping that an initial draft in Nov is too ambitious.

spt