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

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

Hi Dear Paul Wouters, John Scudder, Lars Eggert, and Éric Vyncke,
I sincerely appreciate your comment to improve our Consumer-Facing
Interface YANG Data Model.
Patrick and I have addressed your comments with the following revision:

https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-28

I attach the revision letter.

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

Thanks.

Best Regards,
Paul


On Wed, Apr 12, 2023 at 12:32 AM Paul Wouters via Datatracker <
[e-mail]> wrote:

> Paul Wouters 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:
> ----------------------------------------------------------------------
>
> I've read through the document. I feel that like some other I2NSF documents
> before, it incorporates partial IANA registries instead of referencing
> these IANA registries for their values. We had other I2NSF documents where
> this
> was changed to point to IANA registries. Is that something that is worth
> doing
> here? For example, the listing of services like telnet, pop3, pop3s, imap,
> imaps, ftp.
>
> Additionally, POP (with or without TLS) is very dead. So is IMAP without
> TLS. Why
> reference them in this document?
>
>
>         Also note that QUIC protocol [RFC9000] is excluded in the data
>         model as it is not considered in the initial I2NSF documents
>         [RFC8329]. The QUIC traffic should not be treated as UDP traffic
>         and will be considered in the future I2NSF documents.
>
> I understood that I2NSF is closing? So this statement is no longer true.
> What should be done with QUIC then?
>
>         The action could be one of "pass", "drop", "reject", "rate-limit",
>         "mirror", "invoke-signaling", "tunnel-encapsulation",
>         "forwarding", and "transformation".
>
> Why is it "drop" and "reject" versus "forwarding" and "transformation"?
> For consistency,
> would one not want to use either: drop, reject, forward, transform. Or:
> dropping, rejecting,
> forwarding, transforming" ?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Should section 6.1 have the IETF Trust template text added ?
>
> There is an entry for http (meaning 1.x) and http2, but not for http3 ?
> Any reason why not?
>
>    leaf language {
>       type string {
>         pattern
>                 [ 16 lines of sort of regexp ]
>
> I think this is overspecified and constraining. Probably best to be
> specified as a generic string.
>
>   leaf priority {
>         type uint8 {
>           range "1..255";
>         }
>
> Why is 0 excluded? Eg the priority for MX records can be 0. The Linux
> kernel IPsec SPD entry can be
> priority 0.
>
>
>         This field represents the configuration for an Antivirus.
>
> An antivirus what? I don't think you mean an anti-virus, eg a program
> that replicates itself to fight other viruses ? Maybe "Antivirus service" ?
> The term "Antivirus" is used a few time in this confusing context.
>
>    container anti-virus {
>           description
>            "A condition for anti-virus";
>
> Like here.
>
>         An NSF Capability model is proposed in
>         [I-D.ietf-i2nsf-capability-data-model] as the basic model for
>         both the NSF-Facing interface and Consumer-Facing Interface
>         security policy model of this document.
>
> Change "proposed" to "defined" as the other draft will go out as RFC
> at the same time as this one in one cluster.
>
>         Case (url-category):
>
> The name "url-category" seems odd. It seems to refer to a block or allow
> list for URLs?
>
>         This information describes a caller id or receiver id in order
>         to prevent any exploits (or attacks) of Voice over IP (VoIP)
>         or Voice over Cellular Network (VoCN).
>
> I don't understand what is meant with the sentence. Does Case (voice) list
> a contact
> information? Hoes does that "prevent any exploits" ?
>
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>