Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16
tom petch <ietfa@btconnect.com> Wed, 28 April 2021 11:45 UTC
Return-Path: <ietfa@btconnect.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 560043A2691 for <i2nsf@ietfa.amsl.com>; Wed, 28 Apr 2021 04:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 wUT9k-ibeiVX for <i2nsf@ietfa.amsl.com>; Wed, 28 Apr 2021 04:45:09 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2092.outbound.protection.outlook.com [40.107.21.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287DB3A2694 for <i2nsf@ietf.org>; Wed, 28 Apr 2021 04:45:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jnq8CYorowT6hVnn3+fCVqCBGbgbZcOu28U6kqcs5ZgyHvINEjhqh3WlfXAaOcA0vvhVW4h270fea+ao4lp2cyzTZEVZu3ffpxdu1mpngotROsOuLf7dN3K80YM81Rv0o4UOJA/I9WlrV2lSlbFmRzTnIfcGVLCmUcvM3aXcAtAlqxHd/oT6XQ6TN1+F0bHcPbl4VYr9L+0emfZAOa0lXAk4oOx8+72S4soRI/lxP3E8CIJh+/+1EEsgOa8g42jWIW3oi7i6LlBl33TAgyP5wElf7Tv6tyL+xTQoM2YjuOkiruLQcaL89WNcIc9ym45IqBIyAc8vyiW+pPWMzxGGmA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bJFGHY9De1VpBxM/8Tn/cIIO3qftTs5vIj2OfI0/Txg=; b=W0tY2KU4e21Z25k4xWEU1Fl9dUNsRaFFUi+Qj+8Q1uLobjxTIjz6Gyeq26hcOC3IyLlOosI4LqqO+bWcnjIIYZYS/zn5EBM+23r7p8RwArFZAPHdo26MtzWp9AL2/BP2LvPdXzl6WfQOkih5lSTWSAvVHZHUcm2sgbywSIDGADtZgJwu54dxRQvlD8jwLaeaZ8Xjs3UPVU0N4q4YcAL8sL4+Zyfe0DM2Os7n+2V9hRK4bAtpCMg4Ugke/RL1+Jfe4DjHHuY4Vjw5Bc0j3fMmApMpCT/dNNHA7I95xoNQwO+8xiycTMxZjTKbXLS2psDqU4jfe77byWh/Hhwwx2L4AA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bJFGHY9De1VpBxM/8Tn/cIIO3qftTs5vIj2OfI0/Txg=; b=sIkzWIDTsV/uPWgwr+znEp11KPD7d3xpEzCRIENHTZw+228LuRFNUvFnt1QnVPIAScVj7AjF0gO722tpxQf+1LrWOO+fmvh1Ii26l/XsZDtP4xS5cZb7mhRkxWnJ4RVRraLEsKSSGnjcgigEbtKD5utmztO7N70+GkZRc0xnjvI=
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DB6PR0701MB2167.eurprd07.prod.outlook.com (2603:10a6:4:50::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.8; Wed, 28 Apr 2021 11:45:05 +0000
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::ddb2:16dd:9380:90c7]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::ddb2:16dd:9380:90c7%3]) with mapi id 15.20.4087.025; Wed, 28 Apr 2021 11:45:05 +0000
From: tom petch <ietfa@btconnect.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Thread-Topic: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16
Thread-Index: Adc7dtk38TjktS8NTAuCAcVXZpAN9wAAd5YMAAELvAAAKT9GCw==
Date: Wed, 28 Apr 2021 11:45:05 +0000
Message-ID: <DB7PR07MB55469CA85B8ABDD2F9B961F3A2409@DB7PR07MB5546.eurprd07.prod.outlook.com>
References: <SN6PR13MB23341DC28BD277887FBD69EC85419@SN6PR13MB2334.namprd13.prod.outlook.com> <DB7PR07MB55468323E303445356630DE3A2419@DB7PR07MB5546.eurprd07.prod.outlook.com>, <SN6PR13MB23346DE068162527EC61121F85419@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB23346DE068162527EC61121F85419@SN6PR13MB2334.namprd13.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.143.250.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dd15a8e8-8996-4b9a-66cb-08d90a3b1129
x-ms-traffictypediagnostic: DB6PR0701MB2167:
x-microsoft-antispam-prvs: <DB6PR0701MB21673F25BE6442CB5466FAC5A2409@DB6PR0701MB2167.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OauDN7eijSQnkAhlcKk5GfCQstGvPf7biBEWBvZMyxZOM8iUqoZEn5AHpYGKfwW5StOP/EmR3sZgicC/wm+u2DEVvh2AqeI1PmLBWr2IaiUWfr+X+EizG5zJkpOnOZMzDngfvpOsGigVrrgHd3R2viU484QLBsl8kpQqaiGbSxGofYHHmsROpwXtv/HgGUB5UNKFeDXI1318osHw0Pk3BOM5atHsk9lEOZgCYezLhBh+LhWQirWGiHJWkBFsXVKb1qruK70LxAEXmNdayrFhD+v3X/WTrx4nIZcn1i/Qn5rpxIgvfaOoVPI9kIq2lH2qbo7ZgwfT/eZyZ+/0w/yc65K/7rGjek+fFMQVWaPQvHftVluQtwYJbnK84tJK2trjB93emqHNA8t8vXXYJACZ5PZWK9UsUW+6faqfBTA6dOid5+JkCthqQ2yXoejCnmf3OxOF8I0t+lfPoE+Vf8JU5GlxN9GlpLFpgvm56leXGzvNa4CxMUivxaEMHtymszpZC0GDgcHneZNYH7TaE01n/kAR04rBvtPEphIa+uLrJLMr4sr25qc4A3ZdadqMlPJpp8owOnvOaluDFSsaB1NUD1RRAMz/rur3zS0y3JYszjFF/6Z2UL4p0L8at0yxO6EVspMIy+tUbH5ThRcyQZ3LU6nxMv66WPAiG+f4ILtr7RM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(396003)(39860400002)(366004)(478600001)(38100700002)(186003)(9686003)(122000001)(26005)(55016002)(966005)(33656002)(83380400001)(316002)(110136005)(66574015)(8676002)(86362001)(53546011)(66446008)(5660300002)(6506007)(2906002)(8936002)(7696005)(71200400001)(30864003)(91956017)(64756008)(45080400002)(66556008)(66476007)(52536014)(76116006)(66946007)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: cOQAJvyZj0S/uti8WVJqXe3HfIKmNv7M4rDnLBCYUwdFJYrVh5sGjvTtR8wNX2E/qpYMDsCNFk/zYa//yiZ3erUe8hGYBj7pKVi1mNUZoYMKJzLov4biSWyMC5C/2B5l4KdjeZeSuLN2CGQXldG1fPUV8HmS7DG/0MBv3A/EloFe4UvbPgMgMCQyNATzqtoT/XbuuPieBGhpQfZg/Fpfp33DyADyOgf2hLpmvBTAYeNK9t0UjXaN39eoh+R2xwgxyj1xPsMSZT+QKQqs6hX88eH1UW3Fk9UcCV0IZjbdqX/vufh1bhX/Q1KIGTjAl91R56Rs/MSypWV4GuiLfWGsu7k+VZzU8hyrxl8l9HGSPhUD2PIEKc2eb8mN/fHQZBX+uH/2uIOxFmk2oQNDVHTyPAnyUNFYue0bS6rWChHEzw8Fq0cs6sssriWxXKSLsj/FOyDlvP5m0ZiJkPCQPtrRhF3hVUFODDKwwwGfn20w3jOt74Dxt9J/1T6mgpIA7Y9VtuzhR5n4eV+DG2ZdI6l05SqnCqV2RVgnxTIx29NU90/Z84ew3Ovi8roNHyrL2FOqWXO5XS0Ms3FubgMnj/L0Y5FE7QUnqC/PQsi4UaOdeVoY3NNU01uaJJEh8fGCIiPRnSFevvnl0UnhWAqTJU3fA/yj9yh7039q84zdwXjVVkmBBGGU5HOje0dRVKjACkWzJXWoyJqtzPaJAckb8HPmSnkqPGgD1PsWDP8M+xoZpDmEq7SYD4V+zSgiYuAF5HcRzciszwfmEp/HWgg2AZrgdSFluCZXACiO8tqrSsJA/hAJ2TiHchjZNLqIs4JMuOx0MbyRphJsqWBMhSSNsNbvOzEGcP+Omx1yINMvWIxnqAHwWTvtmIhRKuNpXgjMLe91ZZlTkH6Ge9HVb8fUTFicOCvxW0P0oN212Ze4OES8OUkC4XKGpmGAlKAL+DroPRhmjAUcJ9AtVvioRG1fNhl4q/3J6U9VoXO7/sh/yoS7IA1AKZ/iRN+4nJEFX2CKcp3CZ/c+OoagJlt4G0hVHFu3aih6FyHBxGXidbOYmJqUZWQFnk1lzHNVeOqe3j3s6KjoBrJhw5dIESR141WmPymnA26D9Iq/93qQN4CdnqpzxiaKh+3R189QO6rlVqi8pUS/bcswXsAAaerGssID9X2i8ZEoytkYLh8RWLAHeSo+cVwRRCcNei8s6ug2njXspQcSgaX/heA9AG2ULu/X0hjp6WXZKOrp3N0i+kabJNg7hTi36nrcYYsc2hlBBdF7Z5G+KiU+oAUeH2HVlUGnyKykzTe8u4cMcGhKqKhDPMruYJU=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd15a8e8-8996-4b9a-66cb-08d90a3b1129
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 11:45:05.5041 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6XouTIPINdCc54yFAR2o//v59AdUR+BcGKLcTeFADVA41KzNvDKpf0VH+QRjQg0Czc3IzHUYXqxOytOclNjtPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2167
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/K9Ae3l6eaZrPATcHJXFH9xZMQAU>
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: Wed, 28 Apr 2021 11:45:14 -0000
From: Linda Dunbar <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> Sent: Tuesday, April 27, 2021 10:44 AM To: Linda Dunbar <linda.dunbar@futurewei.com>; i2nsf@ietf.org Subject: Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16 From: I2nsf <i2nsf-bounces@ietf.org> on behalf of Linda Dunbar <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 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] 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