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

[Fernando Pereñíguez García <[e-mail]>]

Hi Tom,

Thanks for your feedback and help. We are working to address your comments
in the next version of the draft (v09).
Please, see our answers below, identified with the tag  "[Authors]".

El mar., 25 ago. 2020 a las 12:23, tom petch (<[e-mail]>)
escribió:

> 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.
>
>
*[Authors]* Fixed. The import by revision has been removed.


> 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.'
>
>
*[Authors]* Added this text to clarify the normative nature of Appendices.


> YANG is version 1.1 so RFC7950 is required.  I suggest adding [RFC7950]
> to YANG in the Introduction.


*[Authors]* Added RFC7950 and a brief text clarifying we are using YANG 1.1.


> For IANA considerations, RFC6020 is the
> better reference.
>

*[Authors] *We do not understand this comment. The IANA considerations
section has been written following the guidelines provided in RFC 8407
(section 3.8). Consequently, the current text references RFC 6020 when
registering the YANG modules names. The current IANA review state is "IANA
OK - Actions Needed", meaning that the IANA Considerations section
indicates the details of the actions correctly.


>
> NMDA[RFC8342] conformance should be stated as appropriate
>
>
*[Authors]* Clarification added in the introduction.


> YANG'import' need a reference; I see five without
>

*[Authors]* Fixed.


>
> Tree Diagrams need explaining - RFC8340 does that
>

*[Authors]* We will include new text at the end of sections 6.1 and 6.2,
explaining the type of information and how it is structured for each
module.


>
> 'revision' should be 'Initial version' at this stage with a reference to
> this I-D's title
>

*[Authors] *Fixed.


>
> 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
>
>
*[Authors] *Thanks for pointing out this. We have thoroughly revised all
yang data models to identify missing references.


> and they will each need a reference from the body of the I-D such as
> 'The YANG modules make reference to [RFC2247], ....
>
>
*[Authors]* At the beginning of Appendix A, B and C, we have included a
citation to the normative and informative references.


> I note that RFC822 and RFC3280 are Obsoleted which makes their use
> problematic.
>
>
*[Authors]*  Following your recommendation, we have replaced RFC 3280 with
RFC 5280. Regarding RFC 822, we reference it because the IKEv2 protocol
specification (RFC 7296) explicitly defines RFC 822 emails address (see
page 90) as a valid identification type. If we replace RFC 822 with RFC
2821, we don't know its impact on IKEv2.


> s.8.3
> /The YANG module/The YANG modules/
>
>
*[Authors]* Fixed.


> IANA Considerations
> The Registrant contact is usually the IESG
>

*[Authors] *Ok, updated.


>
> The prefix registered for ipsec-common is not the same as appears in
> Appendix A
>

*[Authors]* Fixed. Now the prefix registered in the declaration of module
ietf-ipsec-common is "ic".


>
> For the Web address, it is unusual to have '/about'
>
>
*[Authors]* Fixed.


> 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.
>
>
*[Authors]* Thanks for your comment. We have updated the description
associated to "leaf end" with the following text:




*End port number. The assigned value must be                      equal or
greater than the start port number.                      To express a
single port, set the same value                     as start and end.*


>
> Tom Petch
>

Best regards,
Fernando.


>
> 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
>


-- 
----------------------------------------------------------------------------------------------------
Fernando Pereñíguez García, PhD
Department of Sciences and Informatics
University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT
C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN
Tel: [phone] Fax: [phone]
------------------------------------------------------------------------------------------------------