Hi, Fully agree with Susan here, especially when it comes to differentiating this from DOTS and Security Event concepts.
Some could see this related with attestation mechanisms because this monitoring implies an information flow about NSF status going from NSF to the SC, but there are key differences between both procedures. Basically, attestation is used to establish a level of trust on the NSF before it starts running, while monitoring has to deal with runtime conditions and not with the establishment of trust. A possible point of contact could be continuous attestation, but it should be considered a particular kind of monitoring performed by a (trusted) third party, and I would avoid complicating the monitoring definition with the necessary attestation considerations, though continuous attestation could share some of the information model once agreed. A couple of additional comments: 1) This draft (as many other) has to be reviewed once the terminology on interfaces becomes stable 2) Taking into account the reflection on information and data models made by Adrian and that I replied, I’d like to remark that the first sections of this document are the perfect example of the text that should be published, as an introduction to the data model or elsewhere, if we decide not to go for standalone information model publication. Be goode, On 13 Oct 2016, at 15:49 , Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>> wrote: Adrian: Why: Monitoring is a key component to I2NSF for monitoring NSF devices. Monitoring is not the same as NSF devices sending notifications - which is a push from the NSF devices. Monitoring may encompasses specific requests to the device. Monitoring is different than the DOTS - "help me" cry from a device under attack. While I see the security ADs are proposing Security event, it is important that the I2NSF create monitoring concepts that work with all of the functions (e.g. querying capabilities, sending/receiving notification, and events). Data model versus Information model: Since we do not seem to have a clear idea of what the data model should be, it is important to create the informational models. The content of the draft is a good first step. Sue Hares -----Original Message----- From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, October 11, 2016 5:22 PM To: i2nsf@ietf.org<mailto:i2nsf@ietf.org> Subject: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring Working Group, Linda and I would like to hear some more from you about draft-zhang-i2nsf-info-model-monitoring. Is it something you think we should be working on? Should we have a separate YANG module for it or fold it into other modules? If we produce a YANG module, do we still need to publish the information model? And, most important, what do you think of the content of the draft? Thanks, Adrian _______________________________________________ I2nsf mailing list I2nsf@ietf.org<mailto:I2nsf@ietf.org> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lo...@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
