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

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

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

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.

Thanks for addressing my discuss points.

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) <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml>

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 ?

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.

Thanks for addressing my DISCUSS and comments.