Robert Wilton has entered the following ballot position for draft-ietf-i2nsf-nsf-monitoring-data-model-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Thanks for this document. I have one discuss issue that should hopefully be fairly easy to resolve, that regards the use of some XML boilerplate in the examples. I appreciate that this text was proposed during one of the area reviews by an XML expert, but I don't believe that it helps the readability of the document, doesn't appear in any of our other IETF YANG drafts, and the consensus of the NETMOD WG is that this text isn't helpful, and instead we should look to clarify this in RFC 7950 itself. To this end, I think that we should remove the following text, and instead cite the standard XML reference, NETCONF and YANG, for the examples. In order for the XML data to be used correctly, the prefix (i.e., the characters before the colon or 'nsfmi' in the example) in the content of the element that uses the "identityref" type (e.g., /i2nsf-event/i2nsf-system- detection-alarm/alarm-category/) in the YANG module described in this document MUST be the same as the namespace prefix (i.e., 'nsfmi' in the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf- monitoring. Therefore, XML software MUST be chosen that makes the namespace prefix information available. Related to this, given that it looks like the identities in the example are defined in the same module, then I believe that the XML namespace for those identities is not needed (as per RFC 7950, last paragraph in 9.10.5). So, the example could look like this, and applied similarly elsewhere: <alarm-category>memory-alarm</alarm-category> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First, I understand that Tom Petch has been helping with the YANG in the NSF documents, and I would like to thank him for the time and help that he has given to improving these documents. 4.1 Retention and Emission from NSFs Emission is defined as the delivery of monitoring data in NSFs to an NSF data collector. The I2NSF monitoring information retained on a system entity (e.g., NSF) may be delivered to a corresponding I2NSF User via an NSF data collector. The information consists of the aggregated records, typically in the form of log-files or databases. For the NSF Monitoring Interface to deliver the information to the NSF data collector, the NSF needs to accommodate standardized delivery protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. The NSF data collector can forward the information to the I2NSF User through standardized delivery protocols (e.g., RESTCONF and NETCONF). The interface for this delivery is out of the scope of this document. I'm somewhat struggling to understand exactly what is out of scope for this document. Please can you clarify for my understanding. Separately, would it be helpful for Netconf Event Monitoring and YANG Push also be mentioned/referenced here? 4.3. Push and Pull for the retrieval of monitoring data from NSFs This may be deliberate, but it was somewhat unclear to me what protocol mechansims you mean here. Even if you don't want to constrain the solution to NETCONF/RESTCONF & YANG Push, I think that it would be helpful to readers to cite these as concrete examples of mechanisms to pull/push the data. 6. Extended Information Model for Monitoring Data It this protocol information about how data is being retreived from the NSF that is being embedded in the data returned from the NSF? If so, then although I think that it is great the the document specifies what the expected access is for different parts of the scheme, I'm somewhat less convinced that embedded, what is effectively protocol information, into the data that is being returned by that protocol. Is the reason that this is being done because the expectation is that this information is useful and likely to need to be stored with the records/events anyway? In particular, of the three fields, I'm less convinced that the acquisition-method is actually useful data to be including. 6.1.3. Disk Alarm Would storage alarm be better than disk alarms? Perhaps the storage isn't even local to the device. YANG: i2nsf-event vs i2nsf-nsf-event It wasn't clear to me from the naming of these two top level structures and descriptions how they differed in the events that they hold. Perhaps this could be clarified. Regards, Rob _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
