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

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

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

Thanks.

Best Regards,
Paul

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

> From: Mr. Jaehoon Paul Jeong <[e-mail]>
> Sent: 22 April 2021 13:07
>
> Hi Tom,
> I will address your comments in the revision.
>
> <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 <[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
>