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

[Paul Wouters via Datatracker <[e-mail]>]

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" ?