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

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

Hi Tom,
I will address your comments below.

Thanks.

Best Regards,
Paul


On Wed, Sep 22, 2021 at 6:26 PM tom petch <[e-mail]> wrote:

>
> From: Mr. Jaehoon Paul Jeong <[e-mail]>
> Sent: 15 September 2021 17:39
> To: tom petch
> Cc: Linda Dunbar; Yoav Nir; Roman Danyliw; Paul Wouters; [e-mail];
> Patrick Lingga; Mr. Jaehoon Paul Jeong
> Subject: Re: [I2nsf] Closing the WGLC for
> draft-ietf-i2nsf-capability-data-model-16
>
> Hi Tom,
> Here is the revision to reflect your comments on the I2NSF Capability Data
> Model:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-18
>
> I attach the revision letter.
>
> <tp
> Paul
>
> Getting there.
>
> I think that the references in -18 still need some attention.
>
> I think that RFC6691 is a Downref, a Normative Reference to a document
> that is not Standards Track, which will need calling out by the AD at
> Last Call; RFC2818 is similar but has been approved previously as a
> Downref.
>
> RFC2616 is obsolete; trouble is it has expanded into six RFC, two of
> which you list, not sure what is appropriate.
> RFC4250 needs adding to the I-D References
> RFC5101 is obsoleted by RFC7011
> RFC793 and RFC793bis both appear; I am unclear whether or not both are
> needed
> There are a number of http:// in the I-D References which need to be
> https://
>
> '  http://dx.doi.org/10.5210/fm.v10i1.1204  '
> wants to download an app; being security conscious, I - of course - said
> 'No'!
>
> A quick look at some of the text found
>
> s.1
> '   NSF.  Note that this YANG data model structurizes the NSF
> Monitoring'
> I am not familiar with 'structurizes'; 'structures' would seem
> inappropriate
>
> s.3
> '   independent manner (e.g., regardless of the differences among
> vendors'
> perhaps 'i.e'. not 'e.g.'
>
> s.3.1
> '   An I2NSF Policy Rule is made up of three Boolean clauses: an Event
>    clause, a Condition clause, and an Action clause.  '
> I struggle to see the action clause as Boolean
>
> There is a mismatch between the Authors of the I-D and the Editors of
> the YANG module.  The YANG has gained one and lost two.
>
> Tom Petch
>
> >
> > I attach the revision letter.
> >
> > Thanks.
> >
> > Best Regards,
> > Paul and Patrick
> >
> ----- Original Message -----
> From: "Mr. Jaehoon Paul Jeong" <[e-mail]<mailto:
> [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
> <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-17>
> <
> 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.
>
> 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]><mailto:
> [e-mail]<mailto:[e-mail]>>> wrote:
> > From: Linda Dunbar
> <[e-mail]<mailto:[e-mail]><mailto:
> [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]><mailto:
> [e-mail]<mailto:[e-mail]>>>
> > Sent: Tuesday, April 27, 2021 10:44 AM
> > To: Linda Dunbar
> <[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>;
> [e-mail]<mailto:[e-mail]><mailto:[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]
> ><mailto:[e-mail]<mailto:[e-mail]>>> on
> behalf of Linda Dunbar
> <[e-mail]<mailto:[e-mail]><mailto:
> [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]><mailto:[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]><mailto:[e-mail]<mailto:[e-mail]>>>
> wrote:
> From: Linda Dunbar <[e-mail]<mailto:
> [e-mail]><mailto:[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]><mailto:
> [e-mail]<mailto:[e-mail]>>>
> Sent: Tuesday, April 27, 2021 10:44 AM
> To: Linda Dunbar <[e-mail]<mailto:
> [e-mail]><mailto:[e-mail]<mailto:
> [e-mail]>>>; [e-mail]<mailto:[e-mail]
> ><mailto:[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]><mailto:
> [e-mail]<mailto:[e-mail]>>> on behalf of
> Linda Dunbar <[e-mail]<mailto:[e-mail]
> ><mailto:[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]><mailto:[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]><mailto:[e-mail]<mailto:
> [e-mail]>>
> https://www.ietf.org/mailman/listinfo/i2nsf
>