Clarify the potential use of existing transport protocols for collection as part of the SACM Architecture

[david-waltermire]

In Section 4 the text states that:

"Those interfaces are outside the scope of SACM."

This text is concerning for a number of reasons:

1. It is not clear which interfaces this text is referencing.
2. IMHO, adapting the referenced protocols to exchange SACM information and to integrate with control plane functions is within the scope of SACM.
3. The architecture draft should not be defining what the scope of SACM is. This should fall to the SACM charter.

To address this concern, I'd like to suggest the following changes:

Old:

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. Those interfaces are outside the scope of SACM.

New:

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. If any such protocol is adopted by SACM, additional
specification will be required to describe how the protocol will
support the exchange of SACM assessment information. Furthermore, it
will be necessary to define how such a protocol integrates with or
provides specific control and/or data plane functions defined by
this architecture.

[sacm]

Hi,

SACM is a temporary entity. I recommend it not be mentioned in an RFC (a cast-in-stone entity).

It might be helpful to discuss the (transfer) protocols separately from the data models.
It is common that a given type of data model is used with a given protocol.
However, it has been a design recommendation to make it possible for data models to be reused with different transfer protocols.

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. Proposals for use of such protocols should define how such a protocol integrates with or
provides specific control and/or data plane functions defined by
this architecture. Specification of information models and/or data models will be required to describe how the protocol will
support the exchange of SACM assessment information.

David Harrington
[email protected]

On Nov 4, 2015, at 2:25 AM, david-waltermire-nist [email protected] wrote:

In Section 4 the text states that:

"Those interfaces are outside the scope of SACM."

This text is concerning for a number of reasons:

1. It is not clear which interfaces this text is referencing.
2. IMHO, adapting the referenced protocols to exchange SACM information and to integrate with control plane functions is within the scope of SACM.
3. The architecture draft should not be defining what the scope of SACM is. This should fall to the SACM charter.

To address this concern, I'd like to suggest the following changes:

Old:

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. Those interfaces are outside the scope of SACM.

New:

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. If any such protocol is adopted by SACM, additional
specification will be required to describe how the protocol will
support the exchange of SACM assessment information. Furthermore, it
will be necessary to define how such a protocol integrates with or
provides specific control and/or data plane functions defined by
this architecture.

—
Reply to this email directly or view it on GitHub.

---

sacm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sacm

[david-waltermire]

Good points. I like your updated text.

Thanks,
Dave

-------- Original Message --------
From: sacm [email protected]
Date: Wed, November 04, 2015 8:57 PM +0900
To: sacmwg/draft-ietf-sacm-architecture [email protected]
CC: "Waltermire, David A." [email protected]
Subject: Re: [draft-ietf-sacm-architecture] Clarify the potential use of existing transport protocols for collection as part of the SACM Architecture (#46)

Hi,

SACM is a temporary entity. I recommend it not be mentioned in an RFC (a cast-in-stone entity).

It might be helpful to discuss the (transfer) protocols separately from the data models.
It is common that a given type of data model is used with a given protocol.
However, it has been a design recommendation to make it possible for data models to be reused with different transfer protocols.

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. Proposals for use of such protocols should define how such a protocol integrates with or
provides specific control and/or data plane functions defined by
this architecture. Specification of information models and/or data models will be required to describe how the protocol will
support the exchange of SACM assessment information.

David Harrington
[email protected]

On Nov 4, 2015, at 2:25 AM, david-waltermire-nist [email protected] wrote:

In Section 4 the text states that:

"Those interfaces are outside the scope of SACM."

This text is concerning for a number of reasons:

1. It is not clear which interfaces this text is referencing.
2. IMHO, adapting the referenced protocols to exchange SACM information and to integrate with control plane functions is within the scope of SACM.
3. The architecture draft should not be defining what the scope of SACM is. This should fall to the SACM charter.

To address this concern, I'd like to suggest the following changes:

Old:

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. Those interfaces are outside the scope of SACM.

New:

A variety of protocols, such as SNMP, NETCONF, NEA protocols
[RFC5209], and other similar interfaces, may be used for collection
of data from the target endpoints by the Posture Information
Provider. If any such protocol is adopted by SACM, additional
specification will be required to describe how the protocol will
support the exchange of SACM assessment information. Furthermore, it
will be necessary to define how such a protocol integrates with or
provides specific control and/or data plane functions defined by
this architecture.

Reply to this email directly or view it on GitHub.

---

sacm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sacm

Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-153698630.

[nacho319]

Would there be a mandatory to implement protocol?

[adammontville]

@nacho319 Your question feels loaded... Do you have an opinion?

[sacm]

I don’t think I really have a horse in the race on this, but I’ve heard various folks voice the strong opinion that there would have to be a mandatory to implement protocol for compatibility.

Maybe if I create a protocol then I can pick it. :)

Chris Inacio
[email protected]

On Nov 13, 2015, at 5:13 PM, adammontville [email protected] wrote:

@nacho319 Your question feels loaded... Do you have an opinion?

—
Reply to this email directly or view it on GitHub.

---

sacm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sacm

[sacm]

I believe we need MTIs to be defined for interoperability. What isn't clear to me at this time is if we can have one MTI to "rule them all" or if we need different MTIs to address different types of devices (e.g., network infrastructure, mobile, desktop, server, etc.). I believe this should be a topic for discussion as we work to complete the architecture.

Dave

-----Original Message-----
From: sacm [mailto:[email protected]] On Behalf Of Chris Inacio
Sent: Sunday, November 15, 2015 8:11 PM
To: sacmwg/draft-ietf-sacm-architecture [email protected]
Cc: sacm [email protected]; sacmwg/draft-ietf-sacm-architecture [email protected]
Subject: Re: [sacm] [draft-ietf-sacm-architecture] Clarify the potential use of existing transport protocols for collection as part of the SACM Architecture (#46)

I don’t think I really have a horse in the race on this, but I’ve heard various folks voice the strong opinion that there would have to be a mandatory to implement protocol for compatibility.

Maybe if I create a protocol then I can pick it. :)

Chris Inacio
[email protected]

On Nov 13, 2015, at 5:13 PM, adammontville [email protected] wrote:

@nacho319 Your question feels loaded... Do you have an opinion?

—
Reply to this email directly or view it on GitHub.

---

sacm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sacm

---

sacm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sacm