From: Mr. Jaehoon Paul Jeong <[email protected]> Sent: 22 April 2021 13:07
Hi Tom, I will address your comments in the revision. <tp> Paul My comments on frequency are perhaps worth expanding. In places, the two I-D are providing the same function but in different ways and this nsf facing I-D has, for me, a more complex way which I then think inferior. However, in other places the function is different between nsf facing and consumer facing and I am uncertain whether that is by design or not. If by design, then there would be differences in the YANG as well. Tom Petch Best Regards, Paul On Wed, Apr 21, 2021 at 8:17 PM t petch <[email protected]<mailto:[email protected]>> 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: <[email protected]<mailto:[email protected]>> To: <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> 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/> > > 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> > > 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> > > > 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 > [email protected]<mailto:[email protected]> > 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
