Looking at the YANG module from a different perspective from that of a
YANG Doctor or a IPsec WG Chair, there is quite a lot of editing needed.
'2019' appears 10 times and I suspect most should be 2020; one is an
import by revision which is uncommon because of potential, future,
compatibility problems.
Conventionally, Appendices are Informative and YANG modules are
Normative so if you want the modules to be Normative,I suggest adding to
Appendices A, B, C
'This Appendix is Normative.'
YANG is version 1.1 so RFC7950 is required. I suggest adding [RFC7950]
to YANG in the Introduction. For IANA considerations, RFC6020 is the
better reference.
NMDA[RFC8342] conformance should be stated as appropriate
YANG'import' need a reference; I see five without
Tree Diagrams need explaining - RFC8340 does that
'revision' should be 'Initial version' at this stage with a reference to
this I-D's title
Lots of references - good - but they need to appear in the I-D
References, mostly, probably, Normative. I see no I-D Reference for
822 - ood 2821?
2247 -
3280 - ood 5280?
3947 -
4303 -
5280 -
5915 -
7383 -
7427 -
7619 -
8017 -
8174 -
8221 -
X.690
I-D Common YANG Data Types for Cryptography
IANA Registry Internet Key Exchange Version 2 Parameters
IANA Registry- Transform Type 1
IANA Registry- Transform Type 3
IANA Registry Protocol Numbers
and they will each need a reference from the body of the I-D such as
'The YANG modules make reference to [RFC2247], ....
I note that RFC822 and RFC3280 are Obsoleted which makes their use
problematic.
s.8.3
/The YANG module/The YANG modules/
IANA Considerations
The Registrant contact is usually the IESG
The prefix registered for ipsec-common is not the same as appears in
Appendix A
For the Web address, it is unusual to have '/about'
grouping port-range
with a range, it is usual to specify how a single address is specified,
e.g. the absence of 'end' or 'start'='end' and for a YANG must to
require end>start or end>=start as appropriate. The use of key 'start
end' implies that 'start' and 'end' must both be present.
Tom Petch
The IESG has received a request from the Interface to Network Security
Functions WG (i2nsf) to consider the following document: - 'Software-Defined
Networking (SDN)-based IPsec Flow Protection'
<draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2020-09-04. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.
Abstract
This document describes how to provide IPsec-based flow protection
(integrity and confidentiality) by means of an I2NSF Controller. It
considers two main well-known scenarios in IPsec: (i) gateway-to-
gateway and (ii) host-to-host. The service described in this
document allows the configuration and monitoring of IPsec information
from a I2NSF Controller to one or several flow-based Network Security
Function (NSF) that implement IPsec to protect data traffic.
The document focuses on the I2NSF NSF-Facing Interface by providing
YANG data models for configuration and state data required to allow
the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD)
and IKEv2 to establish IPsec Security Associations with a reduced
intervention of the network administrator.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
..
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
