Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 26 August 2020 00:11 UTC
Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659873A08CF for <i2nsf@ietfa.amsl.com>; Tue, 25 Aug 2020 17:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFTpcP0jIDUh for <i2nsf@ietfa.amsl.com>; Tue, 25 Aug 2020 17:11:20 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72323A08CC for <i2nsf@ietf.org>; Tue, 25 Aug 2020 17:11:19 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id h19so260702ljg.13 for <i2nsf@ietf.org>; Tue, 25 Aug 2020 17:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1UwBHP+Ydon3hwY+S9CeJr54IEQuK4M4dnBSQMxAXUQ=; b=TSHVIdJgHDGBa68d0JeZQXk6pZU+iMjDaKTSq7bzTuaA65LSmlzW2TO3OyQWQx4iAF 0ixy+S3Rti4Ds9on2JZSust63uR6sF87rt86yMREUzOV0GHnSKbyG7CVkcon3uYinn61 beYnyeINj/W+8nfKrzr+fOV/k5fHGgKQgceYOqhT/+tsXd7+MvOc+MDr7GZonJUpKEMn H7//vRAggYc62SVqCw83kt+coE4z+VpRTnlL5gatcTRMveGH1pKGkv744ytCPRLNgJu0 lNBornFX0d8oaE7cFI8SfUz03k3xtWF+qqlMQi9uDRnxsD//p8OP6NczHKw63NkMXtAO ihRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1UwBHP+Ydon3hwY+S9CeJr54IEQuK4M4dnBSQMxAXUQ=; b=svlqB53aw5EO88LjapJ5lE3+ZlRzfC/yWxZHc1capOyqYJonwCeRTr+OXPsjJV3AiT cxcHNuTxg3WjfEgcE0PIwgXoXdEmCQBk4TOknKen/rd29xqSvP364vauWGLb8ZXi3M1W 8+3Shmx+82rvyki44m+myea1QS4ac7tLsQqJk7TrJtrMMwr2johkrxJJI56ChZwmCla2 9/EejEeJaQyGLJXKCkaweDiOMngwqKWTZ5Rn202GPnrrK4jnCMPQOtYjyXXp9xvrqWYL wRLpe6o/R/mPPyYCSOdccsAMDDlbsVcfvtFO2wkHC9YQEzJntQdp71LoqAZNAl4jsPug cPQQ==
X-Gm-Message-State: AOAM531U1LUkIBZshRziJ5jXT0v3KwQOcIdq9oZxiBBhZNJbywLcfy0y MCCLJVGk9dTh/mRBuRoVbtA4zbaFkpkeW3vvj2k=
X-Google-Smtp-Source: ABdhPJz5Mw3WYSh5TuF6HUglv3QwmOgSbblldR2Eds0rFKsxNk81NYjQ33iEzEFOeQ5fonNVccvspTF7i8uzuWdGe0M=
X-Received: by 2002:a2e:3516:: with SMTP id z22mr5576232ljz.387.1598400677054; Tue, 25 Aug 2020 17:11:17 -0700 (PDT)
MIME-Version: 1.0
References: <475d6c2be4a7447dba48a4529451b72f@cert.org> <CAPK2DezkJL3tVnT=3TVwWbjaqAbRDK_vs5SY3ueX=VKf3x0zFw@mail.gmail.com> <81cf3d5e3708484aa157b37ad2431b63@cert.org> <CAPK2DexZGhLpgvaPdU_6f+BC83K+b1fBsrLhjmTR4=2vKE0bAA@mail.gmail.com> <cdab1d2ec31d4a53873fefbe59314c5b@cert.org> <CAPK2Dez1jSZ73PCNJ4EuLeAML1umtJWt528y3roXT3Zg2hU9qg@mail.gmail.com> <e516ded8893a49148ba6638df09ef842@cert.org>
In-Reply-To: <e516ded8893a49148ba6638df09ef842@cert.org>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Wed, 26 Aug 2020 09:10:40 +0900
Message-ID: <CAPK2DexaJfgKV_T6ey2c8ed=MUprk8E77hKL-fN6fHW8TGw1Mw@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="000000000000908c8205adbca805"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/Afe7DV7Z4jaS1xdZkzNKcha1_1A>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2020 00:11:23 -0000
Roman, Thanks for your kind help and guidance. Best Regards, Paul On Wed, Aug 26, 2020 at 2:16 AM Roman Danyliw <rdd@cert.org> wrote: > Hi Paul! > > > > Thanks for all of these revisions. I’ve changed the document state to > start IETF LC. > > > > Regards, > > Roman > > > > *From:* Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Sent:* Tuesday, August 25, 2020 1:08 PM > *To:* Roman Danyliw <rdd@cert.org> > *Cc:* i2nsf@ietf.org; skku-iotlab-members < > skku-iotlab-members@googlegroups.com>; Susan Hares <shares@ndzh.com>; Mr. > Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-capability-data-model-05 > > > > Roman, > > I have used option (3) by adding rudimentary text for each leaf for > advanced-nsf-capabilities. > > I have also replaced "whitelists" with "allow-list". > > > > Here is the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-08 > > > > You can see the differences between -07 version and -08 version for those > updates as follows: > > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-i2nsf-capability-data-model-08.txt > > > > > If you have further comments, please let me know. > > > > Thanks. > > > > Best Regards, > > Paul > > > > On Wed, Aug 26, 2020 at 12:46 AM Roman Danyliw <rdd@cert.org> wrote: > > Hi Paul! > > > > Thanks for the quick update. This change removed the explicit link to > draft-dong-i2nsf-asf-config. However, now the document has a number of > undocumented elements of the YANG model under advanced-nsf-capability. > Citing RFC8329 is helpful to link them to NSF capabilities, but this > doesn’t explain the differences between these YANG elements. I thinking > there are a couple of options: > > > > (1) remove advanced-nsf-capabilities entirely > > > > (2) leave only a “top-level container” named advanced-nsf-capabilities and > specify this no further. Some text is required to explain that the > advanced-nsf-capabilities is an extension point. > > > > (3) leave the text as is in -07, and add rudimentary text explaining each > of the leaves in advanced-nsf-capabilities as being extension points for > particular advanced capabilities (and explain the differences between them) > > > > As a separate matter and I should have noticed it earlier, I see the use > of the language “whitelist”. In the spirit of reconsidering language that > some consider exclusionary, could you please (i.e., > s/whitelist/allow-list/): > > > > OLD: > > identity whitelists { > > base anti-virus-capability; > > description > > "Identity for advanced NSF Anti-Virus Whitelists capability"; > > reference > > "RFC 8329 <https://tools.ietf.org/html/rfc8329>: Framework for > Interface to Network Security > > Functions - Advanced NSF Anti-Virus Whitelists capability"; > > } > > > > NEW: > > identity allow-list { > > base anti-virus-capability; > > description > > "Identity for advanced NSF Anti-Virus Allow List capability"; > > reference > > "RFC 8329 <https://tools.ietf.org/html/rfc8329>: Framework for Interface to Network Security > > Functions - Advanced NSF Anti-Virus Allow List capability"; > > } > > > > Regards, > > Roman > > > > *From:* I2nsf <i2nsf-bounces@ietf.org> *On Behalf Of *Mr. Jaehoon Paul > Jeong > *Sent:* Tuesday, August 25, 2020 8:18 AM > *To:* Roman Danyliw <rdd@cert.org> > *Cc:* i2nsf@ietf.org; skku-iotlab-members < > skku-iotlab-members@googlegroups.com>; Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com>; Susan Hares <shares@ndzh.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-capability-data-model-05 > > > > Hi Roman, > > I have addressed your two comments in the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-07 > > > > - Addition of RFC 3688 in Normative References > > - Removal of the references for draft-dong-i2nsf-asf-config from the draft > > > > Please move our draft forward. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Mon, Aug 24, 2020 at 9:08 PM Roman Danyliw <rdd@cert.org> wrote: > > Hi Paul! > > (my apologies. These email got stuck in my outbox and was intended to go > out when I made the state change in the data tracker) > > > > Thanks for the extensive changes you made in -06 and my apologizes in the > delay in responding. All feedback but the following has been addressed: > > > > (1) IDNits returned the following valid comment about references > (many of the issue is noted were in the YANG module) > > == Missing Reference: 'RFC3688' is mentioned on line 1764, but not > defined > > > > [Paul] => There is no reference to RFC3688 (The IETF XML Registry). > Could you doublecheck your comment to let me follow it? > > > > [Roman] See Section 7 > > > > --[ snip ]-- > > 7. IANA Considerations > > > > This document requests IANA to register the following URI in the > > "IETF XML Registry" [RFC3688]: > > … > > --[ snip ]-- > > > > (10) Section 4. Per "Note that the NSF-Facing Interface ... and the > NSF Monitoring Interface is used to ...", does this text need additional > precision based on the definitions in RFC8329. Per RFC8329, the > "NSF-Facing Interfaces" consists of the "NSF Operational and Administrative > Interface" and a "Monitoring Interface". If draft-dong-i2nsf-asf-config is > on the "Monitoring Interface", on which "sub-interface" of the "NSF-Facing > Interface" does draft-ietf-i2nsf-nsf-facing-interface-dm belong? > > > > (28) Section 6.1.. In the advanced-nsf-capability section, there > are multiple normative references to draft-dong-i2nsf-asf-config-01, an > expired, individual draft. Additionally, Section 4 notes how it supports > the advanced capabilities. This draft is a substantial portion of the YANG > module added in -03. What's the plan on resolving this dependency? > > > > [Paul] => This draft will be developed by I2NSF WG later. > > > > I still have the same question. It doesn’t appear to me that the WG is > currently positioned to do anything with draft-dong-i2nsf-asf-config . > Practically, it isn’t even a WG product, but an individual submission that > wasn’t adopted. It was last updated 22 months ago and expired almost 18 > months ago. Correct me where I have it wrong, but this draft provides a > generic model for the capabilities and draft-dong-i2nsf-asf-config appears > to be acting as an extension for more advancing NSF capabilities. I think > we have (at least) two options: > > > > (a) Remove references to the capabilities derived from > draft-dong-i2nsf-asf-config; if there is energy, consider adopting it in > the WG at some point in the future, and it could update this document > (draft-ietf-i2nsf-capability-data-model); in the meantime this document > gets published > > > > (b) Continue advancing this document and stall awaiting a missing > reference (MISREF) in the RFC Editor queue (just like > draft-ietf-i2nsf-applicability) for something to happen to > draft-dong-i2nsf-asf-config > > > > I have a preference for (a) because I don’t see value in blocking the > publication of a named deliverable of the WG for an unadopted (individual), > expired draft; and this approach doesn’t preclude future enhancements (as > proposed by draft-dong-i2nsf-asf-config). What does everyone else think? > > > > Regards, > > Roman > > > > > > > > *From:* Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Sent:* Monday, July 13, 2020 9:04 AM > *To:* Roman Danyliw <rdd@cert.org> > *Cc:* i2nsf@ietf.org; Susan Hares <shares@ndzh.com>; skku-iotlab-members < > skku-iotlab-members@googlegroups.com>; Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-capability-data-model-05 > > > > Hi Roman, > > I (as an editor) have revised the I2NSF Capability Data Model Draft and > posted it into the IETF repository: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-06 > > > > Here is the revision letter to explain how to address your comments. > > If you are satisfied with this revision, could you move this draft to the > IESG evaluation? > > > > Thanks for your valuable comments and help.. > > > > Best Regards, > > Paul > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Computer Science and Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > > > > On Wed, May 13, 2020 at 7:11 AM Roman Danyliw <rdd@cert.org> wrote: > > Hi! > > I conducted an AD review of draft-ietf-i2nsf-capability-data-model-05. > Thanks for the work in getting this document written. My most significant > items are around aligning of the text in Section 4 with RFC8329 and the > dependency on draft-dong-i2nsf-asf-config-01. My detailed feedback is > below. > > (1) IDNits returned the following valid comment about references (many > of the issue is noted were in the YANG module) > == Missing Reference: 'RFC3688' is mentioned on line 1764, but not > defined > > (2) Section 1. Typo. s/[draft-ietf-i2nsf-capability]../ > [draft-ietf-i2nsf-capability]./ > > (3) Section 3. Is there a reason to rely on two expired drafts for > terminology -- [draft-ietf-i2nsf-terminology] and > [draft-ietf-supa-generic-policy-info-model]? In particular, couldn't > RFC3444 provide the needed definitions of data and information models? > > (4) Section 4. I would have expected somewhere in this overview > section an explicit enumeration of which I2NSF interfaces use this YANG > module. > > (5) Section 4. Per "Figure 1 shows the capabilities of NSFs in I2NSF > Framework." > -- Thanks for reusing the diagram from RFC8329 and annotating it with more > detail. It helps connect the documents > -- It wasn't clear to me where the "capabilities" are on the diagram > -- Is all of the detail under the NSFs (i.e., E, C and A) needed in the > diagram? Text doesn't explain it or reference it. If kept, it should be > explained and E, C and A should be defined (i.e., saying these correspond > to Event, Condition and Action) > > (6) Global. Editorial. Is there a reason to abbreviate "Mgmt" in > "Developer's Mgmt System in the text? Recommend s/Developer's Mgmt > System/Developer's Management System/g > > (7) Section 4. Per "To register NSFs in this way, the Developer's > Mgmt System utilizes this standardized capabilities YANG data model through > its registration interface.", this confused me a bit. Doesn't the > Developer Management System use the model described in > draft-ietf-i2nsf-registration-interface-dm for registration? > > (8) Section 4. Editorial. Per "... those security devices can be > easily managed, ...", I might have used "more easily managed". > > (9) Section 4. Per "The use cases are described below.", where are > those use cases described? Is this text a reference to the "Configuration > Examples" in Appendix A? > > (10) Section 4. Per "Note that the NSF-Facing Interface ... and the > NSF Monitoring Interface is used to ...", does this text need additional > precision based on the definitions in RFC8329. Per RFC8329, the > "NSF-Facing Interfaces" consists of the "NSF Operational and Administrative > Interface" and a "Monitoring Interface". If draft-dong-i2nsf-asf-config is > on the "Monitoring Interface", on which "sub-interface" of the "NSF-Facing > Interface" does draft-ietf-i2nsf-nsf-facing-interface-dm belong? > > (11) Figure 1. Editorial Nit. Is there are reason that the > Registration interface has a bidirectional arrow between the network > operator management system and the developer management system, but the > there is no directionality on the consumer or NSF facing interface? > > (12) Section 4. The bulleted list under Figure 1 is helpful in > describing Figure 1. However, I'd recommend explicitly saying this is an > example. Explain the use case up front and then narrate the flow clearly > delineating what is in and out of scope of I2NSF. IMO, the text describes > a number of internal processing functions which are in scope for > standardization - please let me know if I'm reading it wrong. > > (13) Section 4. Per "If network manager wants to block malicious users > with IPv6, the network manager sends the security policy rules to block the > users to the Network Operator Mgmt System using I2NSF user ....", can you > please clarify "malicious users with IPv6"; is the intent that the network > manager is concerned about malicious IPv6 traffic? > > (14) Section 4. Bullet 1 under Figure 1. Per "a web browser or a > software", what's the difference between a browser and software? > > (15) Section 4. Editorial. Per the second bullet under Figure 1, "If > NSFs encounter the malicious packets, it is a tremendous burden for the > network manager to apply the rule to block the malicious packets to NSFs > one-by-one. This problem can be resolved by managing the capabilities of > NSFs.", delete this text. It is a duplicate of what was stated in the > first bullet. > > (16) Section 4. Per the paragraph, "If NSFs encounter the suspicious > IPv4 packets, they can ask the Network Operator Mgmt System for information > about the suspicious IPv4 packets in order to alter specific rules and/or > configurations. When the Network ...", how much of that signaling is in > scope for I2NSF? > > (17) Section 4. Typo. s/suspiciou/suspicious/ > > (18) Section 5.1. Editorial. s/The model includes NSF capabilities/The > model describes NSF capabilities/ > > (19) Section 5.1. Editorial. "specify" is used twice in the sentence. > OLD > Time capabilities are used to specify the capabilities to specify when to > execute the I2NSF policy rule. > NEW > Time capabilities are used to specify the capabilities which describe when > to execute the I2NSF policy rule. > > (20) Section 5.1. Editorial. This sentence didn't parse for me. The > second contains duplicate text. > OLD > Event capabilities are used to specify capabilities how to trigger the > evaluation of the condition clause of the I2NSF Policy Rule. The defined > event capabilities are defined as system event and system alarm. > NEW > Event capabilities are used to specify the capabilities that describe the > event that would trigger the evaluation of the condition clause of the > I2NSF Policy Rule. The defined event capabilities are system event and > system alarm. > > (21) Section 5.1. A number of capabilities note that they can be > extended which is a helpful feature. For example, "The condition > capability can be extended according to specific vendor condition > features." However, where is the guidance on doing that? Likewise, it > might not be necessary to repeat this statement five times if the extension > mechanism is the same. > > (22) Section 5.1. A number of the described capability types state > that they are described in detail in draft-ietf-i2nsf-capability.. For > example, "The condition capability is described in detail in > [draft-ietf-i2nsf-capability]." I had difficulty locating which specific > section to review. Also, for the default action capabilities, no described > of "pass, drop .. mirror" was found in draft-ietf-i2nsf-capability. Please > provide a specific section number for the event, condition, action, > resolution strategy and default action in draft-ietf-i2nsf-capability. > > (23) Section 5.1. Editorial. These sentences didn't parse for me. > OLD > Action capabilities are used to specify capabilities of how to control and > monitor aspects of flow-based NSFs when the event and condition clauses are > satisfied. > NEW > Action capabilities are used to specify the capabilities that describe the > control and monitoring aspects of flow-based NSFs when the event and > condition clauses are satisfied. > > OLD > Resolution strategy capabilities are used to specify capabilities of how > to resolve conflicts that occur between the actions of the same or > different policy rules that are matched and contained in this particular > NSF. > NEW > Resolution strategy capabilities are used to specify the capabilities that > describe conflicts that occur between the actions of the same or different > policy rules that are matched and contained in this particular NSF. > > OLD > Default action capabilities are used to specify capabilities of how to > execute I2NSF policy rules when no rule matches a packet. > NEW > Default action capabilities are used to specify the capabilities that > describe how to execute I2NSF policy rules when no rule matches a packet. > > > (24) Section 6.1. Update the copyright date and revision date to be in > 2020. > > (25) Section 6.1. Given that draft-ietf-i2nf-monitoring-data-model is > referenced in the YANG model for event and system alarm, please make it a > normative reference. > > (26) Section 6.1. identity ingress/egress-action-capability. I found > draft-ietf-i2nsf-capability-04 to be an unexpected reference.. There is no > mention of ingress or egress in that document. > > (27) Section 6.1. identity pass, drop, reject, alert, mirror. I found > draft-ietf-i2nsf-capability-04 to be an unexpected reference.. There is no > mention of pass, drop, reject, alert or mirror in that document. > > (28) Section 6.1. In the advanced-nsf-capability section, there are > multiple normative references to draft-dong-i2nsf-asf-config-01, an > expired, individual draft. Additionally, Section 4 notes how it supports > the advanced capabilities. This draft is a substantial portion of the YANG > module added in -03. What's the plan on resolving this dependency? > > (29) Section 6.1. Typo. s/Funtion/Function/ > > (30) Section 6.1. The list of references in generic-nsf-capabilities > don't line up with those in the child leaflist(s). For example, RFC 792 is > mentioned in the top level reference list but not in any of the child > leaflist (specifically not in leaf-list icmp-capability) > > (31) Section 6.1. Typo. s/smae/same/ > > (32) Section 8. A few clarifying updates to the template: > OLD > These data nodes may be considered sensitive or vulnerable in some network > environments. Write operations (e.g., edit-config) to these data nodes > without proper protection can have a negative effect on network operations. > ietf-i2nsf-capability: The attacker may provide incorrect information of > the security capability of any target NSF by illegally modifying this. > > NEW > These data nodes may be considered sensitive or vulnerable in some network > environments. Write operations to these data nodes could have a negative > effect on network and security operations. > ietf-i2nsf-capability: An attacker could alter the security capabilities > associated with an NSF whereby disabling or enabling the evasion of > security mitigations. > > OLD > ietf-i2nsf-capability: The attacker may gather the security capability > information of any target NSF and misuse the information for subsequent > attacks.. > NEW > ietf-i2nsf-capability: An attacker could gather the security capability > information of any NSF and use this information to evade detection or > filtering. > > Regards, > Roman > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Computer Science and Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Computer Science and Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
- [I2nsf] AD Review of draft-ietf-i2nsf-capability-… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-capabil… Mr. Jaehoon Paul Jeong