Hi Tom, Thanks for your quick review. I will address your further comments below.
Thanks. Best Regards, Paul 2021년 9월 1일 (수) 오후 9:06, tom petch <[email protected]>님이 작성: > From: Mr. Jaehoon Paul Jeong <[email protected]> > 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 <[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 > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department Head Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
