Re: [sacm] Review on draft-ietf-sacm-ecp-02

["Haynes Jr., Dan" <[e-mail]>]

Hi Adam,

Even more comments inline :).

Thanks,

Danny

From: Adam Montville <[e-mail]>
Sent: Wednesday, September 05, 2018 11:38 PM
To: Haynes Jr., Dan <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [sacm] Review on draft-ietf-sacm-ecp-02

Thanks, Danny. I snipped a bunch of the original content to save space. See inline.


On Sep 5, 2018, at 3:53 PM, Haynes Jr., Dan <[e-mail]<mailto:[e-mail]>> wrote:


  *   Section 5: When is the target endpoint told what attributes matter and their tolerance ranges?
[Danny]: Wouldn’t it be determined by the data models that are called out in the EPCP Implementations section?

That seems like an inference :-) To me, it's better to explain that, but mine is just one opinion.

[Danny]: I think it would be covered in the "provisioning" section in EPCP Transactions. In -03, I updated the "NOTE: TO BE EXPANDED" to say the following.

"An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components necessary to interact with the posture manager. Examples of such identifiers include MAC addresses, serial numbers, hardware certificates compliant with [IEEE-802-1ar], and the identities of hardware cryptographic modules among others. Furthermore, in some cases, an endpoint may need to be provisioned with instantiations of data models if the posture collection engine is expecting posture information in that format. Once provisioning is complete, the endpoint is deployed on the network."

Does this help make it clearer? Or, if not, is there any text that you would like to see?

At first blush this seems helpful. What if the attributes of interest change over time? Not sure they will, or even should. But, the more likely scenario is when a new attribute is introduced. At that point, how do we tell the endpoint we're interested in monitoring that new attribute?

[Danny]: I think those are both possible situations that we want to account for. If there is a Posture Collector on the endpoint that can collect the attributes, it just needs to be configured via the Administrative Interface or API. If there isn’t a Posture Collector on the endpoint that can collect the attributes, a new Posture Collector needs to be installed on the endpoint and then configured by the Administrative Interface or API. We can add some text to this section stating that components and data models may need to be added or updated over time to fulfill the collection needs of the enterprise. Maybe something like the following.

"An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components and data models necessary to interact with the posture manager. Examples of such identifiers include MAC addresses, serial numbers, hardware certificates compliant with [IEEE-802-1ar], and the identities of hardware cryptographic modules among others. Once provisioning is complete, the endpoint is deployed on the network. Over time, components and data models may need to be added to the endpoint or updated to support the collection needs of an enterprise."


  *   Section 5.1: NOTE: TO BE EXPANDED before WGLC?
[Danny]: Yes, we will update this in the next draft.

  *   Section 5.6: It feels odd to allow authorized repo access w/o specifying an interface. That said…may have a good idea for such a draft down the road a place.
[Danny]: Given that we don’t actually have a protocol or interface for this, I think it’s more of a note of what we want when we develop one. So, I think we are in agreement here?

Seems that way.

  *   Section 6.2.4: Why not support fetch/polling via NETCONF and RESTCONF now?
[Danny]: This should be supported through NETCONF and RESTCONF now. This text is just trying to say that we also want to support the self-reporting capabilities provided by Yang Push once it’s an RFC.

Ok. Is it worthwhile to also state NETCONF/RESTCONF?

[Danny]: Section 6.2 contains normative references to NETCONF/RESTCONF. Are you looking for something more?

Sorry. This is my oversight, I think. Seems sane.


  *   Section 6.3: Change “Update the policy…” to “Establish and update the policy…”
[Danny]: Addressed.

  *   Section 6.3: Why shouldn’t the API offer commands and policy interaction?
[Danny]: Are you asking why the API shouldn’t offer endpoints the ability to issue commands and policy interactions?

No. The API is enabling query, but no proactive tasks. How are policies managed? Seems that the API should enable that as well.

[Danny]: I think I am confused. Doesn't the API already support managing the policy  in section 6.3 (i.e., establish and update the policy)?

I'm probably the one who is confused. :-) The way I read that section is that it addresses two means of interaction: 1) administrative interface, 2) API. I took the first three bullets as applicable to the administrative interface, and the solitary bullet as applicable to the API. If all of the bullets are applied to each, then I think the section could be rearranged to combine the two bulleted lists and state something to the effect that the list applies to both the administrative interface and the API.

[Danny]: Sorry my bad. I read it wrong. I don’t see anything wrong with the interface and API supporting the same capabilities especially since it isn’t defined yet :). I will update the text to make them both support the same capabilities.