Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-facing-interface-dm-12.txt
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 15 September 2021 16:37 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 513633A2153 for <i2nsf@ietfa.amsl.com>; Wed, 15 Sep 2021 09:37:34 -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 YTVxOCohAQFu for <i2nsf@ietfa.amsl.com>; Wed, 15 Sep 2021 09:37:29 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 499B13A2152 for <i2nsf@ietf.org>; Wed, 15 Sep 2021 09:37:28 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id r3so2153711ljc.4 for <i2nsf@ietf.org>; Wed, 15 Sep 2021 09:37:28 -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=H39R6bt2eiTDiKQH1IWkoWki8tfpvSE6iucTxRrxGng=; b=I02kJ4LQIOHnJ11MdJvBXG+oUr7tnDx9Yzdq/qLQLQE/LvozljT3Y+BKxxHvFNmMBh j/sKOGn/zpGn6pXFgmS9B0bBOs9AV5IPirmO/VVNNHfTRbI44BeEZR0mGpGmcQ/6J0zN AVXBHoSWay3B8QpFe/oP8KrBb+CtYOqQn3YkHMsT5QaIhAN2+8JrbRRbI1zJ7k2JhZyw 6kt43vLBvdsPk7HHtOOmUuyG2SV1NsreR5DLUcr1PYHQavwPLy+0/nlRdFuYx/NPaESf RJPDvneDLWssMFMNWTF73qd94SODcZh0krzrSXtI1grfrkz+8B8WOHSwV2Jd38SKrI96 /c4A==
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=H39R6bt2eiTDiKQH1IWkoWki8tfpvSE6iucTxRrxGng=; b=pAKH/W0A2X5DrWdAxBBv8pwFQrmePpgRXh/jHYEKHDdCGHYytVaTh3UEHvDZarfA+5 hfnEgp/JQ+4NlLu546Np4y7iZZR4YJhC+wPKABxS5aoUUSFaMj/ov82y78VcVyHQZs7a 6aoq2ih4d7Ca8BijuZxq7weEnE8OPTaUa+ESXkLc+wO0rRPwAM1C8PB6dvAlIppYRhD0 n8uosIz42uIYi7LdDFiR0A98ivkMo4v+vkmcvvABeDjNmtJBdKtAMQgJesD2qvQjYzv3 UBtINb6QAhPVNeSOKlIZesbPZ9kOtBrcB7mCNHr9Y8E39fOTETW2NR5Q08MpkKpfU9U5 EO+w==
X-Gm-Message-State: AOAM531W9BrBdbpy9L0KKBegRn5F6zvF221XXMKWxNrhbyrw/xLKcOiU LtCUUPGwjLxaYghqKA0ad6rf7TNftIvC4YWXD/g=
X-Google-Smtp-Source: ABdhPJwAfZWNQ1zrlwoBs6Xa4SMb81iHCaCQ6bqV1jp7YKtpLPgpZNWgRbbalrYtQIQ4vXLL50Uvn0lUeEBRxpMRsw4=
X-Received: by 2002:a2e:9803:: with SMTP id a3mr759144ljj.423.1631723845248; Wed, 15 Sep 2021 09:37:25 -0700 (PDT)
MIME-Version: 1.0
References: <608009A7.9050907@btconnect.com> <CAPK2DezBVxzidy1BrLQoEqhhE8Zon2S=MPKBuEXTEsnh2umR9g@mail.gmail.com> <AM6PR07MB554474A522662F5842502C5DA2CD9@AM6PR07MB5544.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB554474A522662F5842502C5DA2CD9@AM6PR07MB5544.eurprd07.prod.outlook.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 16 Sep 2021 01:36:48 +0900
Message-ID: <CAPK2DexSbn1f3t-HK5N0ZAhXORszmfiRn1OWqe3Jf6C1eZcFDQ@mail.gmail.com>
To: tom petch <ietfa@btconnect.com>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, Roman Danyliw <rdd@cert.org>, Linda Dunbar <linda.dunbar@futurewei.com>, Yoav Nir <ynir.ietf@gmail.com>, Patrick Lingga <patricklink888@gmail.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/mixed; boundary="0000000000002b0b1b05cc0b50ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/c8z9nQXGjeHETf-30dy3_RK4wwk>
Subject: Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-facing-interface-dm-12.txt
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:37:35 -0000
Hi Tom, Here is the revision to reflect your comments on the I2NSF NSF-Facing Interface Data Model: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-14 I attach the revision letter. Thanks. Best Regards, Paul and Patrick On Wed, Sep 1, 2021 at 9:06 PM tom petch <ietfa@btconnect.com> wrote: > From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > Sent: 15 August 2021 11:34 > To: tom petch > > Hi Tom, > Here are the revision letter and revised draft reflecting your comments. > > > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-13 > > You can find my responses to your comments from page 1 in the revision > letter. > > Patrick and I worked together for this revision. > > Please let me know whether this version satisfies your comments or not. > > <tp> > > Looks good, much easier to read so thank you for the masses of changes. I > will need to take another look to let it all sink in but do have some minor > suggestions pro tem. > > Some references I think need adding to the I-D references > RFC4443 > RFC5595 > and while there are two separate references for ICMP IANA, v4 and v6, in > the module there is only one in the I-D reference; IANA has two separate > groups so I think that this needs bringing in line > > http: needs to be https: > > identity ingress-action > is described as > Base identity for action > which it is not! Other I-D do have a base action from which ingress, > egress etc are derived so perhaps bring the structure in line rather than > just change the description. > > leaf-rule-priority > /till/up to/ > > container long-connection > I would value a longer description of what this is > > container period{ > could do with another space > > rule-group > I am unclear about this. Do the start and end rule point to the list of > rules defined earlier, ie is this a leaf ref? How is the list ordered, hat > starts and ends a list? I think of start and end in numeric terms as for > address or port, or else alphabetic? I am unclear what this does > > leaf enable > /This is enable/True is enabled/ > perhaps > > Tom Petch > Thanks. > > Best Regards, > Paul > > On Wed, Apr 21, 2021 at 8:17 PM t petch <ietfa@btconnect.com<mailto: > ietfa@btconnect.com>> wrote: > This I-D is technically ok but I think asks more of users than is > necessary. I get the feeling of the wheel being reinvented but with a > few additions so that it is hexagonal in shape making for a bumpy ride:-) > > An example of this comes in the specification of ranges which occurs > several times. sdn-ipsec [draft-ietf-i2nsf-sdn-ipsec-flow-protection] > achieves this with > grouping port-range { > leaf start {type inet:port-number; } > leaf end { type inet:port-number; > with a note that when only one value is needed, then start=end; this is > a common pattern throughout the IETF. This I-D has > +--rw pkt-sec-tcp-src-port-num > +--rw (match-type)? > +--:(exact-match) > +--rw port-num* inet:port-number > +--:(range-match) > +--rw range-port-num* [start-port-num end-port-num] > +--rw start-port-num inet:port-number > +--rw end-port-num inet:port-number > more complex YANG, more complex identifiers - in the context, 'start' > and 'end' seem quite enough. This applies in many such ranges in the I-D. > > The choice of identifier is equally prolix in other places. The nature > of a YANG identifier is (almost always) apparent from the > context; -type, -container and such like just get in the way. And if a > compound name is needed, then I find putting the more significant > elements first the clearer although manyt of the instances here would be > eliminated by using just 'start' and 'end'. In a similar vein you have > +--rw packet-security-ipv6-condition > +--rw ipv6-description? string > +--rw pkt-sec-ipv6-traffic-class* identityref > +--rw pkt-sec-ipv6-flow-label > +--rw pkt-sec-ipv6-payload-length > Are all those pkt-sec-ipv6 adding anything given the context of > packet-security-ipv6-condition? This occurs repeatedly. (The > nomenclature in several places is also out of line with other i2nsf > I-D). > > Equally, the specification of frequency seems overly complex. > 'consumer-facing' has > leaf start-time { > type time; > leaf-list date { > type int32{ > range "1..31"; > > identity day { > leaf-list day { > > leaf-list month { > type string{ > pattern '\d{2}-\d{2}'; > where this I-D has such as > typedef day-type > typedef month-type > typedef start-time-type > typedef end-time-type > different YANG constructs - identity v type, ad-hoc types, different > choices of how many points in time can be specified, one off versus > list, more complex constructs and, well, just different, another > accretion to the wheel. > > There are many references but they often poor, compared with other i2nsf > I-D. The reference to IANA needs a URL and think is unhelpful in most > cases where it appears. Protocols such as EIGRP are RFC but that is not > mentioned. > > The I-D almost always has separate constructs for IPv4 and IPv6; why? > RFC6991 provides IP version neutral types which e.g. sdn-ipsec uses > widely. It is as if an entity here is expected to have one IPv4 address > and one IPv6 address and that both need specifying. > > By contrast, ICMPv6 is largely ignored. Yes, it appears as a protocol > but there are more than fifty ICMP error messages listed and these are > v4; some carry across to v6, others do not. > > In a similar vein, most I-D separate OSPFv2 and OSPFv3, deriving them > from a common OSPF identity which is derived from a protocol base. Is > the difference of no import here? > > Tom Petch > > ----- Original Message ----- > From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> > To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>> > Cc: <i2nsf@ietf.org<mailto:i2nsf@ietf.org>> > Sent: Monday, March 08, 2021 2:26 PM > Subject: I-D Action: draft-ietf-i2nsf-nsf-facing-interface-dm-12.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Interface to Network Security > Functions WG of the IETF. > > > > Title : I2NSF Network Security Function-Facing > Interface YANG Data Model > > Authors : Jinyong (Tim) Kim > > Jaehoon (Paul) Jeong > > Jung-Soo Park > > Susan Hares > > Qiushi Lin > > Filename : > draft-ietf-i2nsf-nsf-facing-interface-dm-12.txt > > Pages : 102 > > Date : 2021-03-08 > > > > Abstract: > > This document defines a YANG data model for configuring security > > policy rules on Network Security Functions (NSF) in the Interface > to > > Network Security Functions (I2NSF) framework. The YANG data model > in > > this document corresponds to the information model for NSF-Facing > > Interface in the I2NSF framework. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-d > m/ > <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/> > < > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-12 > > > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interf > ace-dm-12 > <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-12> > < > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-12 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-nsf-facing-interface- > dm-12 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-nsf-facing-interface-dm-12> > < > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-nsf-facing-interface-dm-12 > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org< > http://tools.ietf.org>. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > . > > > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org<mailto:I2nsf@ietf.org> > https://www.ietf.org/mailman/listinfo/i2nsf >
- [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-facing-i… internet-drafts
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… t petch
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… tom petch
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… tom petch
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-faci… tom petch