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

Lars,
Could you take action on this revision according to your comments?
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-31

Thanks in advance.

Best Regards,
Paul

On Mon, May 15, 2023 at 10:40 PM Mr. Jaehoon Paul Jeong <
jaehoon.paul@gmail.com> wrote:

> 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 <lars@eggert.org> 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 <jaehoon.paul@gmail.com>
>> 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 <
>> jaehoon.paul@gmail.com> 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 <
>>> 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
>>>>>
>>>>