[I2nsf] Last Call: <draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt> (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard

[tom petch <[e-mail]>]

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
[e-mail] mailing lists by 2020-09-04. Exceptionally, comments may
be sent to [e-mail] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce
.