I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-32

[Ballot comment]
The latest version addresses the specific concerns that originated from Ben's DISCUSS. Ben's thoughts about a wider discussion are not something that I think would be prudent to discuss at this point in time.

[Ballot discuss]
In updating my ballot position for the -26 I am mostly just taking the
position from the -25 and trimming things that no longer apply.

I do, however, still feel that it is most important to have a conversation
about what the actual goals of the model are in terms of what type of
semantics we expect to be assigned to the different capabilities that a
NSF might claim.  Only once that topic is understood would we be in a
position to make concrete suggestions for the best way to express those
intended semantics in YANG.

Thanks for adding a note that the routing header condition capabilities indicates
only a core set of IPv6 routing headers, with some (e.g.) deprecated ones
being excluded.  What is the specific set of core routing headers that
are indicated, then?



Below appear the DISCUSS section from the -25, modified as described above
==========================================================================

The overall structure of this data model seems useful and well described.
I also think that the identified "core" set of capabilities to include in
this YANG module is a good starting set that will have broad applicability
(while still allowing extensibility as needed via standard YANG
mechanisms).  However, I'd like to have a discussion about whether the
individual capabilities are identified and described with sufficient
precision so that actual implementations will have identical expctations
of semantics and thereby achieve interoperability.

Do I have to support both IPv4 flags and TCP control bits in order to
claim support for "identity flags"?

Do I have to support both UDP and SCTP processing to claim support for
"identity length"?

Do I have to support both TCP and DCCP processing to claim support for
"identity offset"?

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with more precision, but I may be working
under flawed assumptions of the usage scenario.

The "transformation" capability for egress action seems under-defined as well
-- would a NSF claim this capability if it can perform a single type of
transformation?  What happens if the user wanted a different type of
transformation?

It is probably most prudent to have a general discussion about what level
of detail/precision we are expecting to include in this document, and only
then go and modify the corresponding parts of the document to be
compatible with that expectation.

[Ballot comment]
In updating my ballot position for the -26 I am mostly just taking the
position from the -25 and trimming things that no longer apply.
It is possible that I had some false negatives in trimming and left in
some comments that are no longer relevant; my apologies in advance, and
please just point out that the comment is already addressed.


Below appear the COMMENT section from the -25, modified as described above
==========================================================================

Thanks for expanding the security and privacy considerations sections in
response to my earlier review; it's much improved.

It seems to me that knowing the capabilities of a given NSF is necessary
but not sufficient in order to plan out a successful deployment that
utilizes those capabilities.  In particular, knowledge of where the NSF
lies in the (physical or virtual) network topology, or the ability to
adjust the topology as needed (as might be done in SDN or with a
service-function chaning architecture) is also necessary in order to know
which flows could actually be processed by a given NSF.  While the
specifics of the interaction with network topology are probably out of
scope for a data model for NSF capabilities, it still seems like we should
mention that there is a need to make this integration, which would ideally
be accompanied by a reference to a document that meets that need.  Right
now the word "topology" appears in this document only once, in the
security considerations section (as part of a statement that does not seem
to be supported by the rest of the document, no less).
[ed. that statement about "topology" got removed in the -26.  The core
issue described above seems to remain present.]


Section 3.1

                                            The set of capabilities
  provided by a given set of NSFs unambiguously defines the security
  services offered by the set of NSFs used.  [...]

This is probably more of a soapbox rant than an actionable comment, but
"unambiguously defines" is a very high bar.  If there is any kind of
vendor differentiation or quality-of-implementation differences, there may
be attributes not captured by the set of capabilities that still affect
the security services on offer.

Section 6

    identity device-type {
      description
        "Identity for device type condition capability. The capability
          for matching the destination device type.";

Why is the destination device given the unqualified name "device-type"?
Why would the source device type not also be of interest?
[ed. this got updated to also mention source device type.  In a certain
sense one might imagine a device having capability to match only one
one but not the other, akin to my DISCUSS point, though in this particular
case that seems likely to be rare]

    identity routing-header {
      base ipv6;
      description
        "Identity for IPv6 routing header condition
        capability";

The semantics of this identity (and several adjacent ones, really) seem
rather under-defined.  Does this mean that my NSF can recognize that there
is a RH present?  Or is the NSF expected to do some further parsing on it?
Which types of RH would the NSF be required to be able to parse if it
indicates this capability?  What if new RH types are allocated in the
future?

    identity options {
      base tcp;
      description
        "Identity for TCP options condition capability";

Similarly to the routing-header, what am I signifying if I claim this
capability?  TCP options are maintained in an IANA registry, so attempting
to claim support for all options is an open-ended task.

    identity transformation {
      base egress-action;
      description
        "Identity for transformation action capability";

Keeping with the theme, "transformation" is a very generic capability.  In
some cases the nature of the transformations that are or are not possible
will be very important to the user, but in this model an NSF has to either
claim the "transformation" capability or not claim it, leaving no room for
the subtleties that will be very important for actual deployments.

Closed request for Telechat review by INTDIR with state 'Withdrawn': Telechat deadline has passed... The document has been approved by the IESG. Please next time, be explicit and refuse to review the document. Thank you. -éric

[Ballot discuss]

Thanks for working on this data-model. It seems useful specification to have.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I would like to discuss the followings

  1. With RFC9000 and live traffic in the Internet it feels a bit odd to not mention QUIC as transport protocol. I initially thought it might have been part of UDP identity and capabilities. However, could not reason with that take as there will QUIC and UDP traffic mix and treating them same will not be the correct approach. I also think I am not the first one to notice that QUIC is missing and it might have been excluded with proper thoughts. In that case I would like to know more about it.

  2. With live 5G networks, a similar observation as above for "voip-volte-phone" identity and "voip-volte-filtering" identity. The term 'volte' makes this identity very much specific to a particular cellular network generation, LTE (4G). Even though the same network infrastructure for 'volte' can be and will be used to enable 5G voice, I didn't understood the reasoning behind a 'volte' specific identity and filtering. Was this intentional and the idea is to extend the data-model for all the cellular network generations when needed? I think the need is already now. Alternative would be to have the identity and filtering independent of cellular network generation. Has this been considered?

  3. I am not sure the high level of HTTPS identity and capabilities definition is good enough? We have multiple generations of HTTP and underlying transport protocol for those generations are not same, neither allows same kind of operations to be performed. for example, HTTP2 over TCP/TLS , with might allow termination of TLS context by the intermediaries, will not be true for HTTP3 over QUIC. I understand that the actual policy and conflict resolution is out of scope of this specification. However, I could not resist myself to think about a case where a policy rule may allow HTTPS traffic but blocks general UDP traffic. This would mean that HTTPS traffic with QUIC as transport protocol will be blocked, which might not be the intention at all. (Note that if QUIC traffic is blocked the clients will fall back to TCP/TSL as transport protocol(s).) I believe to be more functional the general HTTPs capabilities and rule need to be more granular and specific to HTTP generations. What is the thinking here?

[Ballot comment]

I had noticed couple of reference issues, those were also picked up by Martin and Francesca. I see the authors have already take care of those. Thanks for being prompt.

[Ballot comment]
DOWNREF [RFC8329] from this Proposed Standard to Informational RFC8329.

Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/RZKBK7ht9PrmIMC5VpMwaLohkc4).

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

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

"Table of Contents", paragraph 2, nit:
>  Registration for the Capabilities of a HTTP and HTTPS Flood Mitigator . . .
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour". (Also elsewhere.)

Section 1. , paragraph 2, nit:
> tomers. Multiple NSFs can be combined together to provide security services
>                              ^^^^^^^^^^^^^^^^^
"combined together" is redundant. Use "combined".

Section 3.1. , paragraph 3, nit:
> , respectively. These facilitate multi-vendor interoperability. * Automation:
>                                  ^^^^^^^^^^^^
This word is normally spelled as one.

Section 3.1. , paragraph 10, nit:
> r values in order to determine whether or not the set of actions in that (im
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 3.1. , paragraph 22, nit:
> firewall R2: During 7am-8pm, run anti-virus There is no conflict between the
>                                  ^^^^^^^^^^
This word is normally spelled as one. (Also elsewhere.)

Section 6. , paragraph 156, nit:
> er-id or user-name. The users can collected into a user-group and identified
>                                  ^^^^^^^^^
The modal verb "can" requires the verb's base form.

Section 6. , paragraph 169, nit:
> f the capabilities may entail privacy sensitive information as explicitly out
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen. (Also elsewhere.)

Document references draft-ietf-i2nsf-nsf-monitoring-data-model-12, but -14 is
the latest available revision.

Document references draft-ietf-i2nsf-nsf-facing-interface-dm-16, but -20 is the
latest available revision.

Document references draft-ietf-i2nsf-registration-interface-dm-13, but -14 is
the latest available revision.

[Ballot comment]
[S10.2; question]

* Should all of OODMP, OODOP, & OODSRP point to the "mediator-pattern" URL?

  Seems like:

    * OODOP -> https://www.oodesign.com/observer-pattern.html

  and

    * OODSRP -> https://www.oodesign.com/single-responsibility-principle.html

  is perhaps more appropriate.

[S6; comment]

  * RFC 8805 was published on the ISE stream, and is probably not suitable
    as normative reference (as an Informational reference that seems okay
    to me).

[Ballot discuss]
The overall structure of this data model seems useful and well described.
I also think that the identified "core" set of capabilities to include in
this YANG module is a good starting set that will have broad applicability
(while still allowing extensibility as needed via standard YANG
mechanisms).  However, I'd like to have a discussion about whether the
individual capabilities are identified and described with sufficient
precision so that actual implementations will have identical expctations
of semantics and thereby achieve interoperability.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with more precision, but I may be working
under flawed assumptions of the usage scenario.

Consider the resolution strategies as an example.  "First Matching" and
"Last Matching" are pretty straightforward, but where can I find a precise
specification of "Prioritized Matching Rule with Errors" or "Prioritized
Matching Rule with No Errors"?  I don't think I can find one in this
document, and I don't see any references given that would settle the
question either.

Similarly, if an NSF indicates the "routing-header" capability, what
specifically does that mean?  IPv6 routing headers are managed in an IANA
registry and this registry is seeing some recent activity, with SRH being
registered in 2020 and two CRH variants given temporary registrations in
2021.  Is it required to support all defined routing headers in order to
claim this capability?  Is that all headers defined at the time of this
writing, or at the time the claim is being made, or some other definition
of "all"?  Is it required to support deprecated routing header types like
source route ("RH0") and Nimrod?  If it suffices to only support any
single routing header type, then this is no longer an unambiguous
description of the feature.

As a couple more examples that I called out in my COMMENT section below,
support for HTTP will likely vary across major version of HTTP, and the
"transformation" capability for egress action seems under-defined as well
-- would a NSF claim this capability if it can perform a single type of
transformation?  What happens if the user wanted a different type of
transformation?

It is probably most prudent to have a general discussion about what level
of detail/precision we are expecting to include in this document, and only
then go and modify the corresponding parts of the document to be
compatible with that expectation.

[Ballot comment]
Thanks for expanding the security and privacy considerations sections in
response to my earlier review; it's much improved.

It seems to me that knowing the capabilities of a given NSF is necessary
but not sufficient in order to plan out a successful deployment that
utilizes those capabilities.  In particular, knowledge of where the NSF
lies in the (physical or virtual) network topology, or the ability to
adjust the topology as needed (as might be done in SDN or with a
service-function chaning architecture) is also necessary in order to know
which flows could actually be processed by a given NSF.  While the
specifics of the interaction with network topology are probably out of
scope for a data model for NSF capabilities, it still seems like we should
mention that there is a need to make this integration, which would ideally
be accompanied by a reference to a document that meets that need.  Right
now the word "topology" appears in this document only once, in the
security considerations section (as part of a statement that does not seem
to be supported by the rest of the document, no less).

Section 1

  *  Definition for resolution strategy capabilities of network
      security functions.

I didn't see discussion of the need for resolution strategies in the
framework (maybe I missed it), so we might want to have a bit of
exposition on how the need for it arises due to the other elements of the
framework and deployment reality.  Some of that content is already present
down in §3.2, but there doesn't seem to be an introductory remark that
this is extending past what the framework envisioned.

Section 3.1

  *  Automation: The system MUST have the ability to auto-discover,
      auto-negotiate, and auto-update its security capabilities (i.e.,
      without human intervention).  These features are especially useful

I assume that "auto-update" here is in the sense of "keep the central
database of NSF capabilities current" rather than "go fetch and apply
software patches".  If my assumption is correct, then we might refer to
its "capability registration", admittedly at the cost of the alliterative
"auto-"s.

  of capabilities that other I2NSF Components can use.  These
  capabilities MUST have their access control restricted by a policy;
  this is out of scope for this document.  [...]

Is the mechanics of the access control, the policy about which components
are granted which access, or both, what is out of scope?

                                            The set of capabilities
  provided by a given set of NSFs unambiguously defines the security
  services offered by the set of NSFs used.  [...]

This is probably more of a soapbox rant than an actionable comment, but
"unambiguously defines" is a very high bar.  If there is any kind of
vendor differentiation or quality-of-implementation differences, there may
be attributes not captured by the set of capabilities that still affect
the security services on offer.

  Technically, the "Policy Rule" is really a container that aggregates
  the above three clauses, as well as metadata, which describe the
  characteristics and behaviors of a capability (or an NSF).

Almost nit-like, but up here since it actually affects meaning: if the
thing that describes the characteristics and behaviors of a capability/NSF
is the metadata, then remove the comma after "metadata".

  Aggregating metadata enables a business logic to be used to prescribe
  a behavior.  For example, suppose a particular ECA Policy Rule
  contains three actions (A1, A2, and A3, in that order).  Action A2
  has a priority of 10; actions A1 and A3 have no priority specified.

This is the first time we've mentioned "priority"; it is not a good way to
introduce the topic.  In fact, this paragraph is the only place that the
word "priority" appears in the document (though "prioritized" does appear
in §5.1 and in the YANG model ... with no further description of how to
fulfil them).
Also, is the concept of being able to aggregate multiple pieces of
metadata the importent point here, or just the ability to associate
metadata with a policy at all?  I might rephrase slightly to use
"associate" in that case.

Section 3.2

  There is no conflict between the two policy rules R1 and R2, since
  the actions are different.  [...]

I don't think the actions just being "different" is enough to meet the
definition.  Is the intent to say that they act on different *objects*, or
that somehow they act on the same object "in the same way"?

  *  Resolution Strategies: They can be used to specify how to resolve
      conflicts that occur between the actions of the same or different
      policy rules that are matched and contained in this particular
      NSF;

I'm kind of curious how a conflict would arise between the actions of "the
same policy rule".  Isn't that just a badly written rule?
(There is similar text in §5, if any change is made here.)

Section 4

  Controller.  As described in [RFC8192], with the usage of
  Registration Interface and the YANG module in this document, the NSFs
  manufactured by multiple vendors can be managed together by the
  Security Controller in a centralized way and be updated dynamically
  by each vendor as the NSF has software or hardware updates.

As above, please clarify what is being updated in the scenario being
referred to (i.e., software on the device vs the registration information
at the security controller).

                          v                I2NSF
        +-----------------+------------+  Registration +-------------+
        | Network Operator Mgmt System |  Interface  | Developer's |
        | (i.e., Security Controller)  |<------------->| Mgmt System |
        +-----------------+------------+              +-------------+
                          ^                                New NSF
                          |                          Cap = {FW, WF}
            I2NSF        |                          E = {}
      NSF-Facing Interface |                          C = {IPv4, IPv6}
                          |                          A = {Allow, Deny}

I still think it would be useful to have some prose indicating that the "E
= {}" means that the event boolean will always evaluate to true.

Section 6

    identity system-event {
      [...]
    identity system-alarm {
      [...]
    identity time {
      [...]
    identity device-type {
      [...]
    identity geographic-location {
      [...]
    identity directional {

All of these identities are used as base identities for other identities.
Are any of them intended to also be used directly as their own identifier?
If not, then I think the description should use the phrase "base
identity".

    identity device-type {
      description
        "Identity for device type condition capability. The capability
          for matching the destination device type.";

Why is the destination device given the unqualified name "device-type"?
Why would the source device type not also be of interest?

    identity fragment-flags {
      base ipv4;
      description
        "Identity for IPv4 fragment flags condition capability";

I'm not aware of "fragment flags" being a common jargon to refer to the
'flags' field of the IPv4 header.

    identity routing-header {
      base ipv6;
      description
        "Identity for IPv6 routing header condition
        capability";

The semantics of this identity (and several adjacent ones, really) seem
rather under-defined.  Does this mean that my NSF can recognize that there
is a RH present?  Or is the NSF expected to do some further parsing on it?
Which types of RH would the NSF be required to be able to parse if it
indicates this capability?  What if new RH types are allocated in the
future?

    identity sctp {
      base transport-protocol;
      description
        "Identity for SCTP condition capabilities";
      [...]
    identity dccp {
      base transport-protocol;
      description
        "Identity for DCCP condition capabilities";

The TCP and UTP identities said they were "base identity" for the
respective condition capabilities.  Why are SCTP and DCCP different in
this regard?

    identity options {
      base tcp;
      description
        "Identity for TCP options condition capability";

Similarly to the routing-header, what am I signifying if I claim this
capability?  TCP options are maintained in an IANA registry, so attempting
to claim support for all options is an open-ended task.

    identity length {
      base tcp;
      base udp;
      description
        "Identity for matching TCP or UDP length condition capability.

Why is SCTP (DATA) chunk length not applicable here?  (I don't actually
know if DCCP has something analogous.)

    identity http {
      base application-protocol;
      description
        "The identity for Hypertext Transfer Protocol.";
      reference
        "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message
          Syntax and Routing
          RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics
          and Content";

This seems highly problematic.  HTTP/1.x, HTTP/2, and HTTP/3 are
completely different protocols and a device that can parse one should not
be expected to be able to parse any of the others.  Trying to conglomerate
support for "http" conditions in this manner seems doomed to result in
failure.

    identity pop3 {
      base application-protocol;
      description
        "The identity for Post Office Protocol 3. This includes
          POP3 over TLS";
      [...]
    identity imap {
      base application-protocol;
      description
        "The identity for Internet Message Access Protocol. This
          includes IMAP over TLS";

Why are pop3 and imap different from http, which gets distinct identities
for http-not-s and https?

    identity transformation {
      base egress-action;
      description
        "Identity for transformation action capability";

Keeping with the theme, "transformation" is a very generic capability.  In
some cases the nature of the transformations that are or are not possible
will be very important to the user, but in this model an NSF has to either
claim the "transformation" capability or not claim it, leaving no room for
the subtleties that will be very important for actual deployments.

    identity fmr {
      base resolution-strategy;
      description
        "Identity for First Matching Rule (FMR) resolution
          strategy capability";
    [...]
    identity lmr {
      base resolution-strategy;
      description
        "Identity for Last Matching Rule (LMR) resolution
          strategy capability";
    [...]
    identity pmr {
      base resolution-strategy;
      description
        "Identity for Prioritized Matching Rule (PMR) resolution
          strategy capability";
    [...]
    identity pmre {
      base resolution-strategy;
      description
        "Identity for Prioritized Matching Rule with Errors (PMRE)
          resolution strategy capability";
    [...]
    identity pmrn {
      base resolution-strategy;
      description
        "Identity for Prioritized Matching Rule with No Errors (PMRN)
          resolution strategy capability";

Where are the details of these resolution strategies specified?  "first
match" and "last match" are perhaps self-explanatory, but I am confident
that just relying on the string "Prioritized Matching Rule with No Errors
(PMRN)" with no reference or further explanation will result in divergent
implementation.

Section 9

  *  list nsf: The leak of this node to an attacker could reveal the
      specific configuration of security controls to an attacker.  An
      attacker can craft an attack path that avoids observation or
      mitigations; one may reveal topology information to inform
      additional targets or enable lateral movement; one enables the
      construction of an attack path that avoids observation or
      mitigations; one provides an indication that the operator has
      discovered the attack.

I don't understand what the "one" in the different clauses here refers to.
Is it supposed to be "one node" in the YANG tree?  But I don't remember
seeing specific nodes that provide these abilities if read access is
obtained by an attacker; could we name the specific nodes if that's the
case?

Also, separately, I don't think any of the nodes in *this* module provide
topology information.  My understanding is that topolgoy information would
have to come from a different source (likely a separate YANG module
implemented by the same system) and could be combined with the information
from this model in order to perform the indicated attacks.

  Some of the capability indicators (i.e., identities) defined in this
  document are highly sensitive and/or privileged operations that
  inherently require access to individuals' private data.  These are
  subtrees and data nodes that are considered privacy sensitive:
  [...]

I think that url-filtering-capability should also be listed here.
Perhaps NEW:
% * url-filtering-capability: URLs themselves often contain sensitive
%  information [CAPABILITY-URLS], and access to URLs typically comes
%  hand-in-hand with access to request and response content, which is
%  also often sensitive.
%
% [CAPABILITY-URLS]: https://www.w3.org/2001/tag/doc/capability-urls/

Section 10.2

I'm not sure what methodology was used to classify references as normative
vs informative.  E.g., RFC 6691 is cited in the same way that RFC 7323
is, but RFC 7323 is classified as normative and RFC 6691 is classified as
informative.  For reference, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
, the classification should be made solely on how the reference is used in
the document, with no dependence on the status or source of the
referred-to document.
For concreteness, I suggest that the classification of RFCs 2818 and 6691,
and [I-D.ietf-i2nsf-nsf-facing-interface-dm] and
[I-D.ietf-i2nsf-registration-interface-dm] be revisited.

  [OODMP]    "https://www.oodesign.com/mediator-pattern.html".

  [OODOP]    "https://www.oodesign.com/mediator-pattern.html".

  [OODSRP]  "https://www.oodesign.com/mediator-pattern.html".

I think the latter two were intended to point to
https://www.oodesign.com/observer-pattern.html and
https://www.oodesign.com/single-responsibility-principle.html
respectively.

NITS

Section 2

  This document follows the guidelines of [RFC8407], uses the common
  YANG types defined in [RFC6991], and adopts the Network Management
  Datastore Architecture (NMDA).  The meaning of the symbols in tree

Please reference RFC 8342 for NMDA.

Section 3

  This CapIM includes enabling a security controller in an I2NSF
  framework [RFC8329] to properly identify and manage NSFs, and allow
  NSFs to properly declare their functionality through a Developer's
  Management System (DMS) [RFC8329], so that they can be used in the
  correct way.

I think there's a word or two missing between "includes" and "enabling"
(perhaps "mechanisms for" or "provision for"?) -- the information model
itself does not include an element "enabling a controller to ...", rather,
the existince of the model (and other things build on it) enables the
controller to do these things.  Alternately, drop "includes" and go with
"this CapIM enables [...]".

Section 3.1

  *  Advertisement: Registration Interface
      [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to

"The Registration Interface"

  *  Execution: NSF-Facing Interface
      [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring

Likewise here, add "The".

      set of Message Exchange Patterns [Hohpe].  Registration Interface
      [I-D.ietf-i2nsf-registration-interface-dm] can register the

"The" here as well.

      capabilities of NSFs with the security controller from the request
      of Developer's Management System providing NSFs and the
      corresponding security capabilities.  Also, this interface can

Something seems awry here but I can't pick out the intended meaning so as
to suggest a fix.  Is the idea that the Developer's Management System
instigates a request and as a result of that request the list of relevant
NSFs and their respective security capabilities become available at the
security controller?  If so, a comma before "providing" would help, as
would some more description like "providing a list of available ... at the
security controller".

      whether it needs to invoke scaling or not.  NSF Monitoring
      Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe

"The NSF Monitoring Interface"

  or stored separately in a vendor's local repository.  In either case,
  Registration Interface can facilitate this update process to

"the Registration Interface"

  Developer's Management System to let the security controller update
  its repository for NSFs and their security capabilities.

I think we want s/to Developer's Management System to let/so the
Developer's Management System can let/

Section 4

  *  If a network administrator wants to block IPv4 or IPv6 packets
      from malicious users, the network administrator sends a security
      policy rule to block the users to the Network Operator Management
      System (i.e., Security Controller) using the I2NSF Consumer-Facing
      Interface.

The ordering of the clauses seems wrong here.  I think we want to say that
the network admin sends a security policy rule to the security controller,
and that rule says to block the users in question.  So we might consider
NEW:
% If a network administrator wants to block IPv4 or IPv6 packets
% from malicious users, the network administrator sends a security policy
% rule to the Network Operator Management System (i.e., Security Controller)
% using the I2NSF Consumer-Facing Interface, directing the system to block
% the users in question.

Section 5.1

  The context capabilities provide extra information for the condition.
  The given context conditions are application filter, target, user
  condition, and geographic location.  The application filter
  capability is capability in matching the packet based on the
  application protocol, such as HTTP, HTTPS, FTP, etc.  The device type
  capability is capability in matching the type of the destination
  devices, such as PC, IoT, Network Infrastructure devices, etc.  The
  user condition is capability in matching the users of the network by
  mapping each user ID to an IP address.  Users can be combined into
  one group.  The geographic location capability is capability in
  matching the geographical location of a source or destination of a
  packet.

A couple points.

The construction of "the  capability is capability in " is not
grammatical; it would be better as something like "the  capability is
the capability for" (other variants are possible that change the
conjugation of the following verb) (multiple instances).

The sentence about "users can be combined into one group" is potentially
confusing.  Is there only ever one group possible?  If there can be
multiple concurrent groupings defined, then something like "users can be
combined into groups" would be more accurate.

                                                              In
  addition, see Section 9.1 (Flow-Based NSF Capability
  Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in
  [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about
  logging at NSFs.

s/7.5/6.5/ (at least as of the -12 of the referenced draft)

Section 6

    identity system-event {
      base event;
      description
        "Identity for system event. System event (called alert) is

I suggest adding "sometimes" or "also" at the start of the parenthetical.

      description
        "Identity for CPU alarm. CPU is the Central Processing Unit
          that executes basic operations of the system. A cpu-alarm
          is emitted when the CPU usage is exceeding the threshold.";
      [...]
      description
        "Identity for disk alarm. Disk is the hardware to store
          information for a long period, i.e., Hard Disk and Solid-State
          Drive. A disk-alarm is emitted when the disk usage is
          exceeding the threshold.";

s/the threshold/a threshold/.  There is no one single definite threshold
that always applies; the threshold in question is either going to be
independently configurable or will vary across systems/implementations.

    identity voip-volte-phone {
      base device-type;
      description
        "Identity for voip-volte-phone";

I think we want "VOIP or VoLTE phone"; there isn't really a single
combined VOIP/VoLTE phone as a concept (even if modern premium smartphones
do offer seamless wifi/LTE calling).

Section 9

  *  list nsf: An attacker could alter the security capabilities
      associated with an NSF by disabling or enabling the functionality
      of the security capabilities of the NSF.

I'd suggest
NEW:
%  *  list nsf: An attacker could alter the security capabilities
%    associated with an NSF in the database maintained by the security
%    controller.  Such changes could result in security functionality
%    going unused due to the controller not having a record of it, and
%    could also result in falsely claiming security capabilities that the
%    controller would then attempt to use but would not actually be
%    provided.

[Ballot comment]
Thank you for the work put into this document. As I reviewed the -12 and as I am running out of time, I have focused my ballot on the changes between -12 and -25.

Thanks to the authors for including the information model (but see my review :( ...), the document should now have a logical flow from information to data model (this was part of my previous DISCUSS but Susan Hares and Diego Lopez had replied to me on this topic).

Thanks as well for handling SCTP now.

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 write-up including the section about the WG consensus and the IPR declarations, minor regrets: nothing is said about the 2nd IESG evaluation.

I hope that this helps to improve the document,

Regards,

-éric

## Section 3.1

This comment is probably for purists, but I wonder whether the automation & scalability (important operational requirements) should be requirements for an information model (as opposed to a data model).

And, the whole 'information model' section is not an information model :-( ... Please rename it as 'requirements' or something like that.

## Section 6 (YANG model)

'identity next-header': the text "Identity for the capability of matching IPv4 Protocol Field or equivalent to IPv6 Next Header.;" does not sound like a proper English sentence to me (I can obviously be wrong as I am not a native English speaker)

in the same identity, please use the right wording for the IANA registry (it does not include IPv4 in its name/title)

Should "identity identification" be renamed into "identity fragment-identification" ? And also applied to IPv6 as the IPv6 fragmentation extension header has this field ?

identity identity fragment-offset: there is a fragment offset field in the IPv6 fragmentation extension header... Does this identity also apply to IPv6 ?

should 'identity type' be renamed in icmp-type ? Same applies for 'code'

Suggest to s/traffic flow capability/traffic flow export capability/

For consistency, s/identity hop-by-hop/identity hop-by-hop-header/ and s/destination-options/destination-options-header/

I am puzzled by the limited list of application-protocols, i.e., DNS, NTP, ... are not included. Is there a need to have such a non-exhaustive list ?

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

I only have one minor comment:

Please update the references to RFC 7230, RFC 7231 and RFC 2818 with draft-ietf-httpbis-semantics-19 and draft-ietf-httpbis-messaging-19, which will obsolete them. Note that the HTTP drafts are with the RFC Editor in AUTH48, so will not delay publication of your document.

Francesca

[Ballot comment]
Please update the RFC4960 reference in Sec 6 to draft-ietf-tsvwg-rfc4960-bis-18.

For the ECN identity, it would be good to add RFC8311 as a reference as well. This is a standards-track RFC that clarifies the state of the ECT(1) bit.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version (draft-ietf-i2nsf-capability-data-model-21) is dated Nov 13, 2021.

(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 defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate.  The standards track is noted in the header of the document.

(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 defines an information model and the corresponding YANG data model for the capabilities of NSFs in the Interface to Network Security Functions (I2NSF) framework to manage the capabilities of the various NSFs centrally.


Working Group Summary:
This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document.

Document Quality:
This document is well-written and has gone through a number of working group and external reviews.
The YANG module itself validates without any warnings, and have passed YANG Doctor Review.
There have been IETF Hackathon implementation and Open-source implementation (https://github.com/jaehoonpaul/i2nsf-framework) for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Linda Dunbar
The Responsible Area Director is Roman Danyliw

(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.
I have read many versions of this document.  I feel this 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, I do not.

(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.
I don’t think so.

(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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns for this document.

(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?
Yes.  All authors replied.  These responses can be found in the archives of the I2nsf list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Consensus was strong with no vocalized dissension.

(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.)
Not to my knowledge.

(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 ID nits found during Shepherd review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication.

(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. All normative references are published RFCs.

(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, the YANG model described in the document has reference to RFC8805 which is an Informational RFC.

(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 WG considers it unnecessary.
No, it will not.

(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 8126).
This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]:
Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability
All the referenced IANA registries have been clearly identified by the document.

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

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
This document has passed the automated YANG check, which includes a number of validators.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The YANG module specified by the document has passed the validation and pass the YANG Doctor review.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version (draft-ietf-i2nsf-capability-data-model-21) is dated Nov 13, 2021.

(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 defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate.  The standards track is noted in the header of the document.

(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 defines an information model and the corresponding YANG data model for the capabilities of NSFs in the Interface to Network Security Functions (I2NSF) framework to manage the capabilities of the various NSFs centrally.


Working Group Summary:
This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document.

Document Quality:
This document is well-written and has gone through a number of working group and external reviews.
The YANG module itself validates without any warnings, and have passed YANG Doctor Review.
There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Linda Dunbar
The Responsible Area Director is Roman Danyliw

(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.
I have read many versions of this document.  I feel this 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, I do not.

(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.
I don’t think so.

(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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns for this document.

(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?
Yes.  All authors replied.  These responses can be found in the archives of the I2nsf list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Consensus was strong with no vocalized dissension.

(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.)
Not to my knowledge.

(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 ID nits found during Shepherd review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication.

(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. All normative references are published RFCs.

(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 WG considers it unnecessary.
No, it will not.

(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 8126).
This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]:
Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability
All the referenced IANA registries have been clearly identified by the document.

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

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
This document has passed the automated YANG check, which includes a number of validators.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The YANG module specified by the document has passed the validation and pass the YANG Doctor review.

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

The IANA Functions Operator has completed its review of draft-ietf-i2nsf-capability-data-model-21. 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-capability
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
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-capability
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
Prefix: nsfcap
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-11-29):

From: The IESG
To: IETF-Announce
CC: Linda Dunbar , draft-ietf-i2nsf-capability-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 Capability 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 Capability
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-11-29. 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 defines an information model and the corresponding YANG
  data model for the capabilities of various Network Security Functions
  (NSFs) in the Interface to Network Security Functions (I2NSF)
  framework to centrally manage the capabilities of the various NSFs.




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


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

  https://datatracker.ietf.org/ipr/3556/
  https://datatracker.ietf.org/ipr/3606/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8805: A Format for Self-Published IP Geolocation Feeds (Informational - Independent Submission)
    draft-ietf-tsvwg-udp-options: Transport Options for UDP (None - Internet Engineering Task Force (IETF))
    draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF Monitoring Interface YANG Data Model (None - Internet Engineering Task Force (IETF))
    draft-ietf-i2nsf-registration-interface-dm: I2NSF Registration Interface YANG Data Model (None - Internet Engineering Task Force (IETF))
    rfc4766: Intrusion Detection Message Exchange Requirements (Informational - Internet Engineering Task Force (IETF))

[Ballot comment]
Thanks for addressing my various comments.  Clearing my discuss.

One nit:

  identity ipv6-geo-ip {
    base ipv6-capability;
    description
      "Identity for IPv4 geography condition capability";

That should probably be "Identity for IPv6 geography..."

This is the second time that I2NSF WG sent the document to IESG.
When I2NSF WG closed the WGLC for  draft-ietf-i2nsf-capability-data-model in Dec 2019 (https://mailarchive.ietf.org/arch/browse/i2nsf/?q=draft-ietf-i2nsf-capability-data-model&f_from=Linda%20Dunbar ), there was a formative reference to draft-ietf-i2nsf-capability-05 which was stale. 

After the review, IESG decided to throw the draft back to I2NSF WG and requested the WG to reach the consensus to sunset the draft-ietf-i2nsf-capability-05. The WG finally reached the consensus in  Oct 2020  (https://mailarchive.ietf.org/arch/browse/i2nsf/?q=draft-ietf-i2nsf-capability-data-model&f_from=Linda%20Dunbar).

The authors have merged all the relevant content from draft-ietf-i2nsf-capability-05 and addressed all the comments from the YANG Doctor review.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate.  The standards track is noted in the header of the document.

(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 provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability].

Working Group Summary:
This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible.  The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document.

Document Quality:
This document is well-written and has gone through a number of working group and external reviews.
The YANG module itself validates without any warnings, and have passed YANG Doctor Review.
There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Linda Dunbar
The Responsible Area Director is Roman Danyliw

(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.
I have read this document and have provided feedback on previous revisions to the authors.  I feel this 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, I do not.

(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.
I don’t think so.

(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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns for this document.

(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?
Yes.  All authors replied.  These responses can be found in the archives of the I2nsf list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Consensus was strong with no vocalized dissension.

(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.)
Not to my knowledge.

(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 ID nits found during Shepherd review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication.

(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. All normative references are published RFCs.

(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 WG considers it unnecessary.
No, it will not.

(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 8126).
This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]:
Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability
All the referenced IANA registries have been clearly identified by the document.

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

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
This document has passed the automated YANG check, which includes a number of validators.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The YANG module specified by the document has passed the validation and pass the YANG Doctor review.

Based on preliminary feedback from the IESG in preparation for the September 24, 2020 telechat, this document was initially deferred (from this telechat).  After further discussion between the AD+I2NSF chairs, this document is being sent back to the WG to determine how to best resolve the dependency on the capabilities information model (i.e., draft-ietf-i2nsf-capability).

[Ballot discuss]
I support Benjamin's discuss on the lack of semantics. It is impossible to review the transport related parameters for correctness as they lack the semantics to understand if they do map to protocol values.

This discuss is more a place holder to be aware that this document needs to re-reviewed after having addressed by transport people.

[Ballot comment]
I support Eric's DISCUSS position about the information model vs. data model publications.

The smashed-together list of references at the top of Section 5 could use some formatting.

I tripped over several of the editorial points Barry found.  Here's one more.  In Section 3:

  o  If a network administrator wants to block malicious users for IPv6
      traffic, he sends a security policy rule to block the users to the
      Network Operator Management System using the I2NSF User (i.e., web
      application).

Block malicious users "for" IPv6 traffic?  I don't understand.  Perhaps "block IPv6 traffic from malicious users"?

[Ballot discuss]
There are many elements of the YANG module whose semantics seem
underspecified to me.  I noted quite a few in the COMMENT section, and I
hope that those aspects of my comments are clear (as it would be
substantial effort to partition the comments and move the questions of
unclear semantics into the discuss section), but I am happy to assist in
the classification if needed.

I think that the data nodes of this module as written are probably not
reflecting the intent -- it seems that the only elements of the 'nsf'
list are the string nsf-name; there is no "uses nsf-capabilities" stanza
to bring in the grouping that contains all the interesting parts.
Specifically, I do not see how the tree diagram reflects the current
module.

I'm surprised to not see any discussion of privacy considerations --
some of the features that we define capability indicators for are highly
sensitive and/or privileged operations (e.g., listening to VoIP/VoLTE
audio to identify individuals, web filtering) that inherently require
access to individuals' private data.  Not only should we note that
private information is made accessible in this manner, but we should
also reiterate that the nodes/entities given access to this data need to
be tightly secured and monitored, to prevent leakage or other
unauthorized disclosure of private data.

I also think we need to mention that authentication and proper
authorization will be needed to register as an NSF providing these
capabilities.

The examples do not seem to conform to the current module structure
(e.g., exact-fourth-layer-port-num and range-fourth-layer-port-num).

I worry a little bit that even the structure of the tree risks "imposing
functional requirements or constraints" upon NSF developers (in the
words of the framework).  How would, for example, SCTP capabilities be
indicated, let alone QUIC?  (With an augmentation, clearly, but is that
undue burden?)  While the classification into ingress/egress/log is
natural, it also may be found limiting; consider, for example, a setup
involving port mirroring -- is that an ingress action or egress?  If
traffic is dropped as part of a different ingress filtering capability,
does it still get sent to the port mirror?

[Ballot comment]
It's a little weird to have the data model be up for review when the
information model is still in AD Evaluation, but probably not
catastrophic.

Section 1

  As the industry becomes more sophisticated and network devices (e.g.,
  Internet of Things, Self-driving vehicles, and smartphone using Voice
  over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a

nit: missing verb for "network devices".

  registration interface [RFC8329].  With the capabilities of those
  security devices maintained centrally, those security devices can be

nit: I'd probably say that it's the knowledge of those capabilities or a
database of those capabilities that is maintained centrally.

  o  Definition for condition capabilities of generic network security
      functions.

  o  Definition for condition capabilities of advanced network security
      functions.

[I'm not yet sure at this point that I understand the need for
distinguishing between generic and advanced network security functions
... won't the boundary between those categories evolve over time?]

Section 3

  Framework.  As shown in this figure, an NSF Developer's Management
  System can register NSFs and the capabilities that the network
  security device can support.  To register NSFs in this way, the

nit: s/device/devices/

  That is, this Registration Interface uses the YANG module described
  in this document to describe the capability of a network security
  function that is registered with the Security Controller.  With the

nit: "capabilities" plural probably makes more sense in this context.

  capabilities of those network security devices maintained centrally,

[similar comment about "maintained centrally" as above]

  Note that the NSF-Facing Interface [RFC8329] is used to configure the
  security policy rules of the generic network security functions, and
  The configuration of advanced security functions over the NSF-Facing

nit: lowercase 'l' in "the".

  o  If a network administrator wants to block malicious users for IPv6
      traffic, he sends a security policy rule to block the users to the
      Network Operator Management System using the I2NSF User (i.e., web
      application).

I'm not entirely sure why only the IPv6 traffic of a malicious user
would be blocked.

Also, nit/edtiorial-level, "using the I2NSF Consumer-Facing Interface"
would read more naturally to me than "using the I2NSF User".

Section 4.1

  The NSF capabilities in the tree include time capabilities, event
  capabilities, condition capabilities, action capabilities, resolution
  strategy capabilities, and default action capabilities.  Those

In Section 1 we had a similar list that used "general capabilities"
compared to "time capabilities" here.  Is this distinction intentional?
(Given that the tree diagram and actual module use the "time" variant,
it's not entirely clear what the "general" variant would be...)

  repeated time like day, week, or month.  See Section 3.4.6
  (Capability Algebra) in [I-D.ietf-i2nsf-capability] for more
  information about the time-based condition (e.g., time period) in the
  capability algebra.

Following the reference, it seems to just use time-based condition as an
example of an arbitrary condition -- I don't see any specific discussion
that mentions considerations specific to time-based conditions.

  event and system alarm.  See Section 3.1 (Design Principles and ECA
  Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more
  information about the event in the ECA policy model.

(side note) I followed the reference and was surprised that I couldn't
find any specific indication that an Event of '{}' evaluates to true (at
least, I assume it does).

  advanced network security functions.  The condition capabilities of
  generic network security functions are defined as IPv4 capability,
  IPv6 capability, TCP capability, UDP capability, and ICMP capability.
  The condition capabilities of advanced network security functions are
  defined as anti-virus capability, anti-DDoS capability, Intrusion
  Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE
  capability.  See Section 3.1 (Design Principles and ECA Policy Model

At this point in the document I don't understand why VoIP and VoLTE are
fit to group together into a single capability.  Is the condition clause
just looking at a phone number and not other aspects of the call?

  the ingress and egress actions.  In addition, see Section 9.1 (Flow-
  Based NSF Capability Characterization) for more information about
  logging at NSFs.

[this is section 9.1 of [I-D.ietf-i2nsf-capability] still, though the
additional discussion on logging is fairly minimal.]

Section 5

In general there seems to be a lot of content in "reference" stanzas
that to my non-expert eye would have been more appropriate in the
"description" stanza.

  identity event {
    description
      "Base identity for I2NSF policy events.";

I note that draft-ietf-i2nsf-capability uses the phrase "I2NSF Event",
"I2NSF Policy", and "I2NSF Policy Rule" but not "I2NSF policy event",
which makes me suspect that this is an editorial error.
(draft-ietf-i2nsf-nsf-monitoring-data-model doesn't use "I2NSF policy
event", either.)

  identity hardware-alarm {
    base system-alarm-capability;
    description
      "Identity for hardware alarm";

How do I decide when to use hardware-alarm vs, e.g., memory-alarm or
cpu-alarm?

  identity condition {
    description
      "Base identity for policy conditions";
  }

Similarly to for events, draft-ietf-i2nsf-capability seems to only use
"I2NSF Condition", not "I2NSF policy condition".  In this case, the use
of "policy" does not feel as out of place to me as it did for events,
though.

  identity context-capability {
      [...]
    reference
      "draft-ietf-i2nsf-capability-05: Information Model of NSFs
      Capabilities - The operating context of an NSF.";
  }

I don't see the "the operating context of an NSF" in the referenced
draft, and in fact "context" is not used as a technical term at all.
(Similarly for "identity access-control-list"'s "The context of an NSF".)

  identity application-layer-filter {
    base context-capability;
    description
      "Identity for application-layer-filter condition capability";

This seems likely to be highly dependent on what exactly the application
layer is!  I'm not sure that such a generic capability will be useful in
practice.

  identity user {
    [...]
    reference
      "draft-ietf-i2nsf-capability-05: Information Model of NSFs
      Capabilities - A user in an application of a policy rule
      to be applied by an NSF.
      RFC 8519: YANG Data Model for Network Access Control Lists
      (ACLs) - An access control for a user (e.g., the
      corresponding IP address) in an NSF.";

I'm fairly concerned about implying that it's safe and effective to use
an IP address to identify a user.  While this works often enough that we
have stringent privacy considerations regarding storage/conveyance of IP
addresses in logs, in the context of automated network (security)
functions the risk of collatoral damage seems quite large.

  identity group {
    [...]
    reference
      "draft-ietf-i2nsf-capability-05: Information Model of NSFs
      Capabilities - A group (i.e., a set of users) in an
      application of a policy rule to be applied by an NSF.
      RFC 8519: YANG Data Model for Network Access Control Lists
      (ACLs) - An access control for a group (e.g., the
      corresponding IP address) in an NSF.";

An IP address can identify a group, too?

  identity geography {
    base context-capability;
    description
      "Identity for geography condition capability";
    reference
      "draft-ietf-i2nsf-capability-05: Information Model of NSFs
      Capabilities - A group (i.e., a set of users) in an
      application of a policy rule to be applied by an NSF.

I'm not sure what's going on here -- why are groups relevant for
geography?

      RFC 8519: YANG Data Model for Network Access Control Lists
      (ACLs) - An access control for a geographical location
      i.e., geolocation (e.g., the corresponding IP address) in
      an NSF.

RFC 8519 doesn't itself talk about geographic location.

      RFC 8805: A Format for Self-Published IP Geolocation Feeds
      - An IP address with geolocation information.";

I question the utility of self-published geolocation information for the
application of (security) policy -- my understanding is that this
reference was intended to avoid (among other things) the issue where the
IETF meeting network gets geolocated to the location of the previous
IETF meeting for the first couple days of the week, which is a
convenience/performance application, not a security one.

  identity ipv4-capability {
    base condition;
    description
      "Identity for IPv4 condition capability";

This identity is used as a base identity for other capabilities; is it
intended to also be used as a standalone capability?  If not, I suggest
including "base" in the description.  If so, please clarify what the
semantics are.

  identity ipv4-id {
    base ipv4-capability;
    description
      "Identity for identification condition capability";

(side note) I'd suggest making some mention of "fragment" or
"fragmentation" here, in light of RFC 6864.

  identity ipv6-capability {
    base condition;
    description
      "Identity for IPv6 condition capabilities";

[same as for ipv4-capability]

  identity exact-ipv6-flow-label {
    [...]
    reference
      "RFC 8200: Internet Protocol, Version 6 (IPv6)
      Specification - Flow Label";

RFC 6437 seems relevant as well.
(Similarly for range-ipv6-flow-label.)

  identity tcp-capability {
    base condition;
    description
      "Identity for TCP condition capabilities";

[same as for ipv4-capability]

  identity exact-tcp-seq-num {
    base tcp-capability;
    description
      "Identity for exact-match TCP sequence number condition
      capability";

It's not entirely clear to me why there is need to match on the TCP
sequence number, which per RFC 6528 should be effectively random from
the vantage of a stateless NSF device.

  identity exact-tcp-ack-num {
    base tcp-capability;
    description
      "Identity for exact-match TCP acknowledgement number condition
      capability";

Likewise, the ack number should be effectively random to a stateless
NSF.

  identity udp-capability {
    base condition;
    description
      "Identity for UDP condition capabilities";

[same as for ipv4-capability]

  identity icmp-capability {
    base condition;
    description
      "Identity for ICMP condition capability";

[ditto]

  identity icmpv6-capability {
    base condition;
    description
      "Identity for ICMPv6 condition capability";

[ditto]

  identity url-capability {
    base condition;
    description
      "Identity for URL condition capability";

[ditto]

  identity pre-defined {
    base url-capability;
    description
      "Identity for URL pre-defined condition capability";
  }

  identity user-defined {
    base url-capability;
    description
      "Identity for URL user-defined condition capability";
  }

With such sparse description and no reference, I have no idea what
functionality this is supposed to indicate.

  identity log-action-capability {
    description
      "Identity for log-action capability";

[same as for ipv4-capability]

  identity rule-log {
    base log-action-capability;
    description
      "Identity for rule log log-action capability";
  }

  identity session-log {
    base log-action-capability;
    description
      "Identity for session log log-action capability";
  }

[same as for pre-defined/user-defined]

  identity egress-action-capability {
    description
      "Base identity for egress-action capability";

Why does egress-action-capability get described as a "base identity" but
ingress-action-capability and default-action-capability do not?

  identity tunnel-encapsulation {
    base egress-action-capability;
    description
      "Identity for tunnel encapsulation action capability";

Given that there is more than one tunneling technology available (within
the IETF, even!), it's not really clear that this capability will be
useful.  If a node that only does IPsec wants to talk to a node that
only does VXLAN, there's not going to be much tunneling going on.

  identity voip-volte-capability {
    [...]
    reference
      "RFC 3261: SIP: Session Initiation Protocol
      RFC 8329: Framework for Interface to Network Security
      Functions - Advanced NSF VoIP/VoLTE security service
      capability";

RFC 8329 doesn't talk about "voice" or "VoLTE" at all.

  identity exception-application {
    [...]
    reference
      "RFC 8329: Framework for Interface to Network Security
      Functions - Advanced NSF Anti-Virus Exception Application
      capability";

RFC 8329 doesn't talk about "Anti-Virus Exception" at all (and it's not
a term I've encountered previously, so with no other reference I have
no idea what it's supposed to mean).
(Similarly for exception-signature.)

  identity voice-id {
    base voip-volte-capability;
    description
      "Identity for advanced NSF VoIP/VoLTE Voice-ID capability.
      This can be used for an extension point for VoIP/VoLTE
      Voice-ID as an advanced NSF.";

It sounds like this "voice-ID" is doing voiceprint analysis to identify
humans, which would have rather significant implications for the privacy
considerations of the system.

    reference
      "RFC 3261: SIP: Session Initiation Protocol
      RFC 8329: Framework for Interface to Network Security
      Functions - Advanced NSF VoIP/VoLTE Security Service
      capability";

[still no voice/VoLTE in 8329; I'm probably not going to catch all of
these]

      container generic-nsf-capabilities {
        description
          "Conditions capabilities.
          If a network security function has the condition
          capabilities, the network security function
          supports rule execution according to conditions of
          IPv4, IPv6, TCP, UDP, ICMP, ICMPv6, and payload.";

nit: the "and" implies that an NSF has to support all of those if any
condition capability is present, which I don't think is the intent.

      description
        "Default action capabilities.
        A default action is used to execute I2NSF policy rules
        when no rule matches a packet. The default action is
        defined as pass, drop, alert, or mirror.";

Does "alert" setill let the packet pass, or drop it?

Section 7

"ietf-i2nsf-capability" is not a data node; it's the module name.  (That
said, I don't really disagree with the assessment that all the nodes in
the module are sensitive, for the listed reasons.)

Also, I believe it's conventionally assumed that nodes sensitive for
write are also sensitive for read, and don't need to be listed again.

Section 8.1

RFCs 3444 and 8431 do not seem to be referenced anywhere in the document.

RFCs 3849 and 5737 may not need to be normative (we use the reserved
addresses for documentation but the reader doesn't need to rely on that
per se).

Appendix A.3

The figure lists only "user-defined" as an advanced capability but the
prose claims http and https inspection.

Appendix A.5

We don't seem to use the address of the NSF anywhere, so there doesn't
seem to be need to state what its address is assumed to be.  (This would
also render the RFC 5737 and RFC 3849 references unused.)

[Ballot discuss]
[ general ]

* At a high level, I'm slightly concerned about the state of the IP-geo
  aspects of this document.  It's not obvious to me what's desired (nor
  what may be achievable) here.

  [1] RFC 8805

  In section 5, there's a reference to 8805.  This document is an
  Independent Stream Editor's document, and not an IETF standard.  I don't
  know if that's technically disqualifying from being listed as a Normative
  reference or not.  Regardless, it certainly does not represent any formal
  industry consensus.

  [2] ipv4-geo-ip

  This references draft-ietf-i2nsf-capability, but I cannot find any
  discussion of IPv4 address geolocation in that document (admittedly I have
  not read it thoroughly).

  [3] ipv6-geo-ip

  I did not find an analogous geo-ip element for IPv6.  If there should be
  support for geolocation for one address family there should probably be
  support for the other.

[Ballot comment]
[[ comments ]]

[ section 1 ]

* This document describes a YANG model outlining a few more I2NSF
  documents than just i2nsf-capability, including:

    - i2nsf-nsf-monitoring-data-model
    - i2nsf-sdn-ipsec-flow-protection

  Indeed, this is noted in section 5.  I think it could help the reader
  when they get to section 4.1 if some earlier section also noted the
  more complete list of references that section 5 does.

[ section 4.1 ]

* ICMPv6 is notable by its absence from the list in the paragraph describing
  the "condition capabilities of generic network security functions".

[ section 5 ]

* The meaning of ipv6-protocol is not immediately obvious, and may be
  redundant with ipv6-next-header (the actual name of the header field).

  Or rather, does ipv6-protocol here mean IPv6 itself (as in the value
  "6" or "true" meaning 'is capable of')?

  Or does this mean the first non-IPv6-extension-header next-header value?


[[ nits ]]

[ section 1 ]

* "As the industry becomes more sophisticated and network devices (...),"
  This is not a grammatically complete clause.  Maybe just something like:

  "...and network devices (...) continue to proliferate, ..."

  or something.

[ section 3 ]

* "at a Developer's Management Systems" ->
  "at a Developer's Management System"

* "managing the capabilities of NSFs in this document" ->
  "managing the capabilities of NSFs as described in this document"?

* "network administrator ..., he sends" ->
  "network administrator ..., they send"

* "sends that security policy rules" ->
  "sends that security policy rule"

* "This lets an I2NSF User not consider NSFs where the rule is applied."

  I found this confusing.  Does it mean to say something like
  "...where the rule is not applicable"?

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

While I do appreciate that a data model (this document) is derived from an information model, I am concerned that the information model is an expired draft whereas I would expect the information model being published first. Else, what is the use of the information model ? What was the WG reasoning behind 'putting the cart before the horses' ? My concern is that by publishing the YANG model, there is nearly no way to change the information model anymore.

Please find below a couple of non-blocking COMMENT points but also a couple of blocking DISCUSS points around IPv6. They should be easy to resolve. I would hate to have NSF having basic IPv6 capabilities that cannot be configured by using the YANG model of this document.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4.1 --

It is quite common to apply conditions based on the whole IPv6 extension header chain (i.e., presence of destination option header or wrong order of the extension headers). Why is there no such capabilities in this YANG module ? The only one is 'identity ipv6-next-header' that applies only to the first extension header.

What is the difference between 'identity ipv6-protocol' and 'identity ipv6-next-header' ? There is no 'protocol' field in the IPv6 header.

While fragmented IPv4 packets are part of the conditions ('identity ipv4-fragment-flags'), there is no equivalent in IPv6.

[Ballot comment]
-- Section 4.1 --
May be am I misreading the YANG tree, but, I see no 'sctp-capability' in the set of 'condition-capabilities' (even is SCTP is not heavily used).

Is there a real reason to have two related containers ? generic-nsf-capabilities and advanced-nsf-capabilities. Why not a single one ?
   
Unsure what is meant by 'range' in 'identity range-ipv*-address'. Usually, addresses are filtered/matched by using a prefix length and not a range (that is difficult to implement in hardware).

Is there a reason why ICMP(v6) codes are not part of the conditions ?

[Ballot comment]
While most of these comments are editorial, some of them are dealing with text that's difficult to understand because of the editorial issues.  Please consider these:

— Section 1 —

  As the industry becomes more sophisticated and network devices (e.g.,
  Internet of Things, Self-driving vehicles, and smartphone using Voice
  over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a
  lot of problems described in [RFC8192].

This sentence seems a bit fractured.  What about network devices?  It looks like there’s something missing after the parenthetical.  Please re-work this sentence.

— Section 3 —

  This section provides as overview of how the YANG data model can be

Typo: “provides an overview”.

  The configuration of advanced security functions over the NSF-Facing
  Interface is used to configure the security policy rules of advanced
  network security functions (e.g., anti-virus and Distributed-Denial-
  of-Service (DDoS) attack mitigator), respectively, according to the
  capabilities of NSFs registered with the I2NSF Framework.

I don’t see what “respectively” refers to, as the sentence only talks about configuring one thing (“the security policy rules of advanced network security functions”).

Also, it seems odd to say “the configuration of … is used to configure …”.  Probably should fix that.


  o  If a network administrator wants to block malicious users for IPv6
      traffic, he sends a security policy rule to block the users to the
      Network Operator Management System using the I2NSF User (i.e., web
      application).

Please consider not making the network administrator male (“he”).


  o  When the Network Operator Management System receives the security
      policy rule, it automatically sends that security policy rules to
      appropriate NSFs

Change “rules” to singular “rule” to match the first half of the sentence.

— Section 7 —
You twice say “transport secure transport”, which should just be “secure transport”.

  o  ietf-i2nsf-capability: An attacker could alter the security
      capabilities associated with an NSF whereby disabling or enabling
      the evasion of security mitigations.

I don’t think “whereby” is the right word here, but I can’t figure out what you’re trying to say well enough to suggest what the right word is.  Maybe just “by”?  And I don’t know what it means to “disable the evasion of” something.  So this sentence needs some work, please.

  These are the subtrees and data
  nodes and their sensitivity/vulnerability:

Something’s missing here.  Maybe just “is”?  Maybe something else?

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

The IANA Functions Operator has completed its review of draft-ietf-i2nsf-capability-data-model-08. 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-capability
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
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. 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-capability
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
Prefix: nfscap
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,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-09-08):

From: The IESG
To: IETF-Announce
CC: draft-ietf-i2nsf-capability-data-model@ietf.org, dunbar.ll@gmail.com, rdd@cert.org, i2nsf@ietf.org, i2nsf-chairs@ietf.org, Linda Dunbar
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (I2NSF Capability 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 Capability
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 2020-09-08. 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 defines a YANG data model for the capabilities of
  various Network Security Functions (NSFs) in the Interface to Network
  Security Functions (I2NSF) framework to centrally manage the
  capabilities of the various NSFs.




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


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

  https://datatracker.ietf.org/ipr/3556/
  https://datatracker.ietf.org/ipr/3606/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8329: Framework for Interface to Network Security Functions (Informational - IETF stream)
    rfc8192: Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases (Informational - IETF stream)
    rfc790: Assigned numbers (Historic - Legacy stream)
    rfc3444: On the Difference between Information Models and Data Models (Informational - IETF stream)
    draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF Monitoring YANG Data Model (None - IETF stream)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate.  The standards track is noted in the header of the document.

(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 provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability].

Working Group Summary:
This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible.  The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document.

Document Quality:
This document is well-written and has gone through a number of working group and external reviews.
The YANG module itself validates without any warnings, and have passed YANG Doctor Review.
There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Linda Dunbar
The Responsible Area Director is Roman Danyliw

(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.
I have read this document and have provided feedback on previous revisions to the authors.  I feel this 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, I do not.

(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.
I don’t think so.

(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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns for this document.

(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?
Yes.  All authors replied.  These responses can be found in the archives of the I2nsf list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Consensus was strong with no vocalized dissension.

(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.)
Not to my knowledge.

(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 ID nits found during Shepherd review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication.

(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. All normative references are published RFCs.

(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 WG considers it unnecessary.
No, it will not.

(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 8126).
This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]:
Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability
All the referenced IANA registries have been clearly identified by the document.

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

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
This document has passed the automated YANG check, which includes a number of validators.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The YANG module specified by the document has passed the validation and pass the YANG Doctor review.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate.  The standards track is noted in the header of the document.

(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 provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability].

Working Group Summary:
This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible.  The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document.

Document Quality:
This document is well-written and has gone through a number of working group and external reviews.
The YANG module itself validates without any warnings, and have passed YANG Doctor Review.
There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Linda Dunbar
The Responsible Area Director is Roman Danyliw

(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.
I have read this document and have provided feedback on previous revisions to the authors.  I feel this 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, I do not.

(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.
I don’t think so.

(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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns for this document.

(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?
Yes.  All authors replied.  These responses can be found in the archives of the I2nsf list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Consensus was strong with no vocalized dissension.

(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.)
Not to my knowledge.

(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 ID nits found during Shepherd review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication.

(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. All normative references are published RFCs.

(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 WG considers it unnecessary.
No, it will not.

(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 8126).
This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]:
Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability
All the referenced IANA registries have been clearly identified by the document.

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

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
This document has passed the automated YANG check, which includes a number of validators.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The YANG module specified by the document has passed the validation and pass the YANG Doctor review.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate.  The standards track is noted in the header of the document.

(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 provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability].

Working Group Summary:
This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible.  The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document.

Document Quality:
This document is well-written and has gone through a number of working group and external reviews.
The YANG module itself validates without any warnings, and have passed YANG Doctor Review.
There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Linda Dunbar
The Responsible Area Director is Roman Danyliw

(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.
I have read this document and have provided feedback on previous revisions to the authors.  I feel this 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, I do not.

(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.
I don’t think so.

(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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns for this document.

(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?
Yes.  All authors replied.  These responses can be found in the archives of the I2nsf list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Consensus was strong with no vocalized dissension.

(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.)
Not to my knowledge.

(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 ID nits found during Shepherd review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication.

(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. All normative references are published RFCs.

(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 WG considers it unnecessary.
No, it will not.

(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 8126).
This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]:
Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability
All the referenced IANA registries have been clearly identified by the document.

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

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
This document has passed the automated YANG check, which includes a number of validators.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The YANG module specified by the document has passed the validation and pass the YANG Doctor review.