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

[Adam Montville <[e-mail]>]

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]> 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?

> 
>> 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.