[I2nsf] Lars Eggert's Discuss on draft-ietf-i2nsf-consumer-facing-interface-dm-27: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-i2nsf-consumer-facing-interface-dm-27: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# GEN AD review of draft-ietf-i2nsf-consumer-facing-interface-dm-27

CC @larseggert

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

## Discuss

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

### Section 7.1, paragraph 7
```
     3.  The "https://www.sns-example1.com/" and "https://www.sns-
         example2.com/" URLs are labeled as "sns-websites".

     4.  The "sip:[e-mail]", "sip:bob@203.0.113.15", and
         "sip:[e-mail]" SIP identities are labeled as "malicious-
         id".
```
Use actual RFC2606 example domain names and RFC5737 example IP addresses.
Also in the XML in Figure 19 of course.

### Section 10.1, paragraph 43
```
     [MISPCORE] Dulaunoy, A. and A. Iklody, "MISP Core",
                commit 051e33b6711a660faf81733d825f1015aa0d301b, February
                2022, <https://github.com/MISP/misp-
                rfc/blob/051e33b6711a660faf81733d825f1015aa0d301b/misp-
                core-format/raw.md.html>.

     [OPENIOC]  Gibb, W., "OpenIOC 1.1 DRAFT",
                commit d42a8777708e171f8bdd3c2c9f8590c83488285d, August
                2013, <https://github.com/fireeye/OpenIOC_1.1/blob/
                d42a8777708e171f8bdd3c2c9f8590c83488285d/schemas/ioc.xsd>.
```
For discussion in the IESG. I don't think GitHub commits are appropriate
normative references.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## Comments

### DOWNREFs

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

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

### Inclusive language

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

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

## Nits

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

### Typos

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

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

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

### URLs

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

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

### Grammar/style

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Notes

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

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