Subject: [I2nsf] Robert Wilton's Discuss on draft-ietf-i2nsf-nsf-monitoring-data-model-15: (with DISCUSS and COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 17 Feb 2022 04:17:18 -0800

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