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

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

Hi Roman,
Thanks for your detailed AD review.

I will work on the revision with your comments.

Thanks.

Best Regards,
Paul

2022년 10월 24일 (월) 오전 11:03, Roman Danyliw <[e-mail]>님이 작성:

> 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
>
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>