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 protected]>
To: <[email protected]>
Cc: <[email protected]>
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 protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
