Re: [I2nsf] I-D Action: draft-ietf-i2nsf-nsf-facing-interface-dm-12.txt

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <[e-mail]>님이 작성:

> From: Mr. Jaehoon Paul Jeong <[e-mail]>
> 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 <[e-mail]<mailto:
> [e-mail]>> 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: <[e-mail]<mailto:[e-mail]>>
> To: <[e-mail]<mailto:[e-mail]>>
> Cc: <[e-mail]<mailto:[e-mail]>>
> 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
> > [e-mail]<mailto:[e-mail]>
> > 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
> [e-mail]<mailto:[e-mail]>
> 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: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>