sacm
commented
8 years ago 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 ietfdbh@comcast.net
On Nov 4, 2015, at 2:25 AM, david-waltermire-nist notifications@github.com 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 sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm
david-waltermire
nacho319
adammontville
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.