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

From: Fernando Pereñíguez García <[email-masked]>
Date: Tue, 22 Sep 2020 07:17:00 +0200

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 (<[email-masked]>)
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
> [email-masked] mailing lists by 2020-09-04. Exceptionally, comments
> may
> be sent to [email-masked] 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
> [email-masked]
> 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: +34 968 189 946 Fax: +34 968 189 970
------------------------------------------------------------------------------------------------------

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2020 20:50:15 +0300

Fernando Pereñíguez García writes:
> [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. 

IKEv2 talks about RFC 822 email addresses, the reference points
Internationalized Email Headers RFC 6532, with comment of:

      Because of [EAI], implementations would be wise to treat this
      field as UTF-8 encoded text, not as pure ASCII.

So it uses RFC822 as name not as reference. There should not be any
problems to replace that with newer versions. Most of the
implementations simply consider that as a string and some cases they
actually do not even follow the string email address format, as they
add some routing information for AAAA in the end or something.
-- 
[email-masked]

---

From: Fernando Pereñíguez García <[email-masked]>
Date: Wed, 23 Sep 2020 08:16:14 +0200

Hi Tero,

Thank you very much for your clarification. We will update reference RFC
822 accordingly in our draft.

Tom, you proposed us to replace RFC 822 with 2822, but it is also obsoleted
by 5322. So, if you agree, we will reference RFC 5322 instead.

Best regards,
Fernando.

El mar., 22 sept. 2020 a las 19:50, Tero Kivinen (<[email-masked]>)
escribió:

> page

---

From: tom petch <[email-masked]>
Date: Wed, 23 Sep 2020 11:39:27 +0100

> by 5322. So, if you agree, we will reference RFC 5322 instead.

That is fine by me; my comment was that RFC822 is obsoleted by RCC2822 
so you should consider a more up-to-date version not that RFC2822 was 
the correct update!

You said previously that you did not understand my comment on RFC6020 in 
IANA Considerations.  It is fine.  What I was trying to say is that in 
most places, RFC7950 is the better reference so RFC6020 should not be 
used but for IANA Considerations, RFC6020 is the better reference so 
when updating elsewhere in the I-D, leave IANA Considerations alone.

Tom Petch

---

From: Fernando Pereñíguez García <[email-masked]>
Date: Wed, 23 Sep 2020 13:19:46 +0200

Hi Tom,

Thanks for clarifying this, now we completely understand these two
comments. We will update the next version of the draft accordingly.

Regards,
Fernando.