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

From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
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 <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> 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: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Cc: <i2nsf@ietf.org<mailto:i2nsf@ietf.org>>
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<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
> 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
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf