I2NSF NSF Monitoring Interface YANG Data Model
draft-ietf-i2nsf-nsf-monitoring-data-model-20

[Ballot comment]
Thank you for the work on this document.

Many thanks to Valery Smyslov for his review: https://mailarchive.ietf.org/arch/msg/art/2XuRUuQaI8ZrVSyuWQn1SHi5dEY/, and to the authors for addressing his comments.

Thank you for addressing my DISCUSS points. I have checked about the Web Attack Alarm and heard no objections on this use from the HTTPBIS wg: https://mailarchive.ietf.org/arch/msg/httpbisa/H2bsyIoGo9JKNUlsCrrwA_rnp08/. DISCUSS point kept for record below.

Also please note that the YANG validation fails on the datatracker.

Francesca

-----

Section 6.3.4.

FP: It is not clear to me why these specific header fields (and these fields only) are selected to be part of the information about Web Attack Alarm - req-user-agent, cookies. I agree with Ben's DISCUSS point 1. (reported below) and would even add to that that more motivation around which header fields are included and why, would help. I'd also like to know if the HTTPBIS working group has been involved in the discussion, and if not, if they could be to give their expert opinion.

Ben's DISCUSS:

(1) I'm not sure I understand the motivation for recommending (in §6.3.4) that
the HTTP Cookie header field be included in a notification about a Web
Attack Event.  In general, the cookie field can contain very sensitive
information, including credentials, and it is very risky to be sending the
cookies around outside of their primary protocol context.  Perhaps, if we
are fully confident that the NSF has correctly identified an attack, it
might be useful to send the cookies around, but I think there are still some
scenarios (e.g., a compromised end-user browser) where the cookies in an
attack request are still confidential information that should not be
disclosed.  Could we say more about why it is recommended to always include
the cookies or weaken the recommendation?

[Ballot comment]
Thank you for the work put into this document. I really like the approach of binding an information model to a data model even if the information model looks more like a data dictionary.

Thank you also for addressing my previous DISCUSS points as well as many of my COMMENT points. I sincerely believe that the changes have improved the document.

! Please note that there is a warning about the syntax of the YANG module !

Please also check the Internet directorate review by Donald Eastlake (thank you BTW) at:
https://datatracker.ietf.org/doc/review-ietf-i2nsf-nsf-monitoring-data-model-14-intdir-telechat-eastlake-2022-02-07/
NB: as you may notice, I have not followed Donald's recommendation to raise a DISCUSS on one point, but Donald and I will appreciate an answer of the authors.

Special thanks to Linda Dunbar for the shepherd's write-up (even if dated one year ago) including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

While I trust the OPS AD for a final say, I am really surprised that the data model does not re-use existing YANG modules (e.g., RFC 8632 and ).

# Previous DISCUSS (just kept for archiving)

## Section 6.2.4
About exporting the "traffic flows", a justification of not using IPFIX is required IMHO.

Also missing the MAC address field as not all flows are IPv4 or IPv6 (LLDP, IS-IS, ARP, ...).

## Section 6.3.2
Why is the geo-location not implied by the IP address ? Or rather, how can it be derived if not based on the IP address ? Hence, why duplicating the information which is always bad for data consistency?


# COMMENTS

## Abstract
Unsure what a "YANG data diagram" is... Is it a well-known wording for YANG experts or is it "YANG tree diagram"?

## Section 4.1
Suggestion to use "I2NSF gauge" rather than "I2NSF counter" to represent processor temperature.

## Section 6.2.1
The use of "port" is unqualified and therefore ambiguous: is it a layer-4 port ? or an interface port ? Even if the reader may guess the former, let's remove the ambiguity.

## Section 6.2.3
Is there a definition of "sessions" ? I.e., is it a data plane TCP/UDP "connection" or a configuration plane connection ?

## Section 6.2.4
Here also, a qualification of the "port" is welcome.

On which interval are the rates computed ? Since the beginning of the flow ? Last minute ? or ?

s/arrival-speed/arrival-throughput/ ?

Note: the above comments are also applicable in other places in the document.

## Section 6.3.1
Even if most (if not all) DoS are actually DDOS, would a section title of "DoS" be more generic ?

## Section 6.3.2
Should this section be renamed in "malware" ?

As the 'virus' event can also be detected locally, is the IP flow information required or even available? Or are NSF never implemented on host for local host security ?

What is the "host" here ? In which case is the "host" neither the source nor the destination IP ?

Is there a reason why the geo-location is not included in other events ? (see also my DISCUSS point above as geo-location is probably derived from the IP addresses).

## Section 6.4.2
Does the "traffic" include only the data plane or also control/management plane ? Does it count the layer-2 framing ?

s/disk-left/disk-space-left/ ?

## Section 6.5.1
Some explanations linking "deep packet inspection" to apparently local user actions will be welcome. For most readers, DPI is for transit traffic not for local actions.

## Section 6.6.1
Are the "drops" caused by policy ? or by hardware/resource error ?

As mentioned above, the "peak" and "average" should be qualified by the measurement period.

## Section 8
s/identity ssl-flood/identity tls-flood/

Is there a reason to have a limited set of application protocol ? I.e., why including FTP and not NTP ? Or why defining any at all .. (except perhaps HTTP/HTTPS).

For many operators, having separate counters for IPv4/IPv6/non-IP will be useful.

# NITS 

## Section 1

s/denial of service attacks (DoS)/denial of service (DoS) attacks/ ?

## Section 6.2.3
s/The number of session table exceeded the threshold/The number of sessions exceeded the table threshold/ ?

## Section 8
For "log-action", there is a mix of "action is block" and "action is discarded" (i.e., different tenses).

[Ballot discuss]
Thank you for the work on this document.

Many thanks to Valery Smyslov for his review: https://mailarchive.ietf.org/arch/msg/art/2XuRUuQaI8ZrVSyuWQn1SHi5dEY/, and to the authors for addressing his comments.

Thank you for partially addressing my DISCUSS points with this new version. I do think the question about the Web Attack Alarm was not completely addressed. I am CC'ing the HTTPBIS wg to see if any of the experts there see any red flags here.

Francesca

-----

Section 6.3.4.

FP: It is not clear to me why these specific header fields (and these fields only) are selected to be part of the information about Web Attack Alarm - req-user-agent, cookies. I agree with Ben's DISCUSS point 1. (reported below) and would even add to that that more motivation around which header fields are included and why, would help. I'd also like to know if the HTTPBIS working group has been involved in the discussion, and if not, if they could be to give their expert opinion.

Ben's DISCUSS:

(1) I'm not sure I understand the motivation for recommending (in §6.3.4) that
the HTTP Cookie header field be included in a notification about a Web
Attack Event.  In general, the cookie field can contain very sensitive
information, including credentials, and it is very risky to be sending the
cookies around outside of their primary protocol context.  Perhaps, if we
are fully confident that the NSF has correctly identified an attack, it
might be useful to send the cookies around, but I think there are still some
scenarios (e.g., a compromised end-user browser) where the cookies in an
attack request are still confidential information that should not be
disclosed.  Could we say more about why it is recommended to always include
the cookies or weaken the recommendation?

[Ballot comment]
The shepherd writeup indicates that there is an IPR declaration, but does not characterize the discussion about it that occurred (if any).  Please update the writeup to state, or at least let the IESG know by replying to this, what the outcome of this was.

I suggest breaking Section 11 into subsections, one for each IANA action being requested.

[Ballot 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:

        memory-alarm

[Ballot 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

[Ballot discuss]
Thank you for the work on this document.

Many thanks to Valery Smyslov for his review: https://mailarchive.ietf.org/arch/msg/art/2XuRUuQaI8ZrVSyuWQn1SHi5dEY/, and to the authors for partially addressing his comments. I am following up on his review about the language tag -  thank you for adding that - with a DISCUSS point. I also have a question about the Web Attack Alarm, more general than Ben, but on the same line.

I also have a number of minor COMMENTs and suggestions, which I hope will improve the document.

Francesca

1. -----

FP: Regarding the language tag description in Section 5 is missing a pointer to RFC 5646 and a default value. The following text could be added:

The attribute is encoded following the rules in Section 2.1 of
      [RFC5646].  The default language tag is "en-US".

I'd also like some stronger text about the tag being required if any of the textual fields are present. In particular, I do not think this text is good enough:

This field is mandatory only
            when the implementation provides more than one human
            language for the human-readable string fields.

I believe that the field should be sent any time any human readable string field is used. I believe all of the human readable fields are optional, so it is ok that language is also optional.

I would also have appreciated more precision about what fields are covered by this language tag (message, output? any other?) in the description in Section 5 and in the YANG module.

Additionally, and this is just a comment as I am not sure if this is already covered by the YANG syntax, I would have expected to see the language leaf under the grouping common-monitoring-data, because that is where message is (assuming that is the only human readable field). Here is an example of another YANG module using the language tag "description-lang" for the "attack-detail" grouping: https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-23. Please do correct me if this is already covered.

2. -----

Section 6.3.4.

FP: It is not clear to me why these specific header fields (and these fields only) are selected to be part of the information about Web Attack Alarm - req-user-agent, cookies. I agree with Ben's DISCUSS point 1. and would even add to that that more motivation around which header fields are included and why, would help. I'd also like to know if the HTTPBIS working group has been involved in the discussion, and if not, if they could be to give their expert opinion.

[Ballot comment]
3. -----

      interval (e.g., 1 second).  This interval is defined as dampening-
      period in [RFC8641].  The dampening-period is configurable.  The

FP: RFC 8641 has the following:

                    +--rw yp:dampening-period?  centiseconds

which indicates the unit of the dampening period, while this document contains:

        |    +--rw dampening-period?  uint32

My preference would be to align the two. I do note this is clarified in the YANG module, where the unit is centiseconds as well, but it would be good to have this clarity in the text in Section 6 as well.

4. -----

FP: On the same note, I would have liked to see the unit stated for other fields in subsections of Section 6: usage, threshold, cpu-usage, disk-usage, disk-left etc. Analogously, a pointer to Section 5.6 of RFC 3339 every time a timestamp is mentioned in subsections of Section 6: start-time, end-time, discontinuity-time, operation-time etc would have been appreciated. Again, I know this is clear in the YANG module, but I do think the descriptive text would have benefitted from the clarifications.

[Ballot comment]
Thanks for working on this specification. Thanks to Kyle Rose for TSVART review and agree with him that I also haven't find any transport related issues, hence the NO objection ballot. However, I regret that QUIC is not included in the models as transport protocol.

I am curious to know why doesn't "i2nsf-nsf-event" sub leaf "i2nsf-nsf-detection-voip-vocn" have a "action*" where rest of the events have actions?

I am also interested to know Eric V's discuss on reusing existing YANG models.

[Ballot discuss]
(1) I'm not sure I understand the motivation for recommending (in §6.3.4) that
the HTTP Cookie header field be included in a notification about a Web
Attack Event.  In general, the cookie field can contain very sensitive
information, including credentials, and it is very risky to be sending the
cookies around outside of their primary protocol context.  Perhaps, if we
are fully confident that the NSF has correctly identified an attack, it
might be useful to send the cookies around, but I think there are still some
scenarios (e.g., a compromised end-user browser) where the cookies in an
attack request are still confidential information that should not be
disclosed.  Could we say more about why it is recommended to always include
the cookies or weaken the recommendation?

(2) I'm not sure I understand the relationship between the different pieces
of information listed in the information model (§6.7.1) for firewall
counters.  My understanding is that typically a firewall will function as if
it were a "bump in the wire" on a particular wire, processing all traffic
into and out of a given part of the network (at least on a particular
interface), and that the internal network might contain multiple machines
that reside on multiple network prefixes.  So when we have the information
model that looks to be the counters reported by a firewall security
function, I don't know how to interpret fields like "Source IP address" and
"Destination port", which are typically tied to a particular flow or
machine, whereas the firewall covers many different flows and potentially
many machines as well.  Is the intent to report on firewall behavior on a
per-flow granularity, akin to what IPFIX does?  That seems likely to produce
a very high volume of log information and it's not clear how useful it would
be to the NSF data collector.  The YANG data model uses a list with the
policy name as the list key, indicating that perhaps the intent is to show
what a given firewall policy has done, but (a) that should be made clear
from the description in the information model, and (b) it still doesn't help
relate the different 4-tuple components to each other.

(3) The information model gives a list of DPI action types that's prefaced
with "e.g.", indicating that it is giving examples only and is not
comprehensive, but the dpi-type YANG typedef is modeled as an enumeration
that does not allow extensibility for future values not listed here.  This
seems like an internal inconsistency that needs to be rectified, whether by
claiming to be a comprehensive list or by switching the YANG to use
extensible identities to represent the DPI action types.

(4) Please confirm that we have achieved the intended level of consistency
between the information model and the YANG data model, in light of the
remarks in my COMMENT section around Sections 6.3.2 through 6.3.5, 6.4.3,
and 6.5.1.

[Ballot comment]
I share the surprise of the directorate reviewer that we need to report on
disk, CPU, and RAM, and interface statistics in the NSF-specific model
(rather than using a more generic OAM functionality for those reports), but
I guess it is harmless to duplicate the functionality.

The way that the timestamp grouping is integrated into the data nodes seems
quite unusual to me.  Not least because it's repeated in each element of a
list (rather than a single timestamp that applies to all entries, which "the
time of the message" description would imply), but also because we typically
think of YANG as providing a data model for state of the device being
monitored, whereas this data node is more a function of when data is
retrieved than a function of the state of the node.

Section 2

  *  Subscription: An agreement initialized by the NSF data collector
      to receive monitoring information from an NSF.  The method to
      subscribe follows the method explained in [RFC5277].

It looks like RFC 5277 is specific to NETCONF; do we want to reference RFC
8650 for RESTCONF notifications as well?

Section 3

  *  The I2NSF User that is the security administrator can configure a
      policy that is triggered on a specific event occurring in the NSF
      or the network [RFC8329]
      [I-D.ietf-i2nsf-consumer-facing-interface-dm].  If an NSF data
      collector detects the specified event, it configures additional
      security functions as defined by policies.

I wonder if it might be more appropriate to indicate that it is the security
controller (which is often, but not required to be, the data collector) that
would configure the additional security functions.

Section 4.1

  I2NSF Record:  A record is defined as an item of information that is
      kept to be looked at and used in the future.  Typically, records
      are information generated by a system entity (e.g., NSF) that is
      based on operational and informational data (i.e., various changes
      in system characteristics), and are generated at particular
      instants to be kept without any changes afterward.  A set of
      records has an ordering in time based on when they are generated.

(side note) I think you should probably keep this text as it is now, but in
a certain sense, you could get a set of records (most notably when from
different sources) and even though they all have timestamps attached, it may
not always be possible to recover a strict ordering in time for the events,
owing to clock skew, clock precision, and the possibility of parallel
execution.  But trying to describe that subtlety would detract from the
point being made here and would (in my opinion) take more words than it's
worth.

Section 4.2

  A specific task of an I2NSF User is to process I2NSF Policy Rules.

If the User is a human, would it make more sense to say that they "provide"
the policy rules, rather than to "process" them?  The current "process"
formulation seems to imply that the User is involved in applying or taking
action based on the policy rules, and I'm not sure if that's the intent.

Section 6

  *  Emission type: The cause type for the message to be emitted.  It
      can be "on-change", "periodic", or "on-request".  An "on-change"

Does the emission type matter at all when the acquisition method is "query"?
(That is, does it only apply when the aquisition method is "subscription"?)

Section 6.1.3

  *  usage: Specifies the size of disk space used.

The YANG instantiation of this represents 'usage' as percent, so we probably
don't want to say "size", which implies a non-percentage amount.

Section 6.2.4

It's not clear that the src-mac/dst-mac should always be included in the
traffic flow event.  They make sense in some situations, but (for example)
if the NSF is in the middle of a provider network, the MAC addresses will
just be from its neighboring routers in the provider and do not convey
information about the customer traffic that is triggering the
notification/report.

  *  arrival-rate: Arrival rate of packets of the traffic flow in
      packet per second calculated from the beginning of the flow.

  *  arrival-throughput: Arrival rate of packets of the traffic flow in
      bytes per second calculated from the beginning of the flow.

Thank you for making a clear definition of how these rates are computed.
That said, I am not sure that "calculated from the beginning of the flow"
will be the most useful value, as a more instantaneous rate might also be of
interest (e.g., measured over the past minute or ten minutes).

Section 6.3.1

  *  attack-src-ip: The IP address of the source of the DDoS attack.

Is this really going to always be a single IP address, even for a
*distributed* denial of service attack?
I see that the YANG models this as a leaf-list, which suggests that this
should be described using the plural sense of the terms.

However, it is still unclear that attempting to enumerate every IP addres
seen participating in a DDoS attack is a useful thing to do.  In other
contexts (e.g., the DOTS WG), we limit ourselves to just picking an
arbitrary sampling of the "top talkers" and conserving server resources by
not trying to list out the long tail of attack IPs.

  *  dst-port: The port number that the attack traffic aims at.

Likewise, might an attack target a range of ports?

Section 6.3.2, 6.3.3, 6.3.4

We do not list an "action" information element here, but there is a data
element for the log-action in the YANG data model in §8.

Section 6.3.3

We do not list information elements here for attack-rate or
attack-throughput, but there are such data elements in the corresponding
YAND model in §8.  (I think that is likely to be an error in the YANG rather
than an omission from here, though.)

  *  protocol: The employed transport layer protocol. e.g., TCP or UDP.

  *  app: The employed application layer protocol. e.g., HTTP or FTP.

It might be worth considering whether QUIC would be listed as the transport
or application layer protocol (or both).

Section 6.3.4, 6.3.5

We do not list an information element here for "severity", but such an
element existst in the corresponding YANG data model in §8.  (I think that
it is likely to be an error in the YANG rather than an omission from here,
though.)

Section 6.3.4

  *  req-user-agent: The HTTP User-Agent header field of the request.

Perhaps no action is needed at this time, but there is some effort underway
at the W3C to deprecate the user-agent header field in favor of something
like RFC 8942 Client Hints (see, e.g.,
https://blog.chromium.org/2021/05/update-on-user-agent-string-reduction.html).
The user-agent value may not remain a valuable piece of information for much
longer.

Section 6.4.3

We list "cause" as a potential additional information element here, but
there does not seem to be a way to represent that information in the YANG
data model in §8.

Section 6.5.1

I'm slightly curious what the src-user information would be used for when
processing the DPI logs.  It doesn't seem inherently problematic to include
this information, but I am not sure when it would be useful.

We list "action" as an information model element here, but I don't see a way
to represent that in the YANG data model in §8.  It may have been misplaced
in the ietf-nsf-detection-ddos container, which has such a leaf-list that is
not reflected in the corresponding information model.

Section 6.6.1

Would it make sense to have a "current rate/throughput" (computed over the
past, e.g., 1 or 10 minutes as previously) to supplement the average and
peak rates that are already listed?

Section 6.7.1

As I remarked on §6.5.1, some clarity on why the name of the I2NSF User that
generated the policy is worth reporting, would be useful.  (This sentiment
applies throughout the document, but I will stop repeating it.)

Likewise, my remark from §6.6.1 about "current rate" seems to apply here as
well.

Section 7

It's interesting that the subsection structure under §6 doesn't quite match
up to the YANG tree structure for the i2nsf-event notification's
sub-event-type choice.  (To be clear, it may or may not be problematic that
they don't match; I just don't know the motivation for doing it this way as
I read through from the top.)

Section 8

I would consider using a more complicated grouping structure so that the
'message' leaf (and probably severity and timestamp as well, if not
vendor-name and nsf-name) currently in common-monitoring-data does not need
to appear under the lists in the tree of data nodes.  The 'message' seems
tailored for notifications only.

I don't understand why there is no configuration leaf for the
virus-detection and VoIP/VoCN notifications (e.g., the "enabled" and
"dampening-period" that we have for the other feature-controlled
functionality).

Some of the nodes that are using uint32 might merit bumping up to a wider
type.  E.g., the ddos attack-rate is currently modeled as uint32, but we've
apparently seen an 809 Mpps attack a couple years ago, which is close enough
to values that are unrepresentable in uint32 to cause some worry about
future growth in attack size.

    typedef log-action {
      type enumeration {

I would suggest adding more description to most of the enum values.  E.g.,
what scope does a "block-ip" or "block-service" block apply to?

    identity dampening-type {
      base characteristics;
      description
        "The type of message dampening to stop the rapid transmission
          of messages. The dampening types are on-repetition and
          no-dampening";

Making a claim like this that there are only two possible types, seems more
aligned with a YANG enumeration than an identity-based scheme.  (But I do
not see a strong motivation to change it, at this time.)

    identity protocol {
      description
        "An identity used to enable type choices in leaves
          and leaflists with respect to protocol metadata. This is used
          to identify the type of protocol that goes through the NSF.";

Why are we defining our own set of identities to identify protocols?  Is
there no suitable prior art we could import?

    grouping characteristics {
      description
        "A set of characteristics of a notification.";

Note that this grouping is used in the system-interface, nsf-firewall, and
nsf-policy-hits lists, so the description of being "of a notification" is
not accurate at present.  (The grouping's members like "dampening-type"
don't seem to make much sense in a data node tree.)

      leaf acquisition-method {
        [...]
      leaf emission-type {

Also, it's slightly surprising that the "acquisition-method" and "emission-type"
are included in the notification payloads, when to some extent they  must be
known already from the context in which the notification is receieved.

        case i2nsf-system-detection-event {
          container i2nsf-system-detection-event {
            description
              "This notification is sent when a security-sensitive
                authentication action fails.";

This description does not seem to match the name of the event/case here.

            list changes {
              key policy-name;
              description
                "Describes the modification that was made to the
                  configuration. The minimum information that must be
                  provided is the name of the policy that has been
                  altered (added, modified, or removed).
                  This list can be extended with the detailed
                  information about the specific changes made to the
                  configuration based on the implementation.";

Should we say this is only applicable to the configuration-change events?

        case i2nsf-traffic-flows {
          container i2nsf-traffic-flows {
          [...]
            leaf protocol {
              type identityref {
                base protocol;
              }
              description
                "The protocol type for nsf-detection-intrusion
                  notification";

but this isn't the nsf-detection-intrusion notification.

        case i2nsf-nsf-log-dpi {
          if-feature "i2nsf-nsf-log-dpi";
          container i2nsf-nsf-log-dpi {

(Per above,) it seems like this container is missing a "uses log-action".

            leaf end-time {
              type yang:date-and-time;
              description
                "The time stamp indicating when the attack ended. If
                  the attack is still undergoing when sending out the
                  notification, this field can be empty.";

Empty or omitted?

            leaf-list attack-src-port {
              type inet:port-number;
              description
                "The transport layer source ports of the DDoS attack";
            }
            leaf-list attack-dst-port {
              type inet:port-number;
              description
                "The transport layer destination ports of the DDoS
                  attack";

We might say something about how not all ports will have been seen on all
the corresponding src/dest IP addresses.

            leaf file-type {
              type string;
              description
                "The type of file virus code is found in (if
                  applicable).";
              reference
                "IANA Website: Media Types";

I don't think media type is a common reference for the notion of "file
type", as might be reflected by the file's suffix.

Section 10

While this text probably suffices to convey the needed requirements, I note
that the REGEXT working group has a long-established formulation for
expressing what seems to be essentially the same requirement.  E.g., from
RFC 9095:

%  This document uses the prefix "b-dn" for the namespace
%  "urn:ietf:params:xml:ns:epp:b-dn" throughout.  Implementations cannot
%  assume that any particular prefix is used and must employ a
%  namespace-aware XML parser and serializer to interpret and output the
%  XML documents.

It might be worth considering reusing this established formulation instead
of creating a new one.

Section 12

I suggest cautioning consumers of the input and output of the system access
log to take care when processing those contents, in light of common shell
vulnerabilities relating to quoting and wildcard expansion.

  Additionally, many of the data nodes in this YANG module such as
  containers "i2nsf-system-user-activity-log", "i2nsf-system-detection-
  event", and "i2nsf-nsf-detection-voip-vocn" are privacy sensitive.
  They may describe specific or aggregate user activity including
  associating user names with specific IP addresses; or users with
  specific network usage.

Let's also add another couple sentences here: "They also may describe the
specific commands that were run by users and the resulting output.  Any
sensitive information in that command input or output will be visible to the
NSF data collector and potentially other entities, and care must be taken to
protect the confidentiality of such data from unauthorized parties."

NITS

Section 1

  This document defines an information model of an NSF monitoring
  interface that provides visibility into an NSF for the NSF data
  collector.  Note that an NSF data collector is defined as an entity
  to collect NSF monitoring data from an NSF, such as Security
  Controller.  It specifies the information and illustrates the methods
  that enable an NSF to provide the information required in order to be
  monitored in a scalable and efficient way via the NSF Monitoring
  Interface.  [...]

I think in the last quoted sentence the "it specifies" is referring again to
"this document" rather than the NSF data collector mentioned in the
preceding sentence.  We might state "this document" again specifically, or
put the "note" sentence inside parentheses (but not both), to clarify what
the pronoun is referring to.

Section 4

  Every system entity creates information about some context with
  defined I2NSF monitoring data, and so every entity can be an I2NSF
  component.  [...]

We might want to add another few words to clarify that when we say "every
(system) entity" we are referring to every entity within a certain scope.
(I.e., what is that scope?)

Section 4.1

      something that happens which may be of interest.  Examples for an
      event are a fault, a change in status, crossing a threshold, or an

s/for/of/

  I2NSF Record:  A record is defined as an item of information that is
      kept to be looked at and used in the future.  Typically, records
      are information generated by a system entity (e.g., NSF) that is
      based on operational and informational data (i.e., various changes

s/that is/that are/

      entity or NSF.  The examples of records include as user
      activities, device performance, and network status.  They are

s/include as/include/

Section 4.2

  In I2NSF monitoring, a notification is used to deliver either an
  event and a record via the I2NSF Monitoring Interface.  The
  difference between the event and record is the timing by which the
  notifications are emitted.  An event is emitted as soon as it happens

I think s/event and a record/event or a record/, to match with the preceding
"either".

Section 6.1.5

  *  severity: The severity level of the message.  There are total
      levels, i.e., critical, high, middle, and low.

s/total/four/

Section 6.3.1

  *  attack-type: The type of DoS or DDoS Attack, i.e., SYN flood, ACK
      flood, SYN-ACK flood, FIN/RST flood, TCP Connection flood, UDP
      flood, ICMP flood, HTTPS flood, HTTP flood, DNS query flood, DNS
      reply flood, SIP flood, SSL flood, and NTP amplification flood.

Please consider s/SSL/TLS/.

Section 6.4.1

  Access logs record administrators' login, logout, and operations on a
  device.  By analyzing them, security vulnerabilities can be
  identified.  [...]

I'd suggest s/security vulnerabilities can be/some security vulnerabilities
can be/.

Section 8

        enum block-service{

missing space before open curly brace.

    typedef dpi-type{

ditto

Please look for more instances; there seem to be too many to list
individually.

    identity application-protocol {
      base protocol;
      description
        "Base identity for Application protocol. Note that popular
          application protocols (e.g., HTTP, HTTPS, FTP, POP3, and
          IMAP) are handled in this YANG module, rather than all
          the existing application protocols.";

I suggest saying "a subset of" rather than "popular", to avoid sparking
arguments about what protocols are "popular".

            leaf src-ip {
              type inet:ip-address-no-zone;
              description
                "The source IPv4 (or IPv6) address of the flow";
            }
            leaf dst-ip {
              type inet:ip-address-no-zone;
              description
                "The destination IPv4 (or IPv6) address of the flow";

I think it would be okay to omit the parentheses and just say "IPv4 or
IPv6".

[Ballot comment]
Reading this right after draft-ietf-i2nsf-nsf-facing-interface-dm-21, I'm struck that there are many things defined as possible filter criteria (e.g. TCP header fields) but are not worth recording as statistics. Does this all fall under the "policy hit counter?"

[Ballot discuss]
Thank you for the work put into this document. I really like the approach of binding an information model to a data model even if the information model looks more like a data dictionary.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Please also check the Internet directorate review by Donald Eastlake (thank you BTW) at:
https://datatracker.ietf.org/doc/review-ietf-i2nsf-nsf-monitoring-data-model-14-intdir-telechat-eastlake-2022-02-07/
NB: as you may notice, I have not followed Donald's recommendation to raise a DISCUSS on one point, but Donald and I will appreciate an answer of the authors.

Special thanks to Linda Dunbar for the shepherd's write-up (even if dated one year ago) including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

While I trust the OPS AD for a final say, I am really surprised that the data model does not re-use existing YANG modules (e.g., RFC 8632 and ).

## Section 6.2.4
About exporting the "traffic flows", a justification of not using IPFIX is required IMHO.

Also missing the MAC address field as not all flows are IPv4 or IPv6 (LLDP, IS-IS, ARP, ...).

## Section 6.3.2
Why is the geo-location not implied by the IP address ? Or rather, how can it be derived if not based on the IP address ? Hence, why duplicating the information which is always bad for data consistency?

[Ballot comment]
## Abstract
Unsure what a "YANG data diagram" is... Is it a well-known wording for YANG experts or is it "YANG tree diagram"?

## Section 4.1
Suggestion to use "I2NSF gauge" rather than "I2NSF counter" to represent processor temperature.

## Section 6.2.1
The use of "port" is unqualified and therefore ambiguous: is it a layer-4 port ? or an interface port ? Even if the reader may guess the former, let's remove the ambiguity.

## Section 6.2.3
Is there a definition of "sessions" ? I.e., is it a data plane TCP/UDP "connection" or a configuration plane connection ?

## Section 6.2.4
Here also, a qualification of the "port" is welcome.

On which interval are the rates computed ? Since the beginning of the flow ? Last minute ? or ?

s/arrival-speed/arrival-throughput/ ?

Note: the above comments are also applicable in other places in the document.

## Section 6.3.1
Even if most (if not all) DoS are actually DDOS, would a section title of "DoS" be more generic ?

## Section 6.3.2
Should this section be renamed in "malware" ?

As the 'virus' event can also be detected locally, is the IP flow information required or even available? Or are NSF never implemented on host for local host security ?

What is the "host" here ? In which case is the "host" neither the source nor the destination IP ?

Is there a reason why the geo-location is not included in other events ? (see also my DISCUSS point above as geo-location is probably derived from the IP addresses).

## Section 6.4.2
Does the "traffic" include only the data plane or also control/management plane ? Does it count the layer-2 framing ?

s/disk-left/disk-space-left/ ?

## Section 6.5.1
Some explanations linking "deep packet inspection" to apparently local user actions will be welcome. For most readers, DPI is for transit traffic not for local actions.

## Section 6.6.1
Are the "drops" caused by policy ? or by hardware/resource error ?

As mentioned above, the "peak" and "average" should be qualified by the measurement period.

## Section 8
s/identity ssl-flood/identity tls-flood/

Is there a reason to have a limited set of application protocol ? I.e., why including FTP and not NTP ? Or why defining any at all .. (except perhaps HTTP/HTTPS).

For many operators, having separate counters for IPv4/IPv6/non-IP will be useful.

# NITS 

## Section 1

s/denial of service attacks (DoS)/denial of service (DoS) attacks/ ?

## Section 6.2.3
s/The number of session table exceeded the threshold/The number of sessions exceeded the table threshold/ ?

## Section 8
For "log-action", there is a mix of "action is block" and "action is discarded" (i.e., different tenses).

[Ballot comment]
[S6.1.5; comment]

* Possibly this set of "interface-state"s is sufficient for security
  monitoring, but I'm wondering if any of the additional "oper-status"
  states from RFC 8343 would be of interest (maybe, maybe not).

[S8; comment]

* Anywhere an inet:ip-address-no-zone is used I'm curious as to whether
  or not an optional associated interface might want to also be present.

  For example, in the case of "i2nsf-traffic-flows" there is no ingress
  nor egress interface.  It's possible that with knowledge of the routing
  at the time the information was captured the ingress/egress interfaces
  could be reconstructed but that might also prove difficult unless that
  information is separately retained.

  This applies to the uses as well where the interface in question might
  want to be noted, either because it could change in the future or perhaps
  because an attack arrives via an unexpected interface.

[S8; question]

* Are all three "leaf language" definitions necessary, or can this be
  something shared, defined only once somewhere else?

Pending already discussed revisions from ARTART and SECDIR reviews in IETF LC.  Also, please respond to the TSVART review.  Discussion on GENART appears to be continuing.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-i2nsf-nsf-monitoring-data-model-12. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-i2nsf-nsf-monitoring
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-i2nsf-nsf-monitoring
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
Prefix: nsfmi
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2021-12-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-i2nsf-nsf-monitoring-data-model@ietf.org, dunbar.ll@gmail.com, i2nsf-chairs@ietf.org, i2nsf@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (I2NSF NSF Monitoring Interface YANG Data Model) to Proposed Standard


The IESG has received a request from the Interface to Network Security
Functions WG (i2nsf) to consider the following document: - 'I2NSF NSF
Monitoring Interface YANG Data Model'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-12-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document proposes an information model and the corresponding
  YANG data model of an interface for monitoring Network Security
  Functions (NSFs) in the Interface to Network Security Functions
  (I2NSF) framework.  If the monitoring of NSFs is performed with the
  NSF monitoring interface in a comprehensive way, it is possible to
  detect the indication of malicious activity, anomalous behavior, the
  potential sign of denial of service attacks, or system overload in a
  timely manner.  This monitoring functionality is based on the
  monitoring information that is generated by NSFs.  Thus, this
  document describes not only an information model for the NSF
  monitoring interface along with a YANG data diagram, but also the
  corresponding YANG data model.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3557/
  https://datatracker.ietf.org/ipr/3607/

Shepherd Write-up for draft-ietf-i2nsf-nsf-monitoring-data-model-06

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is requested for publication as a Standards Track RFC.
It is appropriate to be published as “Stardards Track RFC” because there are Security Functions Monitoring data models specified by the draft.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes an information model and the corresponding
  YANG data model for monitoring Network Security Functions (NSFs) in
  the Interface to Network Security Functions (I2NSF) framework.  If
  the monitoring of NSFs is performed in a comprehensive way, it is
  possible to detect the indication of malicious activity, anomalous
  behavior, the potential sign of denial of service attacks, or system
  overload in a timely manner.  This monitoring functionality is based
  on the monitoring information that is generated by NSFs.  Thus, this
  document describes not only an information model for monitoring NSFs
  along with a YANG data diagram, but also the corresponding YANG data
  model for monitoring NSFs.


Working Group Summary
Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document is specifically written for I2NSF WG as one of the milestones specified by the I2NSF Charter. This document is not considered by any other WGs.
The document has been reviewed by YANG Doctors and has fixed all the issues raised by YANG Doctors.

There was nothing exceptional in the WG processing for this document.
There was careful debate resulting in merging contents from other drafts into this document. 

Document Quality
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

At least two organizations are building a system based on the nsf monitoring data model specified in this document.  There has also been experimentation at IETF hackathons that is consistent with the work.

Personnel
Who is the Document Shepherd? Who is the Responsible Area Director?

Linda Dunbar (dunbar.ll@gmail.com) is the document shepherd.
Roman Danyliw ( rdd@cert.org) is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This revision and the previous revision were reviewed by the document shepherd. All comments arising from the reviews have been addressed.
The document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, The WG is small, but there were a good number of sound reviews, including YANG Doctor reviewing.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not required, but the content of the document has been shared with Open Network User Group (ONUG) Software Defined Security Service WG and MEF Application Flow Security for SDWAN service gruop.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No. This document is specifically noted as a deliverable in the WG charter.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

The authors have been explicitly reminded of their responsibilities under BCP 78 and 79. By placing their names as authors of the document they have acknowledged those BCPs and agreed to comply with the terms of the IETF's IP policies.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

There is an IPR disclosure for this draft. Details can be found: https://datatracker.ietf.org/ipr/3607/.


(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Good.
There has been review and supporting positions across the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable. There is no MIB specified by the document.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Yes. This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:

  URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  Registrant Contact: The IESG.
  XML: N/A; the requested URI is an XML namespace.


  This document requests IANA to register the following YANG module in
  the "YANG Module Names" registry [RFC7950][RFC8525]:
name: ietf-i2nsf-nsf-monitoring
  namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  prefix: nsfmi
 
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:

  URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  Registrant Contact: The IESG.
  XML: N/A; the requested URI is an XML namespace.


  This document requests IANA to register the following YANG module in
  the "YANG Module Names" registry [RFC7950][RFC8525]:
name: ietf-i2nsf-nsf-monitoring
  namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  prefix: nsfmi


(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No such section, no such review.

Shepherd Write-up for draft-ietf-i2nsf-nsf-monitoring-data-model-06

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is requested for publication as a Standards Track RFC.
It is appropriate to be published as “Stardards Track RFC” because there are Security Functions Monitoring data models specified by the draft.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes an information model and the corresponding
  YANG data model for monitoring Network Security Functions (NSFs) in
  the Interface to Network Security Functions (I2NSF) framework.  If
  the monitoring of NSFs is performed in a comprehensive way, it is
  possible to detect the indication of malicious activity, anomalous
  behavior, the potential sign of denial of service attacks, or system
  overload in a timely manner.  This monitoring functionality is based
  on the monitoring information that is generated by NSFs.  Thus, this
  document describes not only an information model for monitoring NSFs
  along with a YANG data diagram, but also the corresponding YANG data
  model for monitoring NSFs.


Working Group Summary
Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document is specifically written for I2NSF WG as one of the milestones specified by the I2NSF Charter. This document is not considered by any other WGs.
The document has been reviewed by YANG Doctors and has fixed all the issues raised by YANG Doctors.

There was nothing exceptional in the WG processing for this document.
There was careful debate resulting in merging contents from other drafts into this document. 

Document Quality
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

At least two organizations are building a system based on the nsf monitoring data model specified in this document.  There has also been experimentation at IETF hackathons that is consistent with the work.

Personnel
Who is the Document Shepherd? Who is the Responsible Area Director?

Linda Dunbar (dunbar.ll@gmail.com) is the document shepherd.
Roman Danyliw ( rdd@cert.org) is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This revision and the previous revision were reviewed by the document shepherd. All comments arising from the reviews have been addressed.
The document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, The WG is small, but there were a good number of sound reviews, including YANG Doctor reviewing.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not required, but the content of the document has been shared with Open Network User Group (ONUG) Software Defined Security Service WG and MEF Application Flow Security for SDWAN service gruop.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No. This document is specifically noted as a deliverable in the WG charter.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

The authors have been explicitly reminded of their responsibilities under BCP 78 and 79. By placing their names as authors of the document they have acknowledged those BCPs and agreed to comply with the terms of the IETF's IP policies.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

There is an IPR disclosure for this draft. Details can be found: https://datatracker.ietf.org/ipr/3607/.


(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Good.
There has been review and supporting positions across the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable. There is no MIB specified by the document.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Yes. This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:

  URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  Registrant Contact: The IESG.
  XML: N/A; the requested URI is an XML namespace.


  This document requests IANA to register the following YANG module in
  the "YANG Module Names" registry [RFC7950][RFC8525]:
name: ietf-i2nsf-nsf-monitoring
  namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  prefix: nsfmi
 
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:

  URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  Registrant Contact: The IESG.
  XML: N/A; the requested URI is an XML namespace.


  This document requests IANA to register the following YANG module in
  the "YANG Module Names" registry [RFC7950][RFC8525]:
name: ietf-i2nsf-nsf-monitoring
  namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring
  prefix: nsfmi


(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No such section, no such review.