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

Hi Lars,
Let me remind you of your action on this draft:
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 <
jaehoon.paul@gmail.com> 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
>
> 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 <
> noreply@ietf.org> 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:alice@atlanta.com", "sip:bob@203.0.113.15", and
>>          "sip:carol@chicago.com" 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
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>