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

[tom petch <[e-mail]>]

From: Mr. Jaehoon Paul Jeong <[e-mail]>
Sent: 14 August 2021 08:38

----- Original Message -----
From: "Mr. Jaehoon Paul Jeong" <[e-mail]>
Sent: Saturday, August 14, 2021 8:38 AM

> Hi Tom,
> Here are the revision letter and revised draft reflecting your
comments.
>
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-m
odel-17
>
> Patrick and I worked together for this revision.
>
> Please let me know whether this version satisfies your comments or
not.

Getting there; I like the structure and the identifiers  of the YANG
identity statements

Lots of new references in the YANG module -good -  but they need adding
to the I-D References.  I see
RFC854
RFC913
RFC959
RFC1081
RFC2616
RFC2818
RFC4766
RFC5101
RFC5321
IEEE 802.3 (which also needs a date to make the reference unique)

Of these, RFC1081 is obsoleted by RFC1225 and RFC2616 by several others
so the references may be better changing.  RFC7296 and RFC8519 are
listed as Normative References and are referenced at the start of
Section 6 but no longer appear in the YANG module AFACT.

On the identity, I take this I-D as the best set thereof and so comment
on the other three I-D wanting to bring them in line.  I have |(almost)
no comments on the ones here.

s.5.1
The tree diagram seems out of line with the YANG module.  I cannot see
leaf-list ethernet-capability
leaf-list anti-virus-capability

Appendix  A
Equally the examples seem out of line with the YANG module e.g.
       <udp-capability>source-port-num</udp-capability>
       <udp-capability>destination-port-num</udp-capability>
seem to be missing a 'ber' while
       <ipv4-capability>ipv4-protocol</ipv4-capability>
I cannot see in the identity. I have not checked the examples in detail,
something a tool can do better then ever I can.

In the YANG module

/http:/https:/

"     identity ethernet {
        base protocol;
        description
          "Base identity for data link layer protocol."; "
not really - it is the base for Ethernet but not for any other data link
layer protocol.  Also it makes
"     identity protocol {
        description
          "Base identity for Internet Protocols"; "
suspect - ethernet is not an Internet Protocol; perhaps
"     identity protocol {
        description
          "Base identity for protocols"; "


        reference
          "IEEE 802.3: IEEE Standard for Ethernet";
needs a date to make in unique

      identity transport-protocol {
        description
          "Base identity for Layer 4 protocol condition capabilities,
e.g.,
           TCP, UDP, SCTP, DCCP, and ICMP";
ICMP does not belong in the transport protocols

      identity anti-ddos {
I think that the description exceeds the permitted line length for an
RFC

As with the other three I-D, I have done a first pass, looking for what
I saw before.  I would hope to do a more detailed review later this
month.  In the case of this I-D, it would be easier if the tree diagram
was derived from the module and if the examples were validated.

Tom Petch

> Thanks.
>
> Best Regards,
> Paul
>
> On Wed, Apr 28, 2021 at 8:45 PM tom petch
<[e-mail]<mailto:[e-mail]>> wrote:
> From: Linda Dunbar
<[e-mail]<mailto:[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]<mailto:[e-mail]>>
> Sent: Tuesday, April 27, 2021 10:44 AM
> To: Linda Dunbar
<[e-mail]<mailto:[e-mail]>>;
[e-mail]<mailto:[e-mail]>
> Subject: Re: [I2nsf] Closing the WGLC for
draft-ietf-i2nsf-capability-data-model-16
>
> From: I2nsf <[e-mail]<mailto:[e-mail]>> on
behalf of Linda Dunbar
<[e-mail]<mailto:[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]<mailto:[e-mail]>
> Subject: WGLC for draft-ietf-i2nsf-capability-data-model-16
>
>
Thanks.

Best Regards,
Paul

On Wed, Apr 28, 2021 at 8:45 PM tom petch <[e-mail]<mailto:[e-mail]>> wrote:
From: Linda Dunbar <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, April 27, 2021 10:44 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16

From: I2nsf <[e-mail]<mailto:[e-mail]>> on behalf of Linda Dunbar <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/i2nsf