Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16

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

Hi Tom,
Here are the revision letter and revised draft reflecting your comments.

https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-17

Patrick and I worked together for this revision.

Please let me know whether this version satisfies your comments or not.

Thanks.

Best Regards,
Paul

On Wed, Apr 28, 2021 at 8:45 PM tom petch <[e-mail]> wrote:

> From: Linda Dunbar <[e-mail]>
> Sent: 27 April 2021 16:49
>
> Tom,
>
> Can you please provide the concrete suggestions to the authors on the
> changes you like to see?
>
> This is the second time of the WGLC for the draft. It would be very
> helpful to hear your suggestions during the WGLC window.
>
> Thank you very much
>
> <tp>
> Linda,
> Sorry about the timing but here goes;
>
> Not Ready IMHO
>
> This is one of six I2NSF I-D with YANG modules and there is a lot of
> overlap between them but the functionality offered, the approach taken,
> the structuring, the terminology used, varies between them which is
> likely to create confusion (and errors) in the user.  This I-D is mostly
> a list of some 200 YANG identity which then appear in a YANG list to
> show what is supported and by implication what is not.  (I have
> extracted the identity and list them at the end of this e-mail since
> much of what I say is clearer when the list is visible in its entirety).
> There are similar but different lists of YANG identity in
> draft-ietf-i2nsf-customer-facing, draft-ietf-i2nsf-nsf-facing,
> draft-ietf-i2nsf-nsf capability.
>
> I find the choice of identifiers here poor.  Some have the
> suffix -capability, others do not.  Given the context in which the
> module uses them e.g leaf-list sctp-capability, then I find that suffix
> largely redundant.  Ditto the suffix -action in the list of anti-ddos.
>
> Most identifier are multi-element e.g.
> identity prefix-ipv6-address-flow-direction
> and the element order means that they will collate with all the prefix,
> range, exact together while ipv6-next-header will be somewhere
> different.  A user likely needs all the ipv4 together, all the ipv6 etc so
> the
> identifier should be
> identity ipv6-address-prefix-flow-direction
> so that all the ipv6, sctp, udp etc are together.  With YANG, as with
> many languages, the distinction between exact and range is moot; exact
> is usually modelled with a range with 'start' equal to 'end' so you
> could almost assume that both variants are supported and it is certainly
> the least important aspect of the identifier so should come last in the
> identifier if it is included at all (I would not).
>
> Functionally there are fewer protocols than other I2NSF I-D; http only
> appears as a potential flood while draft-ietf-i2nsf-consumer-facing has
> ssh, ftp, http, pop3, nat etc and draft-ietf-i2nsf-nsf-facing has ospf,
> l2tp, eigrp, skip etc.  Are these not some of these capabilities?
>
> YANG allows multiple identity to be derived from a common base which
> makes it possible easily to e.g. reference just ip4, or ipv4 and ipv6,
> or all such protocols.  Not here. ipv4-capability is derived from
> 'identity condition' along with  many other quite different capabilities
> such as
>     identity context-capability {
> which renders that YANG capability(!) of little use.
> draft-nsf-monitoring by contrast derives tcp, udp, icmp from a common
> base of ipv4 or ipv6, both of which are in turn derived from 'identity
> ip' which is derived from 'protocol-type'  OK I disagree about the
> suffiix -type but the structure there is what other IETF YANG modules
> widely use and I think right.  In this I-D there is no concept of
> protocol - the identity for protocol are all derived from 'identity
> condition' (along with much else, unrelated concepts IMHO)
>
> identity icmp-capability and identity icmpv6-capability are likewise
> both derived from 'identity conditoin' when I would expect them to have
> a common icmp base given how much overlap there is between icmp for v4
> and icmp for v6 and a likely need to refer the two combined.
>
> I-D nsf-monitoring is quite different here, deriving icmp from a base of
> either ipv4 or ipv6, while deriving icmpv4 from ipv4 and icmpv6 from
> ipv6.  I think that approach much superior both in the choice of
> identifiers, icmpv4 and icmpv6 as opposed to icmp and icmpv6, and in
> allowing a simple reference to icmp in all its forms along with ipv4 or
> ipv6 specific when needed.
>
> This I-D models  identity ipv4-tos-dscp and  identity
> ipv6-traffic-class-dscp/identity exact-ipv6-flow-label; nsf-facing has
> choices such as minimize-cost, maximize-reliability derived from a
> choice of either identity type-of-service or identity traffic-class
> which seems to be more in line with current thinking.
>
> With alarms, this I-D is more in line with others but with different
> terminology, here it is memory-alarm, cpu-alarm, disk-alarm,
> hardware-alarm, interface-alarm. I-D nsf-facing is the same but I-D
> nsf-monitoring has mem-usage-alarm, cpu-usage-alarm, disk-usage-alarm,
> hw-failure-alarm, ifnet-state-alarm. Not wrong but confusingly
> different.
>
> This I-D has context-capability e.g. user, geography, ACL which I
> struggle to relate to the other I-D.  (In passing, I would have thought
> ACL a sine
> qua none for any I2NSF work).
>
> This I-D derives identity rule-log, identity session-log from
> log-action-capability.  nsf-facing is the same but comsumer-facing has
> identity log, identity syslog, identity session-log derived from
> secondary-action;
>
> Here ingress-action/egress-action/default-action are a common base for
> identity pass, identity drop, identity alert, identity mirror while I-D
> consumer-facing has primary-action as a base for identities pass, drop,
> alert, rate-limit, mirror and I-D nsf-facing has pass, drop, reject,
> alert, mirror.
>
> resolution-strategy-capability is the base for identity fmr, identity
> lmr, identity pmr, identity pmre, identity pmrn and this is the same as
> I-D nsf-facing(!)
>
> This I-D uses advanced-nsf-capability as the base for
> anti-virus-capability, anti-ddos-capability, ips-capability,
> voip-volte-capability.  I-D consumer-facing has security-event-type as a
> base for ddos, spyware, trojan, ransomware while  I-D nsf-facing uses
> content-security-control as a base for firewall, antivirus, ips, ids,
> url-filtering, voip-volte, mail-filtering, file-blocking, pkt-capture,
> application-control and then I-D nsf-monitoring  has nsf-attack-type as
> a base for botnet-attack-type and  virus-type, and virus-type is then
> the base for trojan, worm, macro.  Here, antivirus is the base for
> identity detect and identity allow-list which for me is a completely
> different set of concepts.
>
> Returning to ddos, here the I-D diverge widely.  This I-D
> has 10 derived identity, with the only appearance of http in the I-D but
> which it separates from https; likewise it splits icmp-flood from icmpv6
> flood (without a common icmp base) and dns-request from dns-reply, again
> the only appearance of the dns protocol and, again, with no common base.
>
> I-D nsf-monitoring uses a base of flood type from which it derives 14
> identity adding syn-ack, fin-rst, tcp-con.  It keeps the dns-request,
> dns-reply but gives a choice of icmp, icmpv4, icmpv6 but does not derive
> the last two from the first.  (What is meant by 'icmp'? beware, it all
> depends on the author, could be v4 could be v4 and v6, you cannot tell).
>
> I-D nsf-facing is quite close to I-D nsf-monitoring for ddos but uses a
> base of attack-mitigation-control; joins http and https in identity
> http-and-https-flood, splits dns into dns and dns-amp rather than query
> and reply, adds oversized-icmp (icmp-... please)  and then tacks on
> ip-sweep, port-scanning, ping-of-death, teardrop, tracert which may be
> attacks but are not ddos and would seem to make no appearance in this
> capabilities I-D.
>
> This I-D uses voip-volte-capability as a base for voip-volte-call-id and
> identity user-agent.  I-D nsf-facing derives identity voip-volte from
> content-security-control (not a concept I see in the capabilities I-D)
> while draft-ietf-i2nsf-registration-interface-dm would appear to expect
> there to be an identity 'voice-id'.
>
> No one I-D on its own is wrong and every I-D has parts that I think just
> right - it is just when they are put together
> it all gets confusing.  What I lack is an underlying information
> model which separates out the different concepts and gives them
> identifiers for these YANG I-D to use both in nomenclature and it going
> into more detail.  A monitoring I-D may specify more detailed flood
> prevention e.g but I should be able to refer it back to a capability in
> this I-D.  RFC8329 is not that model.
>
> I append below the list of identity I have extracted from the
> capabilities I-D.  I think that seeing just the list of identifiers
> highlights the challenges a user will have.  I have similar lists for
> customer-facing, nsf-facing, nsf-monitoring.  In YANG the 'base' is
> specified after the 'identity' statement.  For the purposes of this
> review I find it clearer to place the 'base' first and then list the
> identity derived from that the base.  The order of the identity
> statements is the same as in the I-D
>
> Tom Petch
>
>
>   /*
>    * Identities draft-ietf-i2nsf-capability-data-model-16
>    */
>
>   base event;
>     identity system-event-capability {
>     identity system-alarm-capability {
>
>   base system-event-capability;
>     identity access-violation {
>     identity configuration-change {
>
>   base system-alarm-capability;
>     identity memory-alarm {
>     identity cpu-alarm {
>     identity disk-alarm {
>     identity hardware-alarm {
>     identity interface-alarm {
>
>   base condition;
>     identity context-capability {
>
>   base context-capability;
>     identity access-control-list {
>     identity application-layer-filter {
>     identity target {
>     identity user {
>     identity group {
>     identity geography {
>
>   base directional-capability;
>     identity unidirectional {
>     identity bidirectional {
>
>   base condition;
>     identity ipv4-capability {
>
>   base ipv4-capability;
>     identity exact-ipv4-header-length {
>     identity range-ipv4-header-length {
>     identity ipv4-tos-dscp {
>     identity exact-ipv4-total-length {
>     identity range-ipv4-total-length {
>     identity ipv4-id {
>     identity ipv4-fragment-flags {
>     identity exact-ipv4-fragment-offset {
>     identity range-ipv4-fragment-offset {
>     identity exact-ipv4-ttl {
>     identity range-ipv4-ttl {
>     identity ipv4-protocol {
>     identity prefix-ipv4-address-flow-direction {
>     identity prefix-ipv4-address {
>     identity prefix-ipv4-src-address {
>     identity prefix-ipv4-dst-address {
>     identity range-ipv4-address-flow-direction {
>     identity range-ipv4-address {
>     identity range-ipv4-src-address {
>     identity range-ipv4-dst-address {
>     identity ipv4-ip-opts {
>     identity ipv4-geo-ip {
>
>   base condition;
>     identity ipv6-capability {
>
>   base ipv6-capability;
>     identity ipv6-traffic-class-dscp {
>     identity exact-ipv6-flow-label {
>     identity range-ipv6-flow-label {
>     identity exact-ipv6-payload-length {
>     identity range-ipv6-payload-length {
>     identity ipv6-next-header {
>     identity exact-ipv6-hop-limit {
>     identity range-ipv6-hop-limit {
>     identity prefix-ipv6-address-flow-direction {
>     identity prefix-ipv6-address {
>     identity prefix-ipv6-src-address {
>     identity prefix-ipv6-dst-address {
>     identity range-ipv6-address-flow-direction {
>     identity range-ipv6-address {
>     identity range-ipv6-src-address {
>     identity range-ipv6-dst-address {
>     identity ipv6-header-order {
>     identity ipv6-options {
>     identity ipv6-hop-by-hop {
>     identity ipv6-routing-header {
>     identity ipv6-fragment-header {
>     identity ipv6-destination-options {
>     identity ipv6-geo-ip {
>
>
>   base condition;
>     identity tcp-capability {
>
>   base tcp-capability;
>     identity exact-tcp-port-num-flow-direction {
>     identity exact-tcp-port-num {
>     identity exact-tcp-src-port-num {
>     identity exact-tcp-dst-port-num {
>     identity range-tcp-port-num-flow-direction {
>     identity range-tcp-port-num {
>     identity range-tcp-src-port-num {
>     identity range-tcp-dst-port-num {
>     identity tcp-flags {
>     identity tcp-options {
>
>
>   base condition;
>     identity udp-capability {
>
>   base udp-capability;
>     identity exact-udp-port-num-flow-direction {
>     identity exact-udp-port-num {
>     identity exact-udp-src-port-num {
>     identity exact-udp-dst-port-num {
>     identity range-udp-port-num-flow-direction {
>     identity range-udp-port-num {
>     identity range-udp-src-port-num {
>     identity range-udp-dst-port-num {
>     identity exact-udp-total-length {
>     identity range-udp-total-length {
>
>   base sctp-capability;  [**yes really]
>     identity exact-sctp-port-num-flow-direction {
>     identity exact-sctp-port-num {
>     identity exact-sctp-src-port-num {
>     identity exact-sctp-dst-port-num {
>     identity range-sctp-port-num-flow-direction {
>     identity range-sctp-port-num {
>     identity range-sctp-src-port-num {
>     identity range-sctp-dst-port-num {
>     identity sctp-verification-tag {
>     identity sctp-chunk-type {
>
>
>   base dccp-capability;
>     identity exact-dccp-port-num-flow-direction {
>     identity exact-dccp-port-num {
>     identity exact-dccp-src-port-num {
>     identity exact-dccp-dst-port-num {
>     identity range-dccp-port-num-flow-direction {
>     identity range-dccp-port-num {
>     identity range-dccp-src-port-num {
>     identity range-dccp-dst-port-num {
>     identity dccp-service-code {
>
>
>
>   base condition;
>     identity icmp-capability {
>
>
>   base icmp-capability;
>     identity icmp-type {
>     identity icmp-code {
>
>   base condition;
>     identity icmpv6-capability {
>
>   base icmpv6-capability;
>     identity icmpv6-type {
>     identity icmpv6-code {
>
>
>   base condition;
>     identity url-capability {
>
>
>   base url-capability;
>     identity pre-defined {
>     identity user-defined {
>
>
>   base log-action-capability;
>     identity rule-log {
>     identity session-log {
>
>
>   base ingress-action-capability;
>   base egress-action-capability;
>   base default-action-capability;
>     identity pass {
>     identity drop {
>     identity alert {
>     identity mirror {
>
>
>   base egress-action-capability;
>     identity invoke-signaling {
>     identity forwarding {
>     identity redirection {
>
>
>   base resolution-strategy-capability;
>     identity fmr {
>     identity lmr {
>     identity pmr {
>     identity pmre {
>     identity pmrn {
>
>   base advanced-nsf-capability;
>     identity anti-virus-capability {
>     identity anti-ddos-capability {
>     identity ips-capability {
>     identity voip-volte-capability {
>
>
>   base anti-virus-capability;
>     identity detect {
>     identity allow-list {
>
>   base anti-ddos-capability;
>     identity syn-flood-action {
>     identity udp-flood-action {
>     identity http-flood-action {
>     identity https-flood-action {
>     identity dns-request-flood-action {
>     identity dns-reply-flood-action {
>     identity icmp-flood-action {
>     identity icmpv6-flood-action {
>     identity sip-flood-action {
>     identity detect-mode {
>     identity baseline-learning {
>
>
>   base ips-capability;
>     identity signature-set {
>     identity ips-exception-signature {
>
>
>   base voip-volte-capability;
>     identity voip-volte-call-id {
>     identity user-agent {
>
>   base ipsec-capability;
>     identity ike {
>     identity ikeless {
>
>
>
>
>
>
> Linda
>
> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: Tuesday, April 27, 2021 10:44 AM
> To: Linda Dunbar <[e-mail]>; [e-mail]
> Subject: Re: [I2nsf] Closing the WGLC for
> draft-ietf-i2nsf-capability-data-model-16
>
> From: I2nsf <[e-mail]> on behalf of Linda Dunbar <
> [e-mail]>
> Sent: 27 April 2021 16:06
>
> I2NSF WG,
>
> As expected, there is no issue with the second time WGLC for
> draft-ietf-i2nsf-capability-data-model.
>
> <tp>
> Sigh, I did not know there was a Last Call in progress, I did not see that
> on the datatracker:-(  I spent last week going round in circles trying to
> dovetail the five I2NSF YANG modules and this morning finally decided that
> it could not be done.
>
> The general concern I have is that there are a number of YANG modules that
> are doing the same thing in different ways, with different terminology,
> different technology, which is going to give the user heartache IMHO
>
> Today I read RFC8329 hoping that it would give one clear set of right
> terminology but it does not help much; thus s.9.2 therein is rather vague
> with question marks in places.  The various YANG modules are clearly in the
> same ballpark as the RFC but perhaps not on the same base e.g. the RFC has
> pass, deny, mirror while this I-D has pass, drop, alert, mirror and
> differences like that are repeated many times.  In places, that may be by
> design but in others I believe that it is not  I will post some more
> concrete examples on Wednesday.  I will seek to use 'capability' as the
> base, the refer4ence, and point out where the other four diverge
>
> I would say that sdn-ipsec gets it right but I also note that the IESG
> made in excess of 150 changes to the I-D before approving it which I think
> on the one hand was necessary but on the other hand seems a profligate use
> of AD time.   More could have been done beforehand IMHO.
>
> Tom Petch
>
> This email is to confirm that the WGLC for the
> draft-ietf-i2nsf-capability-data-model-16 is completed. We will move this
> draft to IESG.
>
> Thank you very much for the work.
>
> Best Regards,
> Linda Dunbar
>
> From: Linda Dunbar
> Sent: Tuesday, March 30, 2021 4:37 PM
> To: [e-mail]
> Subject: WGLC for draft-ietf-i2nsf-capability-data-model-16
>
> Hello Working Group,
>
> When I2NSF WG closed the WGLC for  draft-ietf-i2nsf-capability-data-model
> in Dec 2019 (
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fi2nsf%2F%3Fq%3Ddraft-ietf-i2nsf-capability-data-model%26f_from%3DLinda%2520Dunbar&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416364721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=gTCjj1AgX850nVjMqwhSUYpi261P%2FIEPVEDlzY%2FuVs8%3D&amp;reserved=0
> ), there was a formative reference to draft-ietf-i2nsf-capability-05 which
> was stale.
>
> After the review, IESG decided to throw the draft back to I2NSF WG and
> requested the WG to reach the consensus to sunset the
> draft-ietf-i2nsf-capability-05. The WG finally reached the consensus in
> Oct 2020  (
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fi2nsf%2F%3Fq%3Ddraft-ietf-i2nsf-capability-data-model%26f_from%3DLinda%2520Dunbar&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=CwsgBrh%2FRpLX2x5TP%2BplrmO1ckr3VO4F56TN21h5LOM%3D&amp;reserved=0
> )
>
>
> Many thanks to the authors to merge all the relevant content from
> draft-ietf-i2nsf-capability-05 and addressed all the comments from YANG
> Doctor review and
>
> This email starts a two-weeks Working Group Last Call on
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2F&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RDAu7tXiFbH1WtgyJo2KL1idgWJ3s6pwQjVvJ60TLM8%3D&amp;reserved=0
>
> This poll runs until April 13, 2021.
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as an Author or a Contributor of this Document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
> Thank you.
>
> Linda & Yoav
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>