I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-31

[Ballot comment]
# GEN AD review of draft-ietf-i2nsf-consumer-facing-interface-dm-27

CC @larseggert

Thanks to Roni Even for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/PrQuAtGM5yKx1cs4Upt2cRel9IA).

## Comments

### DOWNREFs

Possible DOWNREF from this Standards Track doc to `[OPENIOC]`. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to `[MISPCORE]`. If so, the IESG
needs to approve it.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 6.1, paragraph 99
```
-          for an IP address, such as IPv4 adress and IPv6 address.";
+          for an IP address, such as IPv4 address and IPv6 address.";
+                                            +
```

#### Section 6.1, paragraph 121
```
-                  category such as SNS sites, game sites, ecommerce
+                  category such as SNS sites, game sites, e-commerce
+                                                            +
```

#### Section 6.1, paragraph 135
```
-              gaming sites, ecommerce sites";
+              gaming sites, e-commerce sites";
+                              +
```

### URLs

These URLs in the document can probably be converted to HTTPS:

* http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm
* http://www.iso.org/iso/home/standards/country_codes.htm#2012_iso3166-2

### Grammar/style

#### Section 3.1, paragraph 1
```
sf-capability-data-model]. Case (anti-virus): This field represents the conf
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.2, paragraph 1
```
This information describes a caller id or receiver id in order to prevent an
                                    ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.2, paragraph 1
```
on describes a caller id or receiver id in order to prevent any exploits (or
                                    ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.2, paragraph 3
```
ow-rate-threshold? uint64 | +--rw anti-virus | | +--rw profile* string | | +-
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.2, paragraph 9
```
he Action object SHALL have following information: Primary-action: This fiel
                            ^^^^^^^^^^^^^^^^^^^^^
```
The article "the" may be missing.

#### Section 4, paragraph 3
```
, e.g., 'Dublin', 'New York', and 'Sao Paulo'. Range-ipv4-address: This repre
                                  ^^^^^^^^^
```
Did you mean "São Paulo" (= city in Brazil)?

#### Section 4.5, paragraph 1
```
is field is not mandatory but recommended to be used as it is helpful for fut
                              ^^^^^^^^^^^^^^^^^
```
The verb "recommended" is used with the gerund form.

#### Section 5.1, paragraph 4
```
er-Facing Interface, this document provide examples for security policy rules
                                  ^^^^^^^
```
The verb "provide" is plural. Did you mean: "provides"? Did you use a verb
instead of a noun?

#### Section 6.1, paragraph 68
```
nclude 'Dublin', 'New York', and 'Sao Paulo'."; } uses ip-address-info{ refin
                                  ^^^^^^^^^
```
Did you mean "São Paulo" (= city in Brazil)?

#### Section 6.1, paragraph 94
```
ck mitigation."; } } } container anti-virus { description "A condition for an
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.1, paragraph 94
```
us { description "A condition for anti-virus"; leaf-list profile { type strin
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.1, paragraph 97
```
hs are filenames/paths to be excluded and relative ones are interpreted as gl
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6.1, paragraph 114
```
ed as a binary to accommodate any kind of a payload type such as HTTP, HTTPS,
                                  ^^^^^^^^^
```
If "kind" is a classification term, "a" is not necessary. Use "kind of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

#### Section 6.1, paragraph 114
```
5 bytes of the payload. This field accept values greater than or equal to th
                                  ^^^^^^
```
The verb "accept" is plural. Did you mean: "accepts"? Did you use a verb
instead of a noun?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
Hi,

Thanks for this document.  There is one issue that I think are worthy of discussion:

(1) p 7, sec 3.2.  Condition Sub-model

  Case (firewall):  This field represents the layer-2 header (e.g., MAC
            addresses), layer-3 header (e.g., IPv4 or IPv6 addresses,
            ICMPv4 or ICMPv6 parameters, and transport layer protocol)
            and layer-4 header (e.g., port numbers) of the network
            traffic.  Note that the YANG module only provides high-
            level ICMP messages that are concretely specified by either
            ICMPv4 or ICMPv6 messages (e.g., Destination Unreachable:
            Port Unreachable which is ICMPv4's type 3 and code 3 or
            ICMPv6's type 1 and code 4).  Also note that QUIC protocol
            [RFC9000] is excluded in the data model as it is not
            considered in the initial I2NSF documents [RFC8329].  The
            QUIC traffic should not be treated as UDP traffic.  The
            data model should be extended or augmented appropriately to
            support the handling of QUIC traffic according to the needs
            of the implementer.

(2) p 8, sec 3.2.  Condition Sub-model

  Note that due to the exclusion of QUIC protocol in the I2NSF
  documents, HTTP/3 is also excluded in the document along with the
  QUIC protocol.  HTTP/3 should neither be interpreted as HTTP/1.1 nor
  HTTP/2.  The data model should be extended or augmented appropriately
  to support the handling of HTTP/3 traffic according to the needs of
  the implementer.

Is there a concrete plan for adding support for QUIC and HTTP/3, given that it stated that these cannot be handled as UDP or HTTP/1.1 or HTTP/2?

[Ballot comment]
(3) p 38, sec 6.1.  YANG Module of Consumer-Facing Interface

          leaf-list system-alarm {
            type identityref {
              base i2nsfmi:system-alarm;
            }
            description
              "The security policy rule according to
                system alarms.";
          }
        }
        container condition {
          description
          "Conditions for general security policies.";

Please include documentation here for the condition container as to how the different fields are combined (i.e., that all configured conditions must match for a rule to trigger).

(4) p 4, sec 3.  YANG Tree Diagram of Policy

  Resolution-strategy:  This field represents how to resolve conflicts
            that occur between actions of the same or different policy
            rules that are matched and contained in this particular
            NSF.  The resolution strategy is described in Section 3.2
            of [I-D.ietf-i2nsf-capability-data-model] in detail.

Given you document the default for language above, would it name sense to document the default matching rule here as well?


(5) p 7, sec 3.2.  Condition Sub-model

  The Condition object describes the network traffic pattern or fields
  that must be matched against the observed network traffic for the
  rule to trigger.  The fields used to express the required conditions
  to trigger the rule are organized around the class of NSFs expected
  to be able to observe or compute them.  Figure 5 shows the YANG tree
  of the Condition object.  The Condition Sub-model SHALL have the
  following information:

I find the use of "Case" confusing in the descriptions below.  I mistakenly thought that you were referring to the YANG case statements under choice, and hence only one of these conditions can be expressed for a given rule.


(6) p 20, sec 6.1.  YANG Module of Consumer-Facing Interface

    identity fmr {

Using longer identity names for the resolution-strategies may make the module more readable.  E.g. 'first-matching-rule' might be clearer than fmr.  If you change this, then I would suggest changing it for the other resolution-strategies as well (and the any default values).


(7) p 37, sec 6.1.  YANG Module of Consumer-Facing Interface

        leaf priority {
          type uint8;
          description
            "The priority of the rule to indicate the order of the
              rules to be matched. A higher value means a higher priority.
              The packet or flow will be matched with the rule with
              the highest priority value first and continues to a lower
              priority value. Once a rule matches the packet or flow,
              the NSF should execute the rule and terminate the matching
              process. If multiple rules have an equal priority, the
              actual order is undefined. The handling of the selection
              of those rules depends on the implementer, e.g., non-rule
              selection, first rule selection or random rule selection.";
        }

Did you consider using an "order-by-user" list to define the priority instead?  I.e., process the rules in the order that they are specified in the list.


(8) p 39, sec 6.1.  YANG Module of Consumer-Facing Interface

                  error-message
                    "An end port number MUST be equal to or greater than
                      a start port number.";

I would suggest changing this to 'must', or otherwise you need to add the standard RFC 2119 boilerplate to the YANG module (pyang can help with this).


(9) p 43, sec 6.1.  YANG Module of Consumer-Facing Interface

                description
                  "This represents the repetition time.  In the case
                    where the frequency is weekly, the days can be
                    set.";

This comment is slightly misleading.  I would suggest deleting, or perhaps rewording "In the case where the frequency is weekly, the days can be set.";"


(10) p 43, sec 6.1.  YANG Module of Consumer-Facing Interface

                leaf-list date {

'date' is a somewhat confusing name for this.  Would 'day-of-month' be better?


(11) p 44, sec 6.1.  YANG Module of Consumer-Facing Interface

                leaf-list month {

'month' is a confusing name for this.  Would 'month-and-day' be better?


(12) p 44, sec 6.1.  YANG Module of Consumer-Facing Interface

                  description
                    "This represents the repeated date and month of
                      every year.  More than one can be specified.
                      A pattern used here is Month and Date (MM-DD).";

So, if you wanted the policy to apply for a particular 3 weeks per year, then I presume that it would be necessary to list each of those day separately?  Did you consider allowing ranges here, or what that be too much complexity?

Regards,
Rob

[Ballot comment]
Thanks for the document,

I've opted against making this a discuss - though debated doing so, I would like however to see some feedback on the below point.

I think having read this, and then read through the other comments submitted most of what I was going to say is already covered.  I would though like the draw specific reference to John's comment on section 6.1 and the regex for the time typedef contained there in.  Considering the number of time formats in existence (RFC822/RFC822/RFC850/RFC1123/RFC1123/RFC3339) and sub-parts of those RFC's (what I will refer to as RFC822Z, RFC1123Z and RFC3339Nano) it would be nice to see a format that conforms to one of the defined standards unless there is specific reason to deviate.  I also think that if we're conforming to one of the above - this should probably form a reference in the document for clarity.

[Ballot comment]
I support Lars' DISCUSS about normative references.

I don't understand the shepherd writeup answer to question #18.  This document doesn't create any new registries.

I'm no expert, but shouldn't the YANG Module itself include (as a comment) the BCP 14 boilerplate?  I ask because the only MUST is in the module, and the only SHOULD is in Security Considerations, so in one sense the BCP 14 reference could go away, and in another, it's missing.

[Ballot comment]
I support Lars' DISCUSS about normative references.

I don't understand the shepherd writeup answer to question #18.  This document doesn't create any new registries.

[Ballot comment]
Thanks for working on this specification. Thanks to Joe for the TSVART review.

I am supporting Lars's 1st and 3rd discuss point. I am also unsure if a github commit can be normative ref and should be a valid ref in any form in a PS specification.

[Ballot comment]

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Linda Dunbar for the shepherd's detailed write-up including the WG consensus *but* it lacks a proper the justification of the intended status. The write-up mentions 2 IPR while there are 4 of them.

Please note that Dirk Von Hugo is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/reviewrequest/17250/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non blocking)

## Threat feed

While threat feeds are important, do they have a place in this model ?

## Section 3

Including a YANG tree in a section about an information model is really surprising. It seems that the whole section is more about the YANG data model than about an information model. Suggest to rename the section.

Having a leaf about language that is optional also means that the complete instance will be mono-lingual (i.e., not possible to have an instance with descriptions both in English and in Korean)

## Section 3.2

What about filtering ARP ? or IPv6 extension headers ?

`For more information about the mapping between ICMPv4 and ICMPv6 messages, refer to [IANA-ICMP-Parameters] and [IANA-ICMPv6-Parameters]` but there is no mapping described in the IANA tables. Also, this text is partially redundant with the text in 'case(firewall)'.

## Sections 4.1 & 4.2

What is impact of randomised MAC addresses and RFC 8981 IPv6 temporary addresses on this model ? Is it still worth doing ?

Is a start-end practical in a sparse addressing space as IPv6 ? Should this rather be a prefix notation ?

## Section 4.3

Is the 'city' in the language as indicated by a top leaf or is it English? Please, specify.

Did the author try to find another representation than basically copying/duplicating addresses in 'user/device/location' trees ? Why not having a list of all addresses (assuming that this is useful) and then having a leaf for user / device / location grouping ? This could be faster to identify a rule relevant to a MAC address (even if performance is not really the key point of an information model).

## Section 5

Should the work done in DOTS WG be listed in this section ?

## Section 6.1

I am not a YANG expert but isn't there an easier way to refer to draft-ietf-i2nsf-nsf-monitoring-data-model rather than redefining all identities here ?

[Ballot discuss]
# GEN AD review of draft-ietf-i2nsf-consumer-facing-interface-dm-27

CC @larseggert

Thanks to Roni Even for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/PrQuAtGM5yKx1cs4Upt2cRel9IA).

## Discuss

### Section 4.4, paragraph 3
```
    URL:      This field represents the URL or hostname.
```
Not a YANG expert, but I thought an inet:uri had to be an actual URI and hence cannot simply be a hostname string?

### Section 7.1, paragraph 7
```
    3.  The "https://www.sns-example1.com/" and "https://www.sns-
        example2.com/" URLs are labeled as "sns-websites".
 
    4.  The "sip:alice@atlanta.com", "sip:bob@203.0.113.15", and
        "sip:carol@chicago.com" SIP identities are labeled as "malicious-
        id".
```
Use actual RFC2606 example domain names and RFC5737 example IP addresses.
Also in the XML in Figure 19 of course.

### Section 10.1, paragraph 43
```
    [MISPCORE] Dulaunoy, A. and A. Iklody, "MISP Core",
                commit 051e33b6711a660faf81733d825f1015aa0d301b, February
                2022, .
 
    [OPENIOC]  Gibb, W., "OpenIOC 1.1 DRAFT",
                commit d42a8777708e171f8bdd3c2c9f8590c83488285d, August
                2013, .
```
For discussion in the IESG. I don't think GitHub commits are appropriate normative references.

[Ballot comment]
## Comments

### DOWNREFs

Possible DOWNREF from this Standards Track doc to `[OPENIOC]`. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to `[MISPCORE]`. If so, the IESG
needs to approve it.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 6.1, paragraph 99
```
-          for an IP address, such as IPv4 adress and IPv6 address.";
+          for an IP address, such as IPv4 address and IPv6 address.";
+                                            +
```

#### Section 6.1, paragraph 121
```
-                  category such as SNS sites, game sites, ecommerce
+                  category such as SNS sites, game sites, e-commerce
+                                                            +
```

#### Section 6.1, paragraph 135
```
-              gaming sites, ecommerce sites";
+              gaming sites, e-commerce sites";
+                              +
```

### URLs

These URLs in the document can probably be converted to HTTPS:

* http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm
* http://www.iso.org/iso/home/standards/country_codes.htm#2012_iso3166-2

### Grammar/style

#### Section 3.1, paragraph 1
```
sf-capability-data-model]. Case (anti-virus): This field represents the conf
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.2, paragraph 1
```
This information describes a caller id or receiver id in order to prevent an
                                    ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.2, paragraph 1
```
on describes a caller id or receiver id in order to prevent any exploits (or
                                    ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 3.2, paragraph 3
```
ow-rate-threshold? uint64 | +--rw anti-virus | | +--rw profile* string | | +-
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.2, paragraph 9
```
he Action object SHALL have following information: Primary-action: This fiel
                            ^^^^^^^^^^^^^^^^^^^^^
```
The article "the" may be missing.

#### Section 4, paragraph 3
```
, e.g., 'Dublin', 'New York', and 'Sao Paulo'. Range-ipv4-address: This repre
                                  ^^^^^^^^^
```
Did you mean "São Paulo" (= city in Brazil)?

#### Section 4.5, paragraph 1
```
is field is not mandatory but recommended to be used as it is helpful for fut
                              ^^^^^^^^^^^^^^^^^
```
The verb "recommended" is used with the gerund form.

#### Section 5.1, paragraph 4
```
er-Facing Interface, this document provide examples for security policy rules
                                  ^^^^^^^
```
The verb "provide" is plural. Did you mean: "provides"? Did you use a verb
instead of a noun?

#### Section 6.1, paragraph 68
```
nclude 'Dublin', 'New York', and 'Sao Paulo'."; } uses ip-address-info{ refin
                                  ^^^^^^^^^
```
Did you mean "São Paulo" (= city in Brazil)?

#### Section 6.1, paragraph 94
```
ck mitigation."; } } } container anti-virus { description "A condition for an
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.1, paragraph 94
```
us { description "A condition for anti-virus"; leaf-list profile { type strin
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.1, paragraph 97
```
hs are filenames/paths to be excluded and relative ones are interpreted as gl
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6.1, paragraph 114
```
ed as a binary to accommodate any kind of a payload type such as HTTP, HTTPS,
                                  ^^^^^^^^^
```
If "kind" is a classification term, "a" is not necessary. Use "kind of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

#### Section 6.1, paragraph 114
```
5 bytes of the payload. This field accept values greater than or equal to th
                                  ^^^^^^
```
The verb "accept" is plural. Did you mean: "accepts"? Did you use a verb
instead of a noun?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
I've read through the document. I feel that like some other I2NSF documents
before, it incorporates partial IANA registries instead of referencing
these IANA registries for their values. We had other I2NSF documents where this
was changed to point to IANA registries. Is that something that is worth doing
here? For example, the listing of services like telnet, pop3, pop3s, imap, imaps, ftp.

Additionally, POP (with or without TLS) is very dead. So is IMAP without TLS. Why
reference them in this document?


        Also note that QUIC protocol [RFC9000] is excluded in the data
        model as it is not considered in the initial I2NSF documents
        [RFC8329]. The QUIC traffic should not be treated as UDP traffic
        and will be considered in the future I2NSF documents.

I understood that I2NSF is closing? So this statement is no longer true.
What should be done with QUIC then?

        The action could be one of "pass", "drop", "reject", "rate-limit",
        "mirror", "invoke-signaling", "tunnel-encapsulation",
        "forwarding", and "transformation".

Why is it "drop" and "reject" versus "forwarding" and "transformation"? For consistency,
would one not want to use either: drop, reject, forward, transform. Or: dropping, rejecting,
forwarding, transforming" ?

[Ballot comment]
Should section 6.1 have the IETF Trust template text added ?

There is an entry for http (meaning 1.x) and http2, but not for http3 ? Any reason why not?

  leaf language {
      type string {
        pattern
                [ 16 lines of sort of regexp ]

I think this is overspecified and constraining. Probably best to be specified as a generic string.

  leaf priority {
        type uint8 {
          range "1..255";
        }

Why is 0 excluded? Eg the priority for MX records can be 0. The Linux kernel IPsec SPD entry can be
priority 0.


        This field represents the configuration for an Antivirus.

An antivirus what? I don't think you mean an anti-virus, eg a program
that replicates itself to fight other viruses ? Maybe "Antivirus service" ?
The term "Antivirus" is used a few time in this confusing context.

  container anti-virus {
          description
          "A condition for anti-virus";

Like here.

        An NSF Capability model is proposed in
        [I-D.ietf-i2nsf-capability-data-model] as the basic model for
        both the NSF-Facing interface and Consumer-Facing Interface
        security policy model of this document.

Change "proposed" to "defined" as the other draft will go out as RFC
at the same time as this one in one cluster.

        Case (url-category):

The name "url-category" seems odd. It seems to refer to a block or allow list for URLs?

        This information describes a caller id or receiver id in order
        to prevent any exploits (or attacks) of Voice over IP (VoIP)
        or Voice over Cellular Network (VoCN).

I don't understand what is meant with the sentence. Does Case (voice) list a contact
information? Hoes does that "prevent any exploits" ?

[Ballot comment]
# Internet AD comments for draft-ietf-i2nsf-consumer-facing-interface-dm-27
CC @ekline

## Comments

### S6.1

* It may seem obvious from the context, but I always think it's better to
  be explicit about ranges of things: the ip-address-info and
  range-match-ipv[46] things might say that the ranges are inclusive of the
  endpoints, or that the intervals are closed, or words to that effect.

[Ballot comment]
# John Scudder, RTG AD, comments draft-ietf-i2nsf-consumer-facing-interface-dm-27
CC @jgscudder

Thanks for this work. Since my expertise with YANG is rudimentary at best, my review was necessarily pretty limited. I did note a few things that seem underspecified or ambiguous, although for all I know some of my comments would be trivially answered by reference to the YANG module if I were better at reading it. For that reason, I haven't chosen to make any of these DISCUSSes, although otherwise I might have done so for the first comment.

## COMMENTS

### Section 3, Priority

I don't see any explanation of what the semantics of "priority" are, other than the tautological definition given here (essentially, it says "the priority is the priority"). Is "priority" explained in one of the normative references? I did spend a little while looking and didn't find anything. If not, it seems as though its semantics need to be explained here.

My guess is that rules are matched in priority order, with lower priorities being matched first, and that matching terminates after the first match occurs. I would also guess that order is undefined among rules with equal priorities. But none of this is stated, and I think it needs to be.

There is also no example that uses 'priority' which might otherwise have helped (although the definition should be able to stand without reference to examples in any case).

### Section 3.1, what is a security event?

This is a little bit of a nit perhaps, but

  based on a security event (i.e., system event and system alarm).

Parsing the parenthetical closely, I would conclude that a security event is defined as the concatenation of both a system event and a system alarm, in other words, both must be present, which seems a little surprising. Maybe that's what you mean, or maybe you mean "or" instead of "and"?

I might have been able to work this out for myself if an example were provided that used 'event', but unfortunately, there isn't one.

### Section 5.2, multiple instances

I can't make out what this sentence means: "If multiple instances of content are defined, it should match all contents somewhere in the session stream." One problem is the disagreement in number -- "multiple instances of content" is plural, and "it" is singular. I wouldn't pick on the grammar nit, except the disagreement in number makes it hard for me to work out what the referent of "it" is.

In general, I can't work out exactly what this paragraph is telling me to do. Maybe an implementor working in this area wouldn't have problems, but on the face of it, it seems like it should be made clearer.

### Section 6.1, time typedef

I was a little surprised you had to typedef time and day for yourself, I would have imagined there would be some well-known base types for these you could reference... but see my disclaimer. :-/

But since you did define your own time, I am curious if you think the definition is clear enough. Your description says,

      "The time type represents an instance of time of zero-duration
      in the specified timezone that recurs every day.";

It would seem desirable to provide a reference for the semantics instead of just relying on the reader to guess (through familiar usage, I suppose). Your regex looks close to, but not quite the same as, RFC 3339 §5.6's 'full-time'. The differences I can see offhand are that you don't permit lower-case 'z',  you restrict the range on the time-offset to +/- 14:00 whereas 3339 looks to permit the full +/- 23:59 range, and you make the TZ optional. The latter point means your current description doesn't really cover the possible range of inputs. I presume UTC is the default if TZ isn't specified, but you don't state this, and it's not the only imaginable option, e.g. I suppose an implementor might choose to use the local time zone if you leave it to their imagination.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Joseph Touch. Sent review to list. Submission of review completed at an earlier date.

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

The IANA Functions Operator has completed its review of draft-ietf-i2nsf-consumer-facing-interface-dm-26. If any part of this review is inaccurate, please let us know.

The IANA Functions 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-cons-facing-interface
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cons-facing-interface
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.

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-cons-facing-interface
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cons-facing-interface
Prefix: i2nsfcfi
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 Functions 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-03-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-i2nsf-consumer-facing-interface-dm@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 Consumer-Facing 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
Consumer-Facing 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 2023-03-16. 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 describes an information model and the corresponding
  YANG data model for the Consumer-Facing Interface of the Security
  Controller in an Interface to Network Security Functions (I2NSF)
  system in a Network Functions Virtualization (NFV) environment.  The
  information model defines various types of managed objects and the
  relationship among them needed to build the flow policies from users'
  perspective.  This information model is based on the "Event-
  Condition-Action" (ECA) policy model defined by a capability
  information model for I2NSF, and the YANG data model is defined for
  enabling different users of a given I2NSF system to define, manage,
  and monitor flow policies within an administrative domain (e.g., user
  group).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/


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

  https://datatracker.ietf.org/ipr/3554/
  https://datatracker.ietf.org/ipr/3604/
  https://datatracker.ietf.org/ipr/5749/
  https://datatracker.ietf.org/ipr/5694/

Shepherd Write-up for I2NSF Consumer facing Interface YANG Data Model (draft-ietf-i2nsf-consumer-facing-interface-dm-23)

(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?

Type: proposed standard
is it listed on the front page: yes

(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 describes an information model and the corresponding YANG data model for the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment.  The information model defines various types of managed objects and the relationship among them needed to build the flow policies from the users' perspective.

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.
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?

This information model is based on the "Event-Condition-Action" (ECA) policy model defined by a capability information model for I2NSF, and the YANG data model is defined for enabling different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain.
An open-source implementation around this work is found at https://github.com/jaehoonpaul/i2nsf-framework.  It has participated in a number of IETF Hackathons.

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 publication.

(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.

(5) Do portions of the document need review from a particular or from a 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 contents of the document will be shared with Ops Area Directorates.

(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.

(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.
Two IPRs have been disclosed since June 2019:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-i2nsf-consumer-facing-interface-dm

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

Two IPRs were disclosed against this document in June 2019 (https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-i2nsf-consumer-facing-interface-dm)
There was no issue with these two IPRs to let the IETF community use the technology in this document.

(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.)

None known.

(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

(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 (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes.  RFC 8805 was moved to Normative References, since this is appropriately called out as a DOWNREF in the IETF LC with no objection from the community, and it is needed to fully explain the semantics of the YANG model.

(16) Will the 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).

This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
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-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: nsfcfi
reference: RFC XXXX
// RFC Ed.: replace XXXX with an actual RFC number and remove
// this note.
       
(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-cfi-policy
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-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: nsfcfi
reference: RFC XXXX
// RFC Ed.: replace XXXX with an actual RFC number and remove this note.

(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 I2NSF Consumer facing Interface YANG Data Model (draft-ietf-i2nsf-consumer-facing-interface-dm-23)

(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?

Type: proposed standard
is it listed on the front page: yes

(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 describes an information model and the corresponding YANG data model for the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment.  The information model defines various types of managed objects and the relationship among them needed to build the flow policies from the users' perspective.

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.
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?

This information model is based on the "Event-Condition-Action" (ECA) policy model defined by a capability information model for I2NSF, and the YANG data model is defined for enabling different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain.
An open-source implementation around this work is found at https://github.com/jaehoonpaul/i2nsf-framework.  It has participated in a number of IETF Hackathons.

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 publication.

(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.

(5) Do portions of the document need review from a particular or from a 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 contents of the document will be shared with Ops Area Directorates.

(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.

(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.
Two IPRs have been disclosed since June 2019:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-i2nsf-consumer-facing-interface-dm

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

Two IPRs were disclosed against this document in June 2019 (https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-i2nsf-consumer-facing-interface-dm)
There was no issue with these two IPRs to let the IETF community use the technology in this document.

(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.)

None known.

(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

(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 (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes.  RFC 8805 was moved to Normative References, since this is appropriately called out as a DOWNREF in the IETF LC with no objection from the community, and it is needed to fully explain the semantics of the YANG model.

(16) Will the 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).

This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
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-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: nsfcfi
reference: RFC XXXX
// RFC Ed.: replace XXXX with an actual RFC number and remove
// this note.
       
(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-cfi-policy
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-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: nsfcfi
reference: RFC XXXX
// RFC Ed.: replace XXXX with an actual RFC number and remove this note.

(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 I2NSF Consumer facing Interface YANG Data Model (draft-ietf-i2nsf-consumer-facing-interface-dm-19)

(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?

Type: proposed standard
is it listed on front page: yes

(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 describes an information model and the corresponding YANG data model for the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment.  The information model defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective.

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.
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?

This information model is based on the "Event-Condition-Action" (ECA) policy model defined by a capability information model for I2NSF, and the YANG data model is defined for enabling different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain.
An open source implementation around this work is found at https://github.com/jaehoonpaul/i2nsf-framework.  It has participated in a number of IETF Hackathons.

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 publication.

(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.

(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 contents of the document will be shared with Ops Area Directorates.

(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.

(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.
Two IPRs have been disclosed since June in 2019:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-i2nsf-consumer-facing-interface-dm

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

Two IPRs were disclosed against this document in June 2019 (https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-i2nsf-consumer-facing-interface-dm)
There was no issue about these two IPRs to let the IETF community use the technology in this document.

(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.)

None known.

(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

(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 (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes.  RFC 8805 was moved to Normative References, since this is appropriately called out as a DOWNREF in the IETF LC with no objection from the community, and it is needed to fully explain the semantics of the YANG model.

(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).

This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
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-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: nsfcfi
reference: RFC XXXX
// RFC Ed.: replace XXXX with an actual RFC number and remove
// this note.
       
(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-cfi-policy
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-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: nsfcfi
reference: RFC XXXX
// RFC Ed.: replace XXXX with an actual RFC number and remove this note.

(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