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

[Lars Eggert <[e-mail]>]

Hi,

the text in Section 4.4 still talks about hostnames.

The example in Section 7 still doesn't use an RFC5737 example address.

Thanks,

Lars

On 11. May 2023, at 16:30, Mr. Jaehoon Paul Jeong <[e-mail]> wrote:



Lars,

Even though you are very busy, please take a look at the revision and take action on our Consumer-Facing Interface Data Model draft:

https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

This draft is the last I2NSF draft to be standardized.

Thanks in advance.

Best Regards,

Paul

On Tue, May 9, 2023 at 5:27 PM Mr. Jaehoon Paul Jeong <[e-mail]> wrote:

Hi Lars,

Let me remind you of your action on this draft:

https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

We authors believe that we addressed your comments as much as possible.

I hope this draft will move forward through your review and lifting up your block.

Thanks.

Best Regards,

Paul

On Fri, Apr 21, 2023 at 9:45 PM Mr. Jaehoon Paul Jeong <[e-mail]> wrote:

Hi Lars,
I sincerely appreciate your comment to improve our Consumer-Facing Interface YANG Data Model.

I have addressed your comments with the following revision:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-28" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-28

Also, two more revisions have been posted to address other comments from other ADs.
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-29" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-29

https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-29" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-30

I attach the revision letters.

If you have further questions and comments, please let me know.

Thanks.

Best Regards,
Paul

On Wed, Apr 12, 2023 at 6:43 PM Lars Eggert via Datatracker <[e-mail]> wrote:

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/" rel="noreferrer nofollow" target="_blank">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/" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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/" rel="noreferrer nofollow" target="_blank">https://www.sns-example1.com/" and "https://www.sns-" rel="noreferrer nofollow" target="_blank">https://www.sns-
         http://example2.com/" rel="noreferrer nofollow" target="_blank">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-" rel="noreferrer nofollow" target="_blank">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/" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments" rel="noreferrer nofollow" target="_blank">https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool" rel="noreferrer nofollow" target="_blank">https://github.com/larseggert/ietf-reviewtool



_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/i2nsf