Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 15 September 2021 16:39 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 CF6983A2162 for <i2nsf@ietfa.amsl.com>; Wed, 15 Sep 2021 09:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.545
X-Spam-Level:
X-Spam-Status: No, score=-1.545 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, T_FREEMAIL_DOC_PDF=0.01, 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 9Ptkt_HUBALf for <i2nsf@ietfa.amsl.com>; Wed, 15 Sep 2021 09:39:48 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 40D3B3A2163 for <i2nsf@ietf.org>; Wed, 15 Sep 2021 09:39:47 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id i7so7063877lfr.13 for <i2nsf@ietf.org>; Wed, 15 Sep 2021 09:39:47 -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=ufg06o/ulnliNCGVqSIWlfCx5Crm/UrwN0oscU1+I74=; b=TmMkivferlQM19X3HQCXX/d3RON8+Vigv52RSOu+hQ69rhF4YN7SaR+5qQCgfx3ZZ4 Hruk6conLbegJhT0Ln/afX8bunya4dq8jBz3J19d7YCHlWZ5eigPNP4AhGG1fCldDY+C 2kdJk6Ua4jvD5Grfie+6lQoFIiY3c1V9og9LHY1onJc8IAFHBze/8PVLWeMSuzYcULvP KUqtl8fAskgGalVDON0A+BjutixTtR02DP/uCemEkJaoC9qvMEh6MIRUFr02Ik3rnOXq c7HoXpyR+Y2SytzVC36f2fDJAUzc8M5lpX6rwHyLqMzD3fg3bzD3BJnkd0Ka6KRStKFz MMAw==
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=ufg06o/ulnliNCGVqSIWlfCx5Crm/UrwN0oscU1+I74=; b=jKwZ5gvJ3IgWusO1SLhXg3jw3uB1ggHXLjE35qZW2BoZQwHM7dD5h8Wr2e6dCLydaP KS2YhCfsVpUKHvcdc3eViQ7bZgWXSxrTwPwdzYm0O+MLntxCuy6yYUtX3wHaYjgZVy/G yCHIiiLMhDZJs0mtUBqUW0cP8I3et4nYQBybjvplQ7dsEDloigtrJDwZnBzQOmA92X/t oLLmfZypZ89QCNTd7nzOmUcmhExwy6+KRwCXtAFd7ygZIBcyw6woz/DKOY2lbHL3ip29 /jVl/lRm2ITXqtT1L+wHxbhdOk3ncTt1MSsJUXqUSnhZKwIOk2N4hL6GbMFpMA2ecbyP cEpA==
X-Gm-Message-State: AOAM533XdWPHNFWsXq3SGcQWaXUTRnxslGmDmoXrN8fWLzKmENFWA7US XMyiOvTdHkP6eaLl26sxHpuq3LQ6SC+7YyjlmM0=
X-Google-Smtp-Source: ABdhPJxZunFeFFGssBvM/szhDEG6wIlsbYTNO3PqQ4/aVggJBzb3P/80+kHfhnWAACHKurPyWcA/NOW0YG6ZM96Pazo=
X-Received: by 2002:a05:6512:39d6:: with SMTP id k22mr657644lfu.258.1631723978989; Wed, 15 Sep 2021 09:39:38 -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>
In-Reply-To: <DB7PR07MB554690BDB2C189649F650B8CA2CF9@DB7PR07MB5546.eurprd07.prod.outlook.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 16 Sep 2021 01:39:02 +0900
Message-ID: <CAPK2DezeA+WKiVKYn53bEnFHQs27AiHUTF40MSE==Ax=AW6tMg@mail.gmail.com>
To: tom petch <ietfa@btconnect.com>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, Yoav Nir <ynir.ietf@gmail.com>, Roman Danyliw <rdd@cert.org>, Paul Wouters <paul@nohats.ca>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Patrick Lingga <patricklink888@gmail.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/mixed; boundary="00000000000023c42105cc0b581e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/MQjX4GXgf1asqeSoIvT8t6U73mA>
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, 15 Sep 2021 16:39:56 -0000
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. Thanks. Best Regards, Paul and Patrick On Fri, Sep 3, 2021 at 7:53 PM tom petch <ietfa@btconnect.com> wrote: > From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > Sent: 14 August 2021 08:38 > > ----- Original Message ----- > From: "Mr. Jaehoon Paul Jeong" <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> > > > > 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>> wrote: > > From: Linda Dunbar > <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>> > > Sent: Tuesday, April 27, 2021 10:44 AM > > To: Linda Dunbar > <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; > 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>> on > behalf of Linda Dunbar > <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> > > 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>> wrote: > From: Linda Dunbar <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>> > Sent: Tuesday, April 27, 2021 10:44 AM > To: Linda Dunbar <linda.dunbar@futurewei.com<mailto: > linda.dunbar@futurewei.com>>; 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>> on > behalf of Linda Dunbar <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> > 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> > 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