Subject: [sacm] FW: [Netconf] [netmod] development plan

From: "Baker, Jon" <[email-masked]>
Date: Tue, 6 Aug 2013 17:33:07 +0000

How closely are SACM WG participants also following the ongoing netconf discussion?

This message seems to directly align with some of the work I have expected SACM to do. Take a look at this quote in particular:

>  A configuration datastore is defined as the complete set of configuration data
>that
>    is required to get a device from its initial default state into a
>    desired operational state.  The configuration datastore does not
>    include state data or executive commands.
>
>    The running configuration datastore holds the complete configuration
>    currently active on the network device.  Only one configuration
>    datastore of this type exists on the device, and it is always
>    present.

Given that the netconf wg seems to be in the middle of a very active discussion on very closely related topics I would suggest that we specifically reach out to the netconf group to ensure alignment and reuse where possible. 

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [email-masked]

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Balazs Lengyel
>Sent: Tuesday, August 06, 2013 5:47 AM
>To: Ladislav Lhotka
>Cc: [email-masked]; Netconf
>Subject: Re: [Netconf] [netmod] development plan
>
>
>On 2013-08-05 19:45, Ladislav Lhotka wrote:
>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel <[email-masked]>
>wrote:
>>
>>> On 2013-08-05 16:03, Ladislav Lhotka wrote:
>>>> It is a fact of life that YANG is being used outside NETCONF, and there are
>more plans for doing do, but with 6020 it is a slippery slope. For example,
>such non-NETCONF applications of YANG will most likely want to use "must"
>for expressing semantic constraints. However, the accessible tree for "must" is
>defined like so:
>>>>
>>>>     o  If the context node represents configuration, the tree is the data
>>>>        in the NETCONF datastore where the context node exists.  The XPath
>>>>        root node has all top-level configuration data nodes in all
>>>>        modules as children.
>>>>
>>>>     o  If the context node represents state data, the tree is all state
>>>>        data on the device, and the <running/> datastore.  The XPath root
>>>>        node has all top-level data nodes in all modules as children.
>>>>
>>>> This cannot be unambiguously interpreted in a non-NETCONF context, so
>it is effectively undefined, which is rather dangerous.
>>>> So I don't mean to completely redesign YANG, but we cannot, on the
>other hand, enable non-NETCONF YANG data modelling without providing
>new definitions.
>>>>
>>>> Lada
>>> In my view Netconf contains the "pure" protocol (encoding, operations,
>transactional behavior...) and background plumbing (datastores, separation of
>state and config data, hierarchical data organisation, filtering, connection
>requirements, session concept, capability negotiation, many of the capabilites,
>error messages).
>>> The background plumbing is valid for all access methods (CLI, Netconf,
>YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined.
>> I don't think this is true. I2RS will probably have no distinction between
>config and state data, though they may have read-write and read-only.
>Sessions and capability negotiation are by no means necessary (RESTCONF
>doesn't have it). I can actually imagine data modelling without any specific
>protocol for data exchange.
>>
>> Lada
>IMHO we can debate whether some protocols need some of the features, or
>whether some of the features belong to the plumbing or the pure
>protocol, but I still believe that many of the concepts like "NETCONF
>datastore" above are actually easily understandable without considering
>the protocol on the wire. If you would just remove the word Netconf from
>your example paragraphs IMHO they are quite understandable in a protocol
>independent way.
>
>Let me just try as an exercise:
>Running Datastore:
>
>  A configuration datastore is defined as the complete set of configuration data
>that
>    is required to get a device from its initial default state into a
>    desired operational state.  The configuration datastore does not
>    include state data or executive commands.
>
>    The running configuration datastore holds the complete configuration
>    currently active on the network device.  Only one configuration
>    datastore of this type exists on the device, and it is always
>    present.
>
>The above defeinition is extracted from RFC6241 (I just removed 2
>sentences). I think it is a very nice protocol independent definition.
>
>
>Does anyone have a list of features that make YANG protocol (Netconf)
>dependent?
>
>Balazs
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Adam Montville <[email-masked]>
Date: Tue, 6 Aug 2013 17:52:43 +0000

Thanks for pointing this out, Jon.

Is anyone on this list also working in netconf?  On the surface, they look very similar.  It would be interesting to understand where, from an architectural perspective, the datastore is said to reside for netconf and how it should be accessed.  I also find the phrase about not storing executive commands interesting, because, presumably, some of the information we want to store will be instructional in nature.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Baker, Jon
> Sent: Tuesday, August 06, 2013 10:34 AM
> To: [email-masked]
> Subject: [sacm] FW: [Netconf] [netmod] development plan
> 
> This message seems to directly align with some of the work I have expected
> SACM to do. Take a look at this quote in particular:
> 
> >  A configuration datastore is defined as the complete set of
> >configuration data that
> Given that the netconf wg seems to be in the middle of a very active
> discussion on very closely related topics I would suggest that we specifically
> reach out to the netconf group to ensure alignment and reuse where
> possible.
> 
> Jon
> 
> >From: [email-masked] [mailto:[email-masked]] On
> >Behalf Of Balazs Lengyel
> >more plans for doing do, but with 6020 it is a slippery slope. For
> >example, such non-NETCONF applications of YANG will most likely want to
> use "must"
> >for expressing semantic constraints. However, the accessible tree for
> >"must" is defined like so:
> >>>>
> >transactional behavior...) and background plumbing (datastores,
> >separation of state and config data, hierarchical data organisation,
> >filtering, connection requirements, session concept, capability
> >negotiation, many of the capabilites, error messages).
> >doesn't have it). I can actually imagine data modelling without any
> >specific protocol for data exchange.
> >>
> >> Lada
> >the protocol on the wire. If you would just remove the word Netconf
> >from your example paragraphs IMHO they are quite understandable in a
> >protocol independent way.
> >
> >  A configuration datastore is defined as the complete set of
> >configuration data that
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
> 
> ...

. . .

---

From: "Nunez, Luis K" <[email-masked]>
Date: Tue, 6 Aug 2013 18:47:16 +0000

A NETCONF enabled device (router/switch)  will publish configuration
information locally into the "datastore". The NETCONF protocol is also used
to access these devices for CRUD operations against this datastore.  From an
architectural perspective NETCONF would be used to Retrieve the
configuration state information for vulnerability compliance assessments.
Likewise NETCONF could also be used for Remediation.

The tread below is related to recent efforts on SDN within the I2RS working
group.  Software Defined Networking or some would say Security Defined
Networking will eventually cross paths with this working group at some
point.

-ln
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville
Sent: Tuesday, August 06, 2013 1:53 PM
To: Baker, Jon; [email-masked]
Subject: Re: [sacm] [Netconf] [netmod] development plan

Is anyone on this list also working in netconf?  On the surface, they look
very similar.  It would be interesting to understand where, from an
architectural perspective, the datastore is said to reside for netconf and
how it should be accessed.  I also find the phrase about not storing
executive commands interesting, because, presumably, some of the information
we want to store will be instructional in nature.

. . .

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 06 Aug 2013 17:19:01 -0400

> Is anyone on this list also working in netconf?  On the surface, they look very similar.  It would be interesting to understand where, from an architectural perspective, the datastore is said to re…

I am on netconf.  I agree with Luis' follow-up.  I viewed NETCONF as a
way to retrieve configuration data from the device as part of config
mgmt in SACM as well as push back changes such as remediations.  I never
saw overlap in terms of the two WGs trying to do the same thing.

I am reminded of David Harrington's talk about using SNMP to do the
asset collection.  NETCONF is another means to accomplish the same type
of collection for config (as well as retrieve some operational data that
may be helpful when identifying true posture).

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 7 Aug 2013 10:52:13 +0000

David Harrington is one of the active participants in Netconf. Bert Wijnen, one of the Netconf co-chairs, Andy Bierman one of the principal contributors attended the meeting in Berlin, but I do not see them subscribed to the mail list. There may be other, and we can bring them in the discussion or ask questions.

Netconf is mostly about configuring network devices, so the datastores Netconf relates to are typically local to the devices (routers, servers). 

Regards,

Dan

> Adam Montville
> Sent: Tuesday, August 06, 2013 8:53 PM
> Is anyone on this list also working in netconf?  On the surface, they
> look very similar.  It would be interesting to understand where, from an
> architectural perspective, the datastore is said to reside for netconf
> and how it should be accessed.  I also find the phrase about not storing
> executive commands interesting, because, presumably, some of the
> information we want to store will be instructional in nature.
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Baker, Jon
> > This message seems to directly align with some of the work I have
> > expected SACM to do. Take a look at this quote in particular:
> >
> > discussion on very closely related topics I would suggest that we
> > specifically reach out to the netconf group to ensure alignment and
> > reuse where possible.
> >
> > Jon
> >
> > >>>>        in the NETCONF datastore where the context node exists.
> > >>>> The
> > XPath
> > >Sessions and capability negotiation are by no means necessary
> > >(RESTCONF doesn't have it). I can actually imagine data modelling
> > >without any specific protocol for data exchange.
> > >>
> > >> Lada
> > >datastore" above are actually easily understandable without
> > >considering the protocol on the wire. If you would just remove the
> > >word Netconf from your example paragraphs IMHO they are quite
> > >understandable in a protocol independent way.
> > >

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 7 Aug 2013 11:51:11 +0000

I have been subscribed to the list and have been following NETMOD for almost a couple of years. While the current modeling work is focused on network devices, there is little that prevents this approach from being used by other endpoint device types.  NETCONF/NETMOD addresses 3 types of configurations, the current running configuration, the persisted boot configuration, and an intermediate configuration that is used to build new configurations that have not been applied. At the last NETMOD WG meeting there was quite a bit of discussion around decoupling NETMOD from NETCONF to make it more generally useful to other efforts in the IETF. Both Adam and I were at the last NETMOD meeting and advertised the SACM WG meeting to get some attendance from the NETMOD community.

While no decision was made to decouple NETCONF and NETMOD yet, IMHO making use of NETMOD is something that we should consider as part of SACM. At minimum we could use it to retrieve configuration data from network devices and it could be extended to do more. Depending on the level of coupling, there may be some flexibility in transport (e.g., NETCONF, NEA). Considering how it could fit into the architectural discussion, it might be used by a type of NETCONF sensor/collector to remotely poll the device and to monitor notifications.  Another way of looking at it architecturally would be to use NETCONF/NETMOD as a mechanism to communicate with the device, with the NETMOD functionality serving as the sensor.

Thoughts?

Dave

> Romascanu, Dan (Dan)
> Sent: Wednesday, August 07, 2013 6:52 AM
> To: Adam Montville; Baker, Jon; [email-masked]
> David Harrington is one of the active participants in Netconf. Bert Wijnen,
> one of the Netconf co-chairs, Andy Bierman one of the principal contributors
> attended the meeting in Berlin, but I do not see them subscribed to the mail
> list. There may be other, and we can bring them in the discussion or ask
> questions.
> 
> Netconf is mostly about configuring network devices, so the datastores
> Netconf relates to are typically local to the devices (routers, servers).
> 
> Regards,
> 
> Dan
> 
> 
> 
> 
> > Of Adam Montville
> > look very similar.  It would be interesting to understand where, from
> > an architectural perspective, the datastore is said to reside for
> > netconf and how it should be accessed.  I also find the phrase about
> > not storing executive commands interesting, because, presumably, some
> > of the information we want to store will be instructional in nature.
> >
> >
> > > >for expressing semantic constraints. However, the accessible tree
> > > >for "must" is defined like so:
> > > >>>>
> > > >>>>     o  If the context node represents configuration, the tree
> > > >>>> is
> > the data
> > > >>>>     o  If the context node represents state data, the tree is
> > > >>>> all
> > state
> > > >other hand, enable non-NETCONF YANG data modelling without
> > > >providing new definitions.
> > > >>>>
> > > >>>> Lada
> > > >separation of state and config data, hierarchical data
> > > >organisation, filtering, connection requirements, session concept,
> > > >capability negotiation, many of the capabilites, error messages).
> > > >IMHO we can debate whether some protocols need some of the
> > > >features,
> > > or
> > > >protocol, but I still believe that many of the concepts like
> > > >"NETCONF datastore" above are actually easily understandable
> > > >without considering the protocol on the wire. If you would just
> > > >remove the word Netconf from your example paragraphs IMHO they
> are
> > > >quite understandable in a protocol independent way.
> > > >
> > > >Does anyone have a list of features that make YANG protocol
> > > >(Netconf) dependent?
> > > >
> > > >Balazs
> > > >

---

From: "Nunez, Luis K" <[email-masked]>
Date: Wed, 7 Aug 2013 14:25:53 +0000

On your last point "NETMOD functionality serving as the sensor".  I agree NETCONF could be used in other ways. For example RFC 6728 IPFIX/PSAMP Configuration Data Model includes NETCONF and Yang.  From a SACM architecture, NETCONF could be used to deploy IPFIX sensing definitions based on threat intelligence and observables (STIX/MILE).    As SACM evolves, these kinds of connections will emerge into use cases.

 -ln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Wednesday, August 07, 2013 7:51 AM
To: Romascanu, Dan (Dan); Adam Montville; Baker, Jon; [email-masked]
Subject: Re: [sacm] [Netconf] [netmod] development plan

Thoughts?

Dave

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 07 Aug 2013 16:45:59 -0400

I'm not all that familiar with NETCONF yet so I'm looking forward to 
learning more.

However, even if it's a great fit for SACM purposes, I would say that we 
should not adopt NETCONF or any other such collection standard 
(WBEM/WMI, SNMP, etc) as our single collection standard, even if for a 
subset of endpoint types.

If instead we focus on a way to communicate what items are to be 
collected from endpoints and return the collected items we shouldn't 
care about how the collection is performed.  That leaves things open 
enough to cover the widest possible range of endpoints including EOL 
legacy devices.

I'll also point out that as we've seen in using OVAL for collection it's 
not enough to simply send a list of items to collect -- there often 
needs to be logic chains where the value of one or more collected items 
determines what is to be collected for other items.  That's why SCAP 
uses OVAL for collection, so whatever SACM settles on needs to have at 
least that level of functionality.

--gun

---

From: David Harrington <[email-masked]>
Date: Thu, 08 Aug 2013 22:59:33 +0200

>enough to cover the widest possible range of endpoints including EOL

IETF works on standards.
If every device gets to use a different protocol for query operations, how
does that support interoperability?
Does an application doing evaluation need to be written to understand
different protocols for every device/model/OS in the network?

I agree that we shouldn't choose just one protocol, but I think we should
use standardized protocols and data models to promote vendor-neutral
interoperability.
--
David Harrington
[email-masked]
+1-603-828-1401

---

From: Adam Montville <[email-masked]>
Date: Thu, 8 Aug 2013 21:52:18 +0000

At this point, I wouldn't disagree with either perspective.  To be pedantic about it, the use cases should probably be at a level where we are not prescribing or presuming any particular protocol or data format.  

Requirements will then be able to describe use case needs in more detail, but still without prescribing or presuming particular protocols/formats - requirements are more likely to describe the characteristics such protocols/formats would need to possess.

Then, architectures would "take the plunge" into the details of which protocols and/or data formats would be viable to meet the requirements, and therefore the use cases.

We all have ideas about what an architecture might look like, and we are trying to do some things in parallel, but I think it's important to keep the delineation between use cases, requirements, and architecture as clean as we can.

Adam

> From: David Harrington [mailto:[email-masked]]
> Sent: Thursday, August 08, 2013 2:00 PM
> To: Gunnar Engelbach; Waltermire, David A.
> Cc: Romascanu, Dan (Dan); Adam Montville; [email-masked]; Baker, Jon
> >However, even if it's a great fit for SACM purposes, I would say that
> >we should not adopt NETCONF or any other such collection standard
> I agree that we shouldn't choose just one protocol, but I think we should use
> standardized protocols and data models to promote vendor-neutral
> interoperability.
> --
> David Harrington
> [email-masked]
> +1-603-828-1401
> 
> 
> >
> 
> 
> 
> ...

. . .

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 8 Aug 2013 22:23:10 +0000

+1. This is consistent with my understanding of where we are in the process today.

I also don't disagree with either perspective. A solid architectural approach will allow for some flexibility in standards used to collect data from endpoints. We may find that multiple are needed to get adequate coverage. We may decide that one approach should be mandatory-to-implement to encourage interoperability. However, it's too early to make a decision on any of this.

However, it does feel like there are some requirements buried in this discussion. ;-) Perhaps we can focus on that view of the problem?

Dave

> From: Adam Montville [mailto:[email-masked]]
> Sent: Thursday, August 08, 2013 5:52 PM
> To: David Harrington; Gunnar Engelbach; Waltermire, David A.
> Cc: Romascanu, Dan (Dan); [email-masked]; Baker, Jon
> Subject: RE: [sacm] [Netconf] [netmod] development plan
> 
> At this point, I wouldn't disagree with either perspective.  To be pedantic
> about it, the use cases should probably be at a level where we are not
> prescribing or presuming any particular protocol or data format.
> 
> Requirements will then be able to describe use case needs in more detail,
> but still without prescribing or presuming particular protocols/formats -
> requirements are more likely to describe the characteristics such
> protocols/formats would need to possess.
> 
> Then, architectures would "take the plunge" into the details of which
> protocols and/or data formats would be viable to meet the requirements,
> and therefore the use cases.
> 
> We all have ideas about what an architecture might look like, and we are
> trying to do some things in parallel, but I think it's important to keep the
> delineation between use cases, requirements, and architecture as clean as
> we can.
> 
> Adam
> 
> > >(WBEM/WMI, SNMP, etc) as our single collection standard, even if for
> > >a subset of endpoint types.
> > >
> > If every device gets to use a different protocol for query operations,
> > how does that support interoperability?
> > I agree that we shouldn't choose just one protocol, but I think we
> > should use standardized protocols and data models to promote
> > vendor-neutral interoperability.
> > --
> > David Harrington
> > [email-masked]
> > +1-603-828-1401
> >
> >
> > >
> >
> >
> >
> > ...
> 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: Gunnar Engelbach <[email-masked]>
Date: Thu, 08 Aug 2013 18:44:30 -0400

This approach makes sense, Adam, and this conversation is a bit further 
down in the process, but nonetheless I'd like to respond to David and 
see how that jives with the group.

Reasons to not require the use of a specific collection methodology:

1) It's a recognition of a practical necessity:  NETCONF is not going to 
be universally usable.  Nor is SNMP, WBEM, or any other technology.  In 
a heterogeneous environment it will be necessary to use a combination of 
these to do the actual collection in order to achieve full coverage, 
especially considering the number of legacy and embedded devices for 
which adding software is impractical.

2) It muddies things a bit that NETCONF, WBEM, SNMP, etc, are also 
network protocols, but the actual artifact collection will frequently 
*not* be done over the network.  It will be done with database queries, 
using local APIs, parsing backed up configuration files, terminal 
command over an RS-232 cable, etc.  The initiator for collection of an 
endpoint may be a network message, but fulfillment can be anything, 
including another network protocol.

3) As I mentioned it's not enough to simply give a list of artifacts 
that need to be collected.  It will also be necessary to do multi-step 
collections where initial collected values are applied via logic rules 
to complete the collection process.  Is the NETCONF group, or any other, 
going to be willing to perturb their work to this degree?

4) For the collection process we are interested in the ability to 
dispatch a document that details all artifacts necessary to complete an 
automated security task, and the response to that request*.  Those two 
documents are the standards that I am interested in:  how that 
collection actually happens I don't care about.  So if the receiving end 
translates that into NETCONF to fulfill part/all of it, or makes WMI 
queries, I don't care, just as I don't care if that receiver is a local 
agent, a database, a proxy for multiple devices, or a relay, except that 
I would also like to receive some information about the collection 
process that can be used to determine timeliness, and accuracy of the 
response.

* Yeah, this statement is a bit presumptive.  Anybody see things 
differently?

On 8/8/2013 5:52 PM, Adam Montville wrote:
> 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: Gunnar Engelbach <[email-masked]>
Date: Thu, 08 Aug 2013 18:54:03 -0400

> I also don't disagree with either perspective. A solid architectural approach will allow for some flexibility in standards used to collect data from endpoints. We may find that multiple are needed…

I think that interoperability will be achieved by implementing data 
interchanges at the level above physical collection -- allowing 
implementers to create SACM-compliant front-ends to existing collection 
methods.  But I'm not sure I made that very clear in my previous response.

> However, it does feel like there are some requirements buried in this discussion. ;-) Perhaps we can focus on that view of the problem?

Any requirements pop out at you?

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 8 Aug 2013 23:51:32 +0000

Gunnar,

While I realize that in today's world there are many
protocols for obtaining information on endpoint posture
and I agree that we'll need to support those, I also
believe that we (the IETF) can and should nudge people
toward one or a small number of protocols that endpoints
should support.

Legacy devices won't change and there will always be
some recalcitrant devices that refuse to supply posture
information and databases of historical data have utility
and there's more to security than endpoint posture and...
but I don't really see any reason why most if not all
endpoints couldn't support one simple set of protocols
and data formats for direct endpoint posture collection.

Thanks,

Steve

> Gunnar Engelbach
> Sent: Thursday, August 08, 2013 6:44 PM
> To: Adam Montville
> Cc: Romascanu, Dan (Dan); David Harrington; Waltermire, David A.;
> Baker, Jon; [email-masked]
> > At this point, I wouldn't disagree with either perspective.  To be
> pedantic about it, the use cases should probably be at a level where we
> are not prescribing or presuming any particular protocol or data
> format.
> >
> > Requirements will then be able to describe use case needs in more
> detail, but still without prescribing or presuming particular
> protocols/formats - requirements are more likely to describe the
> characteristics such protocols/formats would need to possess.
> >
> > We all have ideas about what an architecture might look like, and we
> are trying to do some things in parallel, but I think it's important to
> keep the delineation between use cases, requirements, and architecture
> as clean as we can.
> >
> > Adam
> >
> should use
> > 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: David Harrington <[email-masked]>
Date: Fri, 09 Aug 2013 09:13:26 +0200

First if our discussion is about using multiple protocols, let's change
the subject line from "[sacm] [Netconf] [netmod]  development plan" to
demonstrate that we are not trying to tie sacm/netconf/netmod togther.

I considered changing this to use text from Gunnar's message, such as
"collection methodologies".
But that subject line doesn't reflect for which document we are having
this discussion.

Gunnar, do you consider this a use cases discussion? A requirements
discussion? An architecture discussion?
Maybe we should use "use cases" or "requirements" or "architecture" or
"terminology" in the subject line where ossible

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

On 8/9/13 12:44 AM, "Gunnar Engelbach" <[email-masked]>
wrote:

>>are not prescribing or presuming any particular protocol or data format.
>>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 9 Aug 2013 10:24:36 +0200

Hello,

analogously to the discussion in the meeting, I think that providing a 
recommendation/guideline regarding meta-data acquisition processes 
really helps. At least to better highlight context and purpose.

Maybe, describing/defining categories for potential sources of 
information (from DBs, over real-time services, to automated discovery), 
for types of administrative domain (from well known IT-systems that 
support business processes, to unknown BYOD handhelds), or for 
acquisition methods (via agent or agent-less, via polling or pushing, or 
even recommended characteristics of specific protocols in certain 
environments), can result in better quality of aggregated meta-data - 
overall?

Best,

Henk

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 9 Aug 2013 13:49:50 +0000

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Thursday, August 08, 2013 6:45 PM
> To: Adam Montville
> Cc: David Harrington; Waltermire, David A.; Romascanu, Dan (Dan);
> [email-masked]; Baker, Jon
> 3) As I mentioned it's not enough to simply give a list of artifacts that need to
> be collected.  It will also be necessary to do multi-step collections where
> initial collected values are applied via logic rules to complete the collection
> process.  Is the NETCONF group, or any other, going to be willing to perturb
> their work to this degree?

I don't see how this would perturb the underlying transport in any way. If collection of a subset of posture is allowed, wouldn't this simply be handled (regardless of transport) using multiple requests for posture?

Dave

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 9 Aug 2013 13:57:00 +0000

> Sent: Thursday, August 08, 2013 6:54 PM
> To: Waltermire, David A.
> Cc: Adam Montville; David Harrington; Romascanu, Dan (Dan);

Here are a few potential requirements extracted from the discussion thread:

- We SHOULD achieve complete/adequate coverage of all endpoint device types.
- We MUST identify (select existing, design new as needed) one or a small number of transports for use in exchanging endpoint posture with a focus on maximizing interoperability.
  - Transports MUST support client (endpoint) initiation of the exchange.
  - Transports MUST support server initiation of exchange, including requests for a subset of posture.
  - Transports SHOULD support multiple data representations, allowing for multiple posture information types.
- If multiple transports are used, there MUST be a method to consolidate data collected from each into a cohesive data set.
- Posture collection MUST be allowed to be performed remotely and locally relative to the endpoint.
- Exchanged metadata information associated with a posture exchange SHOULD include information about the collection process that can be used to determine timeliness, and accuracy of the response.

Comments?

Dave

---

From: Eric Walker <[email-masked]>
Date: Fri, 9 Aug 2013 09:39:43 -0600

Hi,

I have been following the SACM threads only very lightly up to now due to competing commitments, but this one stood out -- my apologies in advance for not being more familiar with the preceding conversation.

It seems to me that we have headed well into architectural details at this point.  In this case, we're discussing a client-server architecture and the existence of a set of protocols that are to be used to communicate between client and server ("transports").  In a sense I feel fortunate, because what is being proposed is at a high level similar to the product that I currently work on.  But I'm also somewhat nervous, because if we're getting into this level of detail, there's a good chance that later on something could get rolled into the use cases or standard that would be at variance with what my product does and that we would have a hard time accommodating within the medium term.

Are people comfortable with this level of detail in the requirements -- agent, server, the existence of one or more transport protocols, etc.?  Is this level of detail required to fulfill the mission of this working group?  Perhaps it is, in which case existing products that do not have this architecture will have to adapt.  But I sort of feel like we're approaching the problem from the wrong direction -- we have a solution in mind, and next we'll get to the challenges that it will address.  This is fine on one level, because years of familiarity with the problem space may have given us a sufficient sense of what a viable solution would look like for us to be able to go about things this way.  But if I might propose sorting out the use cases first, without introducing details that would necessarily imply an agent-based architecture if such details can be omitted, that might be something that people would want to consider.  That way we would be working from customer value back to architecture, which will help to avoid over-engineering things.

If we are comfortable getting into this level of detail at this point, what about omitting the part about transport protocols and the need to support multiple ones?  Personally, I would like to avoid a standard that implies an architecture that is so general that it can do anything and everything.  Another possibility is to limit things to a single transport protocol (one based on JSON or a single XML schema, for example).

Eric

[email-masked] wrote: -----

To: Gunnar Engelbach <[email-masked]>
From: "Waltermire, David A."
Sent by: [email-masked]
Date: 08/09/2013 06:57AM
Cc: David Harrington <[email-masked]>, Adam Montville <[email-masked]>, "[email-masked]" <[email-masked]>, "Baker, Jon" <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>
Subject: Re: [sacm] [Netconf] [netmod] development plan

Comments?

Dave

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 09 Aug 2013 12:28:51 -0400

Adam laid out the steps in a traditional development process from use 
cases to requirements, and it sounds like there is general agreement on 
that as the approach.

However, I'm not against listing requirements now if we are aware of 
them.  We can always change/remove them later if the process 
necessitates that.  Use cases will help communicate the goals of the 
working group via examples, but I don't expect them to be complete 
enough to be able to derive all requirements from.

--gun

On 08/09/2013 11:39 AM, Eric Walker wrote:
> Hi,
>
> I have been following the SACM threads only very lightly up to now due 
> to competing commitments, but this one stood out -- my apologies in 
> advance for not being more familiar with the preceding conversation.
>
> It seems to me that we have headed well into architectural details at 
> this point.  In this case, we're discussing a client-server 
> architecture and the existence of a set of protocols that are to be 
> used to communicate between client and server ("transports").  In a 
> sense I feel fortunate, because what is being proposed is at a high 
> level similar to the product that I currently work on.  But I'm also 
> somewhat nervous, because if we're getting into this level of detail, 
> there's a good chance that later on something could get rolled into 
> the use cases or standard that would be at variance with what my 
> product does and that we would have a hard time accommodating within 
> the medium term.
>
> Are people comfortable with this level of detail in the requirements 
> -- agent, server, the existence of one or more transport protocols, 
> etc.?  Is this level of detail required to fulfill the mission of this 
> working group?  Perhaps it is, in which case existing products that do 
> not have this architecture will have to adapt.  But I sort of feel 
> like we're approaching the problem from the wrong direction -- we have 
> a solution in mind, and next we'll get to the challenges that it will 
> address.  This is fine on one level, because years of familiarity with 
> the problem space may have given us a sufficient sense of what a 
> viable solution would look like for us to be able to go about things 
> this way.  But if I might propose sorting out the use cases first, 
> without introducing details that would necessarily imply an 
> agent-based architecture if such details can be omitted, that might be 
> something that people would want to consider.  That way we would be 
> working from customer value back to architecture, which will help to 
> avoid over-engineering things.
>
> If we are comfortable getting into this level of detail at this point, 
> what about omitting the part about transport protocols and the need to 
> support multiple ones?  Personally, I would like to avoid a standard 
> that implies an architecture that is so general that it can do 
> anything and everything.  Another possibility is to limit things to a 
> single transport protocol (one based on JSON or a single XML schema, 
> for example).
>
> Eric
>
>
> Cc: David Harrington <[email-masked]>, Adam Montville 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "Baker, Jon" <[email-masked]>, "Romascanu, Dan \(Dan\)" 
> <[email-masked]>
> - We MUST identify (select existing, design new as needed) one or a 
> small number of transports for use in exchanging endpoint posture with 
> a focus on maximizing interoperability.
> - If multiple transports are used, there MUST be a method to 
> consolidate data collected from each into a cohesive data set.
> - Exchanged metadata information associated with a posture exchange 
> SHOULD include information about the collection process that can be 
> used to determine timeliness, and accuracy of the response.
>
> Comments?
>
> Dave

---

From: David Harrington <[email-masked]>
Date: Fri, 09 Aug 2013 21:57:14 +0200

Can we please change the subject thread from "Re: [sacm] [Netconf]
[netmod]  development plan"
I also subscribe to netmod and netconf lists, and there is discussion
going on there undet the same subject line (minus the [sacm])
It would be MUCH better for the editors to be able to find emails they
need to respond during editing if the subject line reflects the message
content.

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

On 8/9/13 3:57 PM, "Waltermire, David A." <[email-masked]>
wrote:

>- We MUST identify (select existing, design new as needed) one or a small
>number of transports for use in exchanging endpoint posture with a focus
>on maximizing interoperability.
>- If multiple transports are used, there MUST be a method to consolidate
>data collected from each into a cohesive data set.
>SHOULD include information about the collection process that can be used
>to determine timeliness, and accuracy of the response.
>
>Comments?
>
>Dave

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 09 Aug 2013 17:21:39 -0400

> - Exchanged metadata information associated with a posture exchange SHOULD include information about the collection process that can be used to determine timeliness, and accuracy of the response.

Yeah:  good list.  Hang on to it.