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

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

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.

Thanks.

Best Regards,
Paul

On Wed, Apr 21, 2021 at 8:17 PM t petch <[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]>
> To: <[e-mail]>
> Cc: <[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/>
> >
> > 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.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [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]
> https://www.ietf.org/mailman/listinfo/i2nsf
>