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 (<daedulus@xxxxxxxxxxxxx>) 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.
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
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
----------------------------------------------------------------------------------------------------
Fernando Pereñíguez García, PhDDepartment 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
------------------------------------------------------------------------------------------------------
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
