Skip to main content

Last Call Review of draft-ietf-i2nsf-nsf-monitoring-data-model-06

Request Review of draft-ietf-i2nsf-nsf-monitoring-data-model-06
Requested revision 06 (document currently at 20)
Type Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2021-03-26
Requested 2021-03-02
Requested by Linda Dunbar
Authors Jaehoon Paul Jeong , Patrick Lingga , Susan Hares , Liang Xia , Henk Birkholz
I-D last updated 2021-03-23
Completed reviews Yangdoctors Early review of -04 by Andy Bierman (diff)
Yangdoctors Last Call review of -06 by Andy Bierman (diff)
Genart Last Call review of -12 by Dale R. Worley (diff)
Artart Last Call review of -12 by Valery Smyslov (diff)
Secdir Last Call review of -12 by Melinda Shore (diff)
Tsvart Last Call review of -12 by Kyle Rose (diff)
Secdir Telechat review of -14 by Melinda Shore (diff)
Intdir Telechat review of -14 by Donald E. Eastlake 3rd (diff)
The document has been reviewed by YANG DR for an Early Review request, reached the "Almost READY" state. The authors have revised the draft twice. We have started the WGLC for the 06 version of the draft. Andy Bierman asked to request Another YANG DR review for the 06 version.
Assignment Reviewer Andy Bierman
State Completed
Request Last Call review on draft-ietf-i2nsf-nsf-monitoring-data-model by YANG Doctors Assigned
Posted at
Reviewed revision 06 (document currently at 20)
Result Ready w/issues
Completed 2021-03-23
Status: Ready with Issues

Most of the issues raised in the review of draft-04 have been

Major Issues:

 - None

Moderate Issues:

1) too many YANG features

There are 13 YANG features, one for each of the 13 notification-stmts
defined.  There should be as few YANG features defined as possible.
They should only be used if it is an unreasonable burden (compared
to the feature value) for all servers to support the functionality.

2) list /i2nsf-monitoring-configuration/system-alarm

This is yet another alarm management system created in the IETF.
I guess the WG decided that RFC 8632 was not suitable.

It is not clear how this system prevents excessive notifications
sent to a client.

What happens when the CPU, memory, or disk usage crosses back and
forth over the threshold? Seems like an alarm is generated for each
upward crossing of the threshold leaf.

The precise behavior for triggering and then re-arming an alarm
needs to be specified in the YANG module.

RMON Alarms (RFC 2819) defines one way to prevent bursts of
SNMP notifications, using an alarm reset threshold.

YANG Push (RFC 8641) uses a dampening-period approach to prevent
flooding the receiver with notifications.

Also, it is not clear what use-case is served by "threshold = 0".
The range is 0..100 instead of 1..100.

Minor Issues:

3) too many notifications

This module creates a lot of notifications to manage, and they are
all optional to implement. This increases complexity in both
the client implementation and operations.

If you really need all 13 notifications then OK, but
13 notification events is a lot for one YANG module,
especially if this set will get even larger over time.

Here is one way to reduce the number of event definitions.
The example below has 1 event and 13 sub-event types, but it could
also apply to N event types each with some sub-event types.

This design template adds one more layer in the notification message,
but it is probably easier for the client and operator to manage.
The deployment may require filters and access control rules that become
more complex for a large number of notifications.

    notification i2nsf-event {
        "Wrapper for all I2NSF events";

      choice sub-event-type {
          "This choice must be augmented with cases for each allowed
           sub-event.  Only 1 sub-event will be instantiated in each
           i2nsf-event message. Each case is expected to define one
           container with all the sub-event fields.";

         // could put sub-events inline
         case i2nsf-system-detection-alarm {
           if-feature "i2nsf-system-detection-alarm";
           container i2nsf-system-detection-alarm {
             // contents of i2nsf-system-detection-alarm data


     // could add sub-events via augments at any time
     augment "/i2nsf-event/sub-event-type" {
       case i2nsf-system-detection-event {
         if-feature "i2nsf-system-detection-event";
         container i2nsf-system-detection-event {
           // contents of i2nsf-system-detection-event data


4) underscore vs. hyphen

There are many field names in sec. 7 that are incorrect
because they use an underscore instead of a hyphen char
(e.g. req_cookies but leaf name is req-cookies)

5) verbose SNMP-style names

The term -configuration in the object names is unusual.
Repeating the parent name (like SMIv2) is not usually done in YANG.
(e.g., i2nsf-system-detection-event-configuration)

6) identifiers should use well-known abbreviations or spell
out the word if not too long.  E.g "ave" -> "average"

7) Is there a reason some identities are ALL-CAPS and others
are all-lower-case? This should be explained in the YANG module.