Hi Tom, We authors will consider your comments on frequency. Thanks.
Best Regards, Paul 2021년 4월 23일 (금) 오후 6:43, tom petch <[email protected]>님이 작성: > 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/> > < > 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 > > [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
