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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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

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
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-
<https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-29>
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/
> 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
>
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>