Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Mon, 04 October 2021 14:23 UTC
Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEDA3A07F3 for <i2nsf@ietfa.amsl.com>; Mon, 4 Oct 2021 07:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.542, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIh0SYwfOo8z for <i2nsf@ietfa.amsl.com>; Mon, 4 Oct 2021 07:23:42 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C1A3A07EC for <i2nsf@ietf.org>; Mon, 4 Oct 2021 07:23:41 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id j5so67440393lfg.8 for <i2nsf@ietf.org>; Mon, 04 Oct 2021 07:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HdqSKqkvegp2Y+TzeOyhLb18G0dABQCYbJNqnUJoxcw=; b=JnMSjV4m8etUQxKbLEjwmoMtNaExAbVaVN84vq9H1htVgzcF/c6xAtBVfnPUn6ogTh Kfazl9XRV2S2fQlHzRa3oDpje8YrDHQdUsXPNq2avsHcIQ8vZ2uJeMHR0aRWubvn6x6J ocJ4494AASg6wUvcHeZNV9Bx7Rom4GH6FzrVIiZ8hGXmQRFoFmL+zYgVSdN3bbLcoXr5 xjAJYnG/fjnma6FN8eoNO7HshUY0vXnt/H9bxamDqU6GbfhV17cHzvhmkLBhSCKYWa2x qHYXzrlZpE42AE9x1MEQbdeBO0ttHZukVXrKy9DrDhfYLNnxAOhjOf2ki+nXP4GpHv4I sciw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HdqSKqkvegp2Y+TzeOyhLb18G0dABQCYbJNqnUJoxcw=; b=GNiEOp26xfnIKsT6kL9kabxcMvXT80wiIedqv8LiAGfhfZIeP7qUrZzdV/UL7xvML9 9eW9GSUxsEsNEwuc//8O0hjbfzd0uSVbfK2pPl7oJ5A3muzuX+z0iYPymrihCPz2zD7z B5m621nm61LIn25+4Lj56y1j6TYeqXTrNOa2D8j2vVZJ4DKS1UhOnNaqGOpJoMpbEJEb dRoEB3mEmPc9M76vWh4XnLQUq+78QPHqQKpMCvGeN0swrYEyep4Pun7rSSI6jzsKueUY tvw6vpBbkjK+58vOQpNSf8rOtu1knfd7hfjQg9iMR1wrzLuAg8QXtT88Qu76J/mnb5j6 ImaA==
X-Gm-Message-State: AOAM533l8UWGPtkT8CShKyMw8B64GlB9D/XrWiBttGyLKC730dPa7Mk4 vQrTtuywjtt9vExiTNWWUt3EhrJUJfVQ8cqdVBM=
X-Google-Smtp-Source: ABdhPJwNdDmW7b2rXZfd4UFWcDhAGWzxDyjYRujgNzN3F72nmgCAUwA2L2P16+3bvtFf7TMsVGmV9amc8LD197EWu9I=
X-Received: by 2002:a05:6512:10ca:: with SMTP id k10mr15176449lfg.438.1633357415330; Mon, 04 Oct 2021 07:23:35 -0700 (PDT)
MIME-Version: 1.0
References: <SN6PR13MB23341DC28BD277887FBD69EC85419@SN6PR13MB2334.namprd13.prod.outlook.com> <DB7PR07MB55468323E303445356630DE3A2419@DB7PR07MB5546.eurprd07.prod.outlook.com> <SN6PR13MB23346DE068162527EC61121F85419@SN6PR13MB2334.namprd13.prod.outlook.com> <DB7PR07MB55469CA85B8ABDD2F9B961F3A2409@DB7PR07MB5546.eurprd07.prod.outlook.com> <CAPK2DewE=r5YvMRuYrcP5wcwpVwZz2C_2VH+8d4ANS5u_yHaBA@mail.gmail.com> <DB7PR07MB554690BDB2C189649F650B8CA2CF9@DB7PR07MB5546.eurprd07.prod.outlook.com> <CAPK2DezeA+WKiVKYn53bEnFHQs27AiHUTF40MSE==Ax=AW6tMg@mail.gmail.com> <DB7PR07MB55469004A40D0523E1D63331A2A29@DB7PR07MB5546.eurprd07.prod.outlook.com> <CAPK2Deyjmqq6YwO6eiAGY6x64joyAiQLWC0wkUSy-wW_kjXtjQ@mail.gmail.com> <AM6PR07MB5544F183EEAEC9F706F0772DA2AE9@AM6PR07MB5544.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB5544F183EEAEC9F706F0772DA2AE9@AM6PR07MB5544.eurprd07.prod.outlook.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Mon, 04 Oct 2021 23:22:59 +0900
Message-ID: <CAPK2Dez5qvG3Td=Nyvhjacbz6CZTsteEdyxsRqD33j6P4icmew@mail.gmail.com>
To: tom petch <ietfa@btconnect.com>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, Patrick Lingga <patricklink888@gmail.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000088372205cd87a83c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/8LiwsKWR2QQY3s1xQ2GRK2M8asw>
Subject: Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2021 14:23:51 -0000
Hi Tom, I have revised both the Capability YANG Data Model Draft and NSF-Facing Interface YANG Data Model Draft for TCP ECE and CWR Flags for Explicit Congestion Notification (ECN) as follows: - Capability YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-20 - NSF-Facing Interface YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-15 Thanks. Best Regards, Paul On Mon, Oct 4, 2021 at 6:25 PM tom petch <ietfa@btconnect.com> wrote: > From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > Sent: 29 September 2021 05:07 > Hi Tom, > Patrick and I have addressed your comments on the I2NSF Capability YANG > Data Model draft: > > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-19 > > I attach the revision letter. > > <tp> > Paul > > I note your decision to drop RFC793 and reference RFC793-bis; seems like a > timely change but since RFC793 was a Normative Reference, then I think > that 793-bis needs to be as well. (Since that I-D is being reviewed by the > IESG, I am sure it will soon progress and so will not hold up the I2NSF > I-D). > > I note that the in TCP flags of 793-bis there is no 'ecn', rather 'ece'. > I think that this will need changing in nsf-facing-interface-dm > > > Tom Petch > > Thanks. > > Best Regards, > Paul > > > On Wed, Sep 22, 2021 at 6:26 PM tom petch <ietfa@btconnect.com<mailto: > ietfa@btconnect.com>> wrote: > > From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com<mailto: > jaehoon.paul@gmail.com>> > Sent: 15 September 2021 17:39 > To: tom petch > Cc: Linda Dunbar; Yoav Nir; Roman Danyliw; Paul Wouters; i2nsf@ietf.org > <mailto:i2nsf@ietf.org>; 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" <jaehoon.paul@gmail.com<mailto: > jaehoon.paul@gmail.com><mailto:jaehoon.paul@gmail.com<mailto: > jaehoon.paul@gmail.com>>> > 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 > >< > 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 > <ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com>><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto:ietfa@btconnect.com > <mailto:ietfa@btconnect.com>>>> wrote: > > From: Linda Dunbar > <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>>> > > 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 <ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com>><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto:ietfa@btconnect.com > <mailto:ietfa@btconnect.com>>>> > > Sent: Tuesday, April 27, 2021 10:44 AM > > To: Linda Dunbar > <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>>>; > i2nsf@ietf.org<mailto:i2nsf@ietf.org><mailto:i2nsf@ietf.org<mailto: > i2nsf@ietf.org>><mailto:i2nsf@ietf.org<mailto:i2nsf@ietf.org><mailto: > i2nsf@ietf.org<mailto:i2nsf@ietf.org>>> > > Subject: Re: [I2nsf] Closing the WGLC for > draft-ietf-i2nsf-capability-data-model-16 > > > > From: I2nsf <i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org > ><mailto:i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org>><mailto: > i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org><mailto: > i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org>>>> on > behalf of Linda Dunbar > <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com><mailto: > linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>>> > > 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: i2nsf@ietf.org<mailto:i2nsf@ietf.org><mailto:i2nsf@ietf.org<mailto: > i2nsf@ietf.org>><mailto:i2nsf@ietf.org<mailto:i2nsf@ietf.org><mailto: > i2nsf@ietf.org<mailto:i2nsf@ietf.org>>> > > 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 <ietfa@btconnect.com<mailto: > ietfa@btconnect.com><mailto:ietfa@btconnect.com<mailto:ietfa@btconnect.com > >><mailto:ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com>>>> wrote: > From: Linda Dunbar <linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com><mailto:linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com>><mailto:linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com><mailto:linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com>>>> > 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 <ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com>><mailto: > ietfa@btconnect.com<mailto:ietfa@btconnect.com><mailto:ietfa@btconnect.com > <mailto:ietfa@btconnect.com>>>> > Sent: Tuesday, April 27, 2021 10:44 AM > To: Linda Dunbar <linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com><mailto:linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com>><mailto:linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com><mailto:linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com>>>>; i2nsf@ietf.org<mailto:i2nsf@ietf.org > ><mailto:i2nsf@ietf.org<mailto:i2nsf@ietf.org>><mailto:i2nsf@ietf.org > <mailto:i2nsf@ietf.org><mailto:i2nsf@ietf.org<mailto:i2nsf@ietf.org>>> > Subject: Re: [I2nsf] Closing the WGLC for > draft-ietf-i2nsf-capability-data-model-16 > > From: I2nsf <i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org><mailto: > i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org>><mailto: > i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org><mailto: > i2nsf-bounces@ietf.org<mailto:i2nsf-bounces@ietf.org>>>> on behalf of > Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com > ><mailto:linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com > >><mailto:linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com > ><mailto:linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>>> > 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: i2nsf@ietf.org<mailto:i2nsf@ietf.org><mailto:i2nsf@ietf.org<mailto: > i2nsf@ietf.org>><mailto:i2nsf@ietf.org<mailto:i2nsf@ietf.org><mailto: > i2nsf@ietf.org<mailto:i2nsf@ietf.org>>> > 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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416364721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=gTCjj1AgX850nVjMqwhSUYpi261P%2FIEPVEDlzY%2FuVs8%3D&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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=CwsgBrh%2FRpLX2x5TP%2BplrmO1ckr3VO4F56TN21h5LOM%3D&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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=RDAu7tXiFbH1WtgyJo2KL1idgWJ3s6pwQjVvJ60TLM8%3D&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 > I2nsf@ietf.org<mailto:I2nsf@ietf.org><mailto:I2nsf@ietf.org<mailto: > I2nsf@ietf.org>><mailto:I2nsf@ietf.org<mailto:I2nsf@ietf.org><mailto: > I2nsf@ietf.org<mailto:I2nsf@ietf.org>>> > https://www.ietf.org/mailman/listinfo/i2nsf >
- [I2nsf] Closing the WGLC for draft-ietf-i2nsf-cap… Linda Dunbar
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Linda Dunbar
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Linda Dunbar
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… tom petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… t petch
- Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf… Mr. Jaehoon Paul Jeong