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

From: t petch <[email-masked]>
Date: Wed, 21 Apr 2021 12:16:56 +0100

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-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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/
>
> 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
>
> A diff from the previous version is available at:
>
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
> [email-masked]
> 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
> .
>
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 22 Apr 2021 21:07:46 +0900

Hi Tom,
I will address your comments in the revision.

Best Regards,
Paul

On Wed, Apr 21, 2021 at 8:17 PM t petch <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/>
> >
> <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-12>
> >
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-nsf-facing-interface-dm-12>
> >
> >
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

---

From: tom petch <[email-masked]>
Date: Fri, 23 Apr 2021 09:43:45 +0000

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: 22 April 2021 13:07

Hi Tom,

<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-masked]<mailto:[email-masked]>> 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:-)

          identity day {
               leaf-list day {

               leaf-list month {
                 type string{
                   pattern '\d{2}-\d{2}';

Tom Petch

----- Original Message -----
From: <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 08, 2021 2:26 PM
Subject: I-D Action: draft-ietf-i2nsf-nsf-facing-interface-dm-12.txt

directories.
to
in
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/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://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>
submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 23 Apr 2021 19:48:39 +0900

Hi Tom,
We authors will consider your comments on frequency.

Thanks.

Best Regards,
Paul

2021년 4월 23일 (금) 오후 6:43, tom petch <[email-masked]>님이 작성:

> 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
>
> <
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/
> >
> >
> <
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-12
> >
> >
> <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-nsf-facing-interface-dm-12
> >
> >
> >