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 have reflected your comments on the revision of I2NSF Consumer-Facing
Interface YANG Data Model Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-31

I put my answers below with the prefix of [PAUL].

On Mon, May 15, 2023 at 6:50 PM Lars Eggert <[e-mail]> wrote:

> Hi,
>
> the text in Section 4.4 still talks about hostnames.
>
 => [PAUL] hostnames are removed for the URL-Group object.

>
> The example in Section 7 still doesn't use an RFC5737 example address.
>
 => This version uses only three IPv4 documentation address blocks such as
      192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
       If there are non-documentation addresses in this draft, please let
me know.

      Thanks a lot for the good feedback.

      Best Regards,
      Paul


> 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/
>
> 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/
>>
>> 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
>>>
>>> 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
>>>>
>>>