Re: [I2nsf] AD Review of draft-ietf-i2nsf-consumer-facing-interface-dm-23

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

Hi Roman,
Did you have a chance to review my revision of Consumer-Facing Interface and
Registration Interface YANG data model drafts?
- Consumer-Facing Interface:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

- Registration Interface:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/

We need to get these two drafts out and take the next action for I2NSF WG
early next year.

Thanks and have a happy new year.

Best Regards,
Paul

On Thu, Dec 1, 2022 at 11:47 PM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> Roman,
> I see.
>
> I hope these two drafts will be reviewed by the IESG by the end of this
> year.
>
> Thanks for your help.
>
> Best Regards,
> Paul
>
> On Thu, Dec 1, 2022 at 11:42 PM Roman Danyliw <[e-mail]> wrote:
>
>> Hi Paul,
>>
>>
>>
>> With the US Thanksgiving holiday last week and a full telechat this week
>> I have not yet had time to look at either this or the registration document.
>>
>>
>>
>> Regards,
>>
>> Roman
>>
>>
>>
>> *From:* I2nsf <[e-mail]> *On Behalf Of * Mr. Jaehoon Paul
>> Jeong
>> *Sent:* Thursday, December 1, 2022 9:35 AM
>> *To:* Roman Danyliw <[e-mail]>
>> *Cc:* [e-mail]; skku-iotlab-members <
>> [e-mail]>; Patrick Lingga <
>> [e-mail]>; Mr. Jaehoon Paul Jeong <[e-mail]
>> >
>> *Subject:* Re: [I2nsf] AD Review of
>> draft-ietf-i2nsf-consumer-facing-interface-dm-23
>>
>>
>>
>> Hi Roman,
>>
>> If you are satisfied with this revision, could you put this
>> Consumer-Facing Interface draft into the IESG telechat agenda?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Best Regards,
>>
>> Paul
>>
>>
>>
>> On Tue, Nov 8, 2022 at 5:45 PM Mr. Jaehoon Paul Jeong <
>> [e-mail]> wrote:
>>
>> Hi Roman,
>>
>> Here is the revision of Consumer-Facing Interface YANG Data Model:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-24
>>
>>
>>
>> Patrick and I have addressed all your comments.
>>
>> I attach the revision letter.
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Best Regards,
>>
>> Paul
>>
>>
>>
>> On Mon, Oct 24, 2022 at 3:03 AM Roman Danyliw <[e-mail]> wrote:
>>
>> Hi!
>>
>> I performed my AD review of
>> draft-ietf-i2nsf-consumer-facing-interface-dm-23.  Thanks for the work on
>> this information/data model.  Below is my feedback:
>>
>> ** Section 1.  Could a sentence or two here to explain what the Security
>> Controller, the recipient of the Consumer-Facing Interface, does with this
>> configuration information?
>>
>> ** Section 1.  Since the architecture and reference model of RFC8329 is
>> being used, please provide bridging text to explain that "Security
>> Controller" used in this document is equivalent to a "Network Operator
>> Management System" (used in RFC8329).
>>
>> ** Section 1.
>>    Assuming that vendors also provide the
>>    front-end web applications to an I2NSF User, the Consumer-Facing
>>    Interface is required because the web applications developed by each
>>    vendor need to have a standard interface specifying the data types
>>    used when the I2NSF User and Security Controller communicate with
>>    each other using this interface.
>> ...
>> The Consumer-Facing Interface would be built using a set of objects,
>>    with each object capturing a unique set of information from Security
>>    Administrator (i.e., I2NSF User [RFC8329])
>>
>> I'd like to clear up ambiguity on who is an "I2NSF User"?  Is it a "user"
>> as in a human? Is it vendor provided tooling which converts user input into
>> this standardized YANG module and sends it via the Consumer Interface to a
>> controller?  Or is a "I2NSF User" both?
>>
>> -- In this text there are references to "vendors ... provid[ing] the
>> front-end web applications to an I2NSF User", implying that "I2NSF User" is
>> a human, and the tooling to generate the YANG module is NOT part of the
>> "I2NSF user"
>>
>> -- This text also seems to equate a "Security Administrator", a human, to
>> be being the "I2NSF User".
>>
>> -- Section 3.1 of RFC8329 gives examples of "I2NSF Consumers" (not "I2NSF
>> users") to be "video conference network management system", "enterprise
>> network administrator and management systems", and "IoT management system"
>> which seems to imply that it is both.  Figure 1 above this text seems to
>> depict a flow between the I2NSF user directly to the Security Controller.
>> Therefore, unless a human is directly crafting YANG, there is likely some
>> supporting technology that is considered the "I2NSF user".
>>
>> -- Section 6.1 of RFC8329 says "As a general principle, in the I2NSF
>> environment, users directly interact with the I2NSF Controller."
>>
>> ** Section 1.
>>    These policies can easily be
>>    translated by the Security Controller into low-level security
>>    policies.
>>
>> I'm not sure it makes sense to characterize the policy translation as
>> "easy".
>>
>> ** Section 3.  Editorial.
>> OLD
>>    A Policy object represents a mechanism to express a Security Policy
>>    by Security Administrator (i.e., I2NSF User) using Consumer-Facing
>>    Interface toward Security Controller; the policy would be enforced on
>>    an NSF.
>>
>> NEW
>> A Policy object is a means to express a Security Policy set by a Security
>> Administrator (i.e., I2NSF User) with the Consumer-Facing Interface.  It is
>> sent to the Security Controller which converts it into an NSF-specific
>> configuration via the NSF-facing interface for enforcement on the NSF.
>>
>> ** Section 3.  Editorial.
>> OLD
>> The resolution strategy is described in
>> [I-D.ietf-i2nsf-capability-data-model] in detail.
>>
>> NEW
>> The resolution strategy is described in Section 3.2 of
>> [I-D.ietf-i2nsf-capability-data-model].
>>
>> ** Section 3.
>>             1) communication between two Endpoint Groups,
>>              2) for preventing communication with externally or
>>              internally identified threats, and 3) for implementing
>>              business requirement such as controlling access to internal
>>              or external resources for meeting regulatory compliance or
>>              business objectives.  An organization may restrict certain
>>              communication between a set of user and applications for
>>              example.
>>
>> -- What is an "endpoint group"?  It's explained later but not in this
>> point in the document.  Please add a forward reference.
>>
>> -- Per (3), isn't this entire interface about encoding "implementing
>> business requirements"?
>>
>> ** Section 3.
>>             The threats may be from threat feeds obtained
>>              from external sources or dynamically identified by using
>>              specialty devices in the network.
>>
>> I didn't see a mechanism in the text for this dynamic identification.
>> The definitely of threat sources later in the document seems to reinforce
>> the idea that this is externally sourced information.
>>
>> ** Section 3.
>>           Rule conflict analysis
>>           should be triggered by the monitoring service to perform an
>>           exhaustive detection of anomalies among the configuration
>>           rules installed into the security functions.
>>
>> -- Does the "rule conflict analysis" happen on the Security Controller?
>>
>> -- Please say more about the "monitoring service"
>>
>> -- Please say more about "detecting anomalies".  Is this more than "rule
>> conflict[s]"?
>>
>> ** Section 3.
>>
>> A policy is a list of rules.
>>
>> The text prior and Figure 2, just explained how a policy is much more
>> than a rule.  Should it say, "A policy will contain a list of rules."
>>
>> ** Section 3.
>>    A Policy Rule may be related segmentation,
>>    threat mitigation or telemetry data collection from an NSF in the
>>    network, ...
>>
>> This sentence doesn't parse but I don't understand it enough to provide
>> an alternative.
>>
>> ** Section 3.
>>  Event:    This field includes the information to determine whether
>>            the Rule Condition can be evaluated or not.  See details in
>>            Section 3.1.
>>
>> What is the relationship between the Event and the rule Condition.
>> Section 3.1 seems to provide means to specify which system events and
>> alarms are applicable, but it doesn't appear to have a dependency on the
>> Condition and seems to be describing if the entire Rule should trigger.
>>
>> ** Section 3.
>>
>>     This field contains all the checking conditions to apply
>>      to the objective traffic.
>>
>> Please restate to clarify "objective traffic" (vs. just traffic) and
>> "checking conditions".
>>
>> ** Section 3.1
>>
>>    The Rule could be activated based on a security event (i.e., system
>>    event and system alarm).
>>
>> This text states that that a "Rule _could_ be activated ...", suggesting
>> that there is an alternative way to activate it.  Figure 4 doesn't seem to
>> suggest that.  Should it read "The Rule is activated ..."?
>>
>> ** Section 3.2
>>    This object represents Conditions that Security Administrator wants
>>    to apply the checking on the traffic in order to determine whether
>>    the set of actions in the Rule can be executed or not.  The Condition
>>    Sub-model consists of three different types of containers each
>>    representing different cases, such as general firewall and DDoS-
>>    mitigation cases, and a case when the condition is based on the
>>    payload strings of packets.
>>
>> -- The Condition model appears to have 8 different types of containers,
>> not 3.
>>
>> -- This sentence would benefit from editorial polish.  Consider:
>>
>> NEW
>> The Condition object describes the network traffic pattern or fields that
>> must be matched against the observed network traffic for the rule to
>> trigger.  The fields used to express the required conditions to triggers
>> the rule are organized around the class of NSFs expected to be able to
>> observe or compute them.
>>
>> ** Section 3.2
>>    Each containers have source and
>>    destination-target to represent the source and destination for each
>>    case.
>>
>> This statement seems only accurate for "container firewall".  For example
>> "container ddos" and "anti-virus" (and a few others) doesn't seem have a
>> source and destination.
>>
>> ** Section 3.2
>>    This field represents the general firewall case,
>>    where a security admin can set up firewall conditions using
>>    the information present in this field.
>>
>> What is a "general firewall case"?  Is this equivalent to saying that
>> that the Security Administrator wants to describe network traffic with
>> layer 3 or 4 header fields?  Currently, the text is restating the name of
>> the container as the description.
>>
>> ** Section 3.2.  Per the ddos and anti-virus cases, please re-write this
>> text to describe what each is doing.  Currently, the text is restating the
>> name of the container.  Specifically, "This field represents the "condition
>> for <name of container>, where a security amin can setup a <name of the
>> container> condition using the information presented in this field."
>> Please also expand security admin.
>>
>> ** Section 3.  Per the payload case:
>>     This field contains the payload string information.
>>     This information is useful when security rule condition is
>>     based on the string contents of incoming or outgoing
>>     packets.
>>
>> Recommend not using the term "string" since the data model says this is
>> binary and many payloads are likely to be that too.
>>
>> ** Section 3.  Per the payload case:
>>    The name referring to the payload-groups defined
>>    and registered in the endpoint-groups.
>>
>> This sentence doesn't parse.
>>
>> ** Section 3.  Per the voice case:
>> .  This information can be
>>    used to filter 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).
>>
>> No disagreement on the possibility describe here.  However, isn't filter
>> only one of a number of actions that could be taken.  Why call out "filter"
>> here?
>>
>> ** Section 3.  Per the context case:
>>    This field provide extra information for the
>>    condition for filtering the network traffic.
>>
>> Please re-phrase this as the sentence doesn't parse.
>>
>> ** Section 3.  Per the context case:
>>    This field contains the information obtained
>>    from threat-feeds (e.g., Palo-Alto, or RSA-netwitness).
>>
>> --  Consider if you need to name the products as this might age the
>> document in the future.  If so, please name them consistently.  "Palo-Alto"
>> is a company, not a product, which doesn't hyphenate their name.
>> "RSA-netwitness" is "RSA Netwitness".
>>
>> -- Additionally, why name these two vendors, instead of the three
>> products/tools actually mentioned in the data model?
>>
>> ** Section 3. Per the context case:
>>        This information is useful when security rule condition is
>>        based on the existing threat reports gathered by other
>>        sources.
>>
>> Shouldn't this read, "This field is used when the security ..."
>>
>> ** Section 3.3.  Per Figure 6, it looks like specifying the both the
>> primary and secondary action could be empty.  Is that intended?
>>
>> ** Section 4.
>>    The Policy Endpoint Group is a very important part of building User-
>>    Construct based policies.
>>
>> What are "User-Construct based policies" as opposed to just "policies"?
>>
>> ** Section 4.
>>    It is assumed that the information of Endpoint Groups (e.g., User-
>>    group, Device-group, and Location-group) such as the IP address(es)
>>    of each member in a group are stored in the I2NSF database available
>>    to the Security Controller,
>>
>> -- What is an "I2NSF database"?  This is not an architectural entity
>> described in RFC8329.
>>
>> -- What does it mean the "information of Endpoint Groups such as xxx are
>> stored in the I2NSF database ..."?  Isn't this information that is being
>> sent by the I2NSF User to the Security Controller?
>>
>> -- What is the interrelationship between user-group and the url-list?
>> The former lists IP addresses and the latter is list of URLs.  Are those IP
>> address hosting those URLs?  From the examples in Section 8, it looks like
>> there is no relationship between them, but that isn't stated here.
>>
>> ** Section 4.1.  Can a "User Group" please be defined.  The definition of
>> "This object represents a User-Group" just repeats the name.  The
>> description of the field names suggests they are an address range for a
>> "user in the user group".  Where does the user information come from?  From
>> the example in Section 8, it appears that this field groups is a means to
>> label an IP address block.
>>
>> ** Section 4.3.
>>   This object represents a location group based on either tag or other
>>   information.
>>
>> What is the "tag" reference here?
>>
>> ** Section 4.3.  Geo-ip-ipv4 and Geo-ip-ipv6 are citing RFC8805.  My
>> understanding of that specification is that it provides a way to bind a
>> geographic name to an IP address.  I don't see anything in the Location
>> object that ties a human readable geographic label to an IP address.  Is
>> the related geography in the Name field?
>>
>> ** Section 4.4.
>>    url:      This field represents the new URL added by a user to the
>>              URL database.
>>
>> -- What is user is being referenced here?
>>
>> -- What is a "URL database"?
>>
>> ** Section 5.  Even with the detailed descriptions in Section 5.1. and
>> 5.2, it isn't clear what the relationship is between the information in the
>> thread-feed and the payload-content objections.  Does the thread-feed
>> describe the malicious activity and the payload-content is a capture of
>> what it looks like on the wire?
>>
>> ** Section 5.
>> OLD
>>    The threat prevention plays an important part in the overall security
>>    posture by reducing the attack surfaces.  This information could come
>>    from various threat feeds (i.e., sources for obtaining the threat
>>    information).
>>
>> NEW
>> The Threat Prevention model describes information obtained from threat
>> feeds (i.e., sources for obtaining the threat
>>    information).
>>
>> ** Section 5.1.
>>
>> Description:  This is the description of the threat feed.  The
>>              description should have the clear indication of the
>>              security attack such as attack type (e.g., APT) and file
>>              types used (e.g., executable malware).
>>
>> Editorial.  I found the naming convention a bit confusing.  In my
>> experience, a thread feed is sometimes a list of indicators of compromise
>> (IOC) tied to a particular threat (e.g., one feed for a list of domains
>> names or file hashes tied to a given threat actors).  Other times, it is a
>> series of "objects" (IOCs, descriptions, rules) which are a collection of
>> malicious activity, not necessarily related, which capture one publisher's
>> aggregated view of what threat to watch for.  This description seems to
>> assume it is only the former.  This would be worth explaining.
>>
>> ** Section 5.1 and Yang threat-prevention/description.  The description
>> needs further specification.
>> Information model says:
>>    Description:  This is the description of the threat feed.  The
>>              description should have the clear indication of the
>>              security attack such as attack type (e.g., APT) and file
>>              types used (e.g., executable malware).
>>
>> Yang says:
>>            leaf description {
>>              type string;
>>              description
>>                "This represents the descriptions of a threat-feed.  The
>>                 description should include information, such as type,
>>                 threat, method, and file type.  Structured Threat
>>                 Information Expression (STIX) can be used for
>>                 the description of a threat.";
>>              reference
>>                "STIX: Structured Threat Information Expression for the
>>                 description of a threat.";
>>            }
>>
>> -- It isn't clear how this field (description) can be a "clear
>> indication" without providing a structured format for each of the required
>> fields.  While STIX is mentioned, it doesn't appear to be required.
>>
>> -- If STIX is preferred or suggested, please be clear on which STIX
>> objects should be used.  Is it STIX XML or JSON?
>>
>> -- Please provide a reference to STIX
>>
>> -- Is the intent to represent an XML blob in the string data type here?
>> Is it up to the implementer to recognize free form text vs. JSON vs. XML?
>>
>> ** Section 5.1.
>>
>> Signatures: This field contains the threat signatures of malicious
>>              programs or activities provided by the threat-feed.  The
>>              examples of signature types are "YARA", "SURICATA", and
>>              "SNORT" [YARA][SURICATA][SNORT].
>>
>> I'm confused by this description as I can't find where in this field the
>> "threat signatures of malicious programs" is represented.  This field
>> appears to be conveying an enumerated type.
>>
>> ** Section 5.1.
>>              "Signatures" should be
>>              kept carefully in a secure manner.  The secure keeping of
>>              "Signatures" can be performed by Defense in Depth (DID)
>>              [DID] or Distributed Ledger Technology (DLT) such as
>>              Blockchain [Bitcoin].  The details of keeping "Signatures"
>>              securely are out of scope in this document.
>>
>> -- Per the caution of keeping signature in a "secure manner"?  What
>> additional security properties or controls is that suggesting beyond
>> everything else in the data model?  Put in another way, what's special here?
>>
>> -- What does it mean to say that "signature can be performed ..."  Given
>> that this is out of scope, I recommend just dropping the sentence.
>>
>> ** Section 5.1.
>>
>>    With the
>>    obtained threat signatures, the I2NSF User can deliver them to the
>>    Security Controller.
>>
>> How are these signatures being delivered to the controller? Is it with
>> this Yang module?
>>
>> ** Section 5.1.
>>    Note that signature-set in I2NSF Capability
>>    [I-D.ietf-i2nsf-capability-data-model] is the setting of signatures,
>>    which means the configuration of signatures for Intrusion Prevention
>>    System (IPS).  On the other hand, signature-type in Consumer-Facing
>>    Interface is the type of signatures (e.g., YARA signatures, SNORT
>>    signatures, and Suricata signatures).
>>
>> -- Can the text "setting of the signatures" be rephrased, as I don't
>> understand what it means.
>>
>> -- From this text it isn't clear what link is being drawn between the
>> capability model and this data model.
>>
>> ** Section 5.2.
>>
>>    This object represents a custom list created for the purpose of
>>    defining an exception to threat feeds.
>>
>> Can you please clarify, what is an "exception to the threat list"? Is
>> that something that is on the thread list but should be ignored?
>>
>> ** Section 5.2
>> This represents the description of how the payload
>>              content is related to a security attack.
>>
>> Is the referenced "security attack" the one described it the name field?
>> Does this imply additional requirements for the semantics of the name field?
>>
>> ** Section 5.2.
>>    Content:  This contains the payload contents, which are involed in a
>>              security attack, such as strings.
>>
>> -- Typo. s/involed/involved/
>>
>> -- What are "strings" in the context of the payload contents?  Do you
>> mean "strings" as in those dumped from a malware file?  Readable text
>> extracted from a session stream?
>>
>> ** Section 6.  Thanks for explaining the role of NACM.  Is this guidance
>> specific to the I2NSF interface or a generic example of using NACM?  Ask
>> because, I didn't see anything specific to I2NSF here.  Was there a WG push
>> to include this non-I2NSF guidance? Section 11 already says that NACM can
>> be used.
>>
>> ** Section 6.
>>    Then, the
>>    user can simply use an account of root or admin user for the access
>>    control for the module of the I2NSF Consumer-Facing Interface
>>
>> What is the origin of these users names?
>>
>> ** Section 7.  Typo. s/provide the YANG data model of I2NSF/provide the
>> YANG data model of the I2NSF/
>>
>> ** Section 7.
>>    The transformation of the
>>    information model is performed so that this YANG data model can
>>    facilitate the efficient delivery of the control or management
>>    messages.
>>
>> This statement doesn't seem right.  Per RFC3444 cited in Section 1,
>> informational models "are protocol neutral".  That is, they are not capable
>> of being interoperable without translation into a data mode.  It isn't
>> about "efficient delivery".  I recommend removing this sentence.
>>
>> ** Section 7.
>>    With the YANG data model of I2NSF Consumer-Facing Interface, this
>>    document suggests use cases
>>
>> Are there use cases or examples?  This is a bit pedantic, but to me this
>> data model suggests a lot more use cases than are described in Section 8.
>>
>> ** YANG.  identity rate-limit.  I appreciate that this identity is in
>> other I2NSF models.  How does the Security Controller know what is the
>> associate rate-limit threshold is?
>>
>> ** YANG.  identity signature-type.  The references for signature-yara,
>> signature-snort and signature-suricata are all of the form "<tool name>:
>> <tool name> signatures are explained".  There are not references.
>>
>> ** YANG.  identity threat-feed-type.  How is this used in this YANG
>> module?
>>
>> ** YANG.  identity device-type.
>>          Note that the device type of either a source
>>           or destination can be known with the help of DHCP
>>           Fingerprinting and the interaction between an NSF and a DHCP
>>           server.
>>
>> This behavior seems out of scope for this module as it is prescribing NSF
>> behavior.
>>
>> ** Both of these comments are related to similar questions posed in the
>> information model:
>> -- YANG.  grouping user-group.  How is the alignment to users done?  The
>> model appears to represent only a label (name) to describe an IP address
>> range, with the possibility of MAC addresses.
>>
>> -- YANG.  grouping device-group.  Does the ip-address represent the
>> services hosted on the application port, or the outbound connection the
>> ip-address-info will be making?
>>
>> ** YANG.  Per the fields under "rules":
>>
>> -- Does the rule name need to be unique?
>>
>> -- Would there be a desire to version at the per rule basis (e.g.,
>> Snort/Suricata's "rev:" rule option)?
>>
>> ** YANG.  container range-port-number.
>> -- what are the semantics of both the start-port-number  and
>> end-pot-number being empty?
>>
>> -- If the start-port-number is set, but the end-port-number is not, does
>> this assume "[start-port-number,65555]?  Same question situation for a set
>> end-port-number, but not start-port-number?
>>
>> ** YANG.  container ddos.
>> -- leaf flow-rate-threshold.  The associated unit of time is not
>> specified.  Is it flows/per second?
>>
>> -- RFC9244 is an entire YANG module on conveying DoS telemetry.  Are
>> there any additional metrics worth adding here?  Is there a way to reuse
>> this feature rich module?
>>
>> ** YANG.  container anti-virus.  This container not adequately specified.
>>
>>                  "The type or name of the files to be excluded by the
>>                   antivirus. This can be used to keep the known
>>                   harmless files.
>>                   If the value starts with a regular expression (e.g.,
>>                   '*.exe'), the antivirus should interpret it as a
>>                   file pattern/type to be excluded.
>>                   If the value does not start with a dot (e.g.,
>>                   'example.exe'), the antivirus should interpret it as
>>                   a file name/path to be excluded.";
>>
>> -- If regular expressions are permitted, please cite which flavor regex
>> -- POSIX?  PCRE?
>>
>> -- "*.exe" is not a valid regular expression (in POSIX/PCRE) to evaluate
>> a filename that ends with a string ".exe".
>>
>> -- Per the guidance, "if the value doesn't start with a dot (e.g.,
>> example.exe)", the cited example in the parenthesis doesn't appear to be
>> demonstrating what the text is describing.  Also the format described in
>> the line above, "*.exe" also doesn't begin with a dot.
>>
>> -- The text mentions that paths can also be included?  Is that restricted
>> to a local filesystem.  What are the expected path separators?  Can
>> protocol schemes be uses (e.g., smb://myfiles/*.exe)
>>
>> ** YANG.  container anti-virus.  Specifying malicious files to block by
>> hash names seems common.  Did the WG consider it?
>>
>> ** YANG. leaf-list source-id, destination-id, user-agent.  What
>> information is this representing?  The text says "The security policy rule
>> according to a <insert field name>."
>>
>> ** YANG.  device-type/device
>>                    "The device attribute that can identify a device,
>>                     including the device type (i.e., router, switch,
>>                     pc, ios, or android) and the device's owner as
>>                     well.";
>>
>> -- The list of device examples doesn't seem consistent with the defined
>> ones defined for "base device-type" (i.e., computer, mobile-phone, etc).
>> For example, there is not distinction made for mobile operating systems
>> (IOS or Android).  Likewise, there is only network-infrastructure-device
>> (not, router, switch)
>>
>> -- How does this field capture the device owner?
>>
>> ** YANG.  url-group.
>>
>> Is there a reason that the "leaf-list url" can't be of type "uri" instead
>> of "string"?
>>
>> ** YANG.  list payload-content
>>
>> -- Typo. s/Desecribe/Describe/
>>
>> -- How should multiple instances of the "content" field be interpreted?
>> Does every instance of "content" need to be somewhere in the session
>> stream, regardless of order, or does order matter?
>>
>> -- From where in the packet or stream is this payload considered?  Is it
>> everything after the transport layer header?
>>
>> ** Section 8.1.  Per Figure 19:
>> -- The descriptive text says this example is showing the registration of
>> new end-points, but the <name> says "security_policy_for_blocking_sns".
>> Where is the blocking behavior specified?
>>
>> -- The values of the <url> are supposed to be URLs.  What is specified
>> here is not a valid URL (there is not scheme)
>>
>> -- What is the relationship is being expressed between the ip addresses
>> in <user-group> and those in <device-group>?
>>
>> -- What is the relationship among the IP addresses in <user-group>,
>> <device-group> and the <url-group>?
>>
>> Same questions for Figure 20.  Thanks for providing both an IPv4 and IPv6
>> example.
>>
>> ** Section 8.3.  Typo. s/coming from from/coming from/
>>
>> ** Section 8.3. Typo. s/seucurity/security/
>>
>> ** Section 8.3.
>>       The Source is "malicious-id".  This can be a single ID or a list
>>        of IDs, depending on how the ID are stored in the database.
>>
>> How would the "malicious-id" be registered?  Would that be an IP address
>> via a <user-group>?
>>
>> ** Section 8.4.
>>    The destination is set as "web_server01".
>>
>> This destination is not reflected in Figure 23.
>>
>> ** Section 8.4.  Typo. s/nsfs/NSFs/
>>
>> ** Section 8.4.  Typo. s/secuiy/security/
>>
>> ** Section 8.4.
>>
>>    4.  The Source is all sources which send abnormal amount of packets.
>>
>> How would this 1000/pps would be calculated relative to "all sources
>> which send abnormal traffic"?  I'm keying on the way in which a distinction
>> would be made that traffic is abnormal.
>>
>> -- is there a per source IP counter to measure 1000/pps rate?
>>
>> -- is there 1000/pps rate set for the destination and traffic is dropped
>> after regardless of the number of sources?
>>
>> What normative text should be referenced to explain how these rates are
>> computed?
>>
>> ** Section 11.  Editorial.
>>
>> OLD
>> Writing to almost any element of this YANG
>>       module would directly impact on the configuration of NSFs
>> NEW
>> Writing to almost any element of this YANG
>>       module would directly impact the configuration of the NSFs
>> implementing the security policy.
>>
>> ** Section 11.  Per "Writing to almost any element of this YANG module
>> would ... impact the configuration of NSFs, e.g., ...  rendering useless
>> trained statistics or artificial intelligence models", consider something
>> weaker such as s/rendering useless.../reducing the efficacy of statistics
>> or artificial models built on historical data./
>>
>> ** Idnits output said:
>>
>> ==[ annotated snip from idnits ]==
>>   ** Obsolete normative reference: RFC  793 (Obsoleted by RFC 9293)
>>
>> [Roman] Action: replace RFC793 with RFC9293.
>>
>>   ** Downref: Normative reference to an Informational RFC: RFC 8329
>>
>> [Roman] Action: RFC8329 doesn't need to be normative.
>>
>>   ** Downref: Normative reference to an Informational RFC: RFC 8805
>>
>> [Roman] Action: Check my comments on how RFC8805.  If this draft stays,
>> it will be called out in IETF LC (and no action for the authors).
>>
>>   == Outdated reference: draft-ietf-tcpm-rfc793bis has been published as
>> RFC
>>      9293
>>
>> [Roman] Action: replace with RFC9293.
>>
>>   -- Possible downref: Normative reference to a draft: ref.
>>      'I-D.ietf-tcpm-rfc793bis'
>>
>> [Roman] Action: replace with RFC9293.
>> ==[ end snip ]==
>>
>> _______________________________________________
>> I2nsf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>