Thanks for getting this done and published.
We will wait with requesting publication until the I2NSF session next week.
Between now and then, please re-read the draft and send a message to the list
is something is seriously wrong.
Barring any such shouting, we will request publication right after the meeting.
Thanks again,
Linda and Yoav
> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <r...@um.es> wrote:
>
> Dear all:
>
> We submitted a new version of the I-D (v05) where we have applied several
> changes. In the following you have a summary of the main changes, which we
> will expand/explain during our presentation:
>
> - We have dealt with YANG doctors’ review (Martin's)
>
> - We have dealt with Paul Wouters’ comments and Tero’s comments.
>
> - We have added more specific text in the descriptions.
>
> - Notifications have a simpler format now since most of the information that
> contained in the past is already handled by the Security Controller.
>
> - State data has been reduced. For example, in IKE case, most of the
> information is related with IKE and not with the specific details about IPsec
> SAs that IKE handles (after all, IKE can abstract this information from the
> Security Controller).
>
> - We have included text in the security section to discuss about the default
> IPsec policies that should be in the NSF when it starts before contacting
> with the SC such as the IPsec policies required to allow traffic between the
> SC and the NSF.
>
> - We have added a subsection 5.3.4 about NSF discovery by the Security
> Controller.
>
> - In order to specify the crypto-algorithms we have used a simple approach by
> including an integer and adding a text pointing the IANA in the reference
> clause. For example:
>
> typedef encryption-algorithm-type {
> type uint32;
> description
> "The encryption algorithm is specified with a 32-bit
> number extracted from IANA Registry. The acceptable
> values MUST follow the requirement levels for
> encryption algorithms for ESP and IKEv2.";
> reference
> "IANA Registry- Transform Type 1 - Encryption
> Algorithm Transform IDs. RFC 8221 - Cryptographic
> Algorithm Implementation Requirements and Usage
> Guidance for Encapsulating Security Payload (ESP)
> and Authentication Header (AH) and RFC 8247 -
> Algorithm Implementation Requirements and Usage
> Guidance for the Internet Key Exchange Protocol
> Version 2 (IKEv2).";
> }
>
> - We have included three additional Annexes with examples in about the usage
> of the YANG model.
>
> - We have performed pyang --lint --lint-ensure-hyphenated-names and pyang -f
> yang --yang-line-length 69 in our model without warnings.
>
> Best Regards.
>
>> Inicio del mensaje reenviado:
>>
>> De: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>> Asunto: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>> Fecha: 7 de julio de 2019, 23:34:03 CEST
>> Para: <i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>>
>> Cc: i2nsf@ietf.org <mailto:i2nsf@ietf.org>
>> Responder a: i2nsf@ietf.org <mailto:i2nsf@ietf.org>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Interface to Network Security Functions WG
>> of the IETF.
>>
>> Title : Software-Defined Networking (SDN)-based IPsec Flow
>> Protection
>> Authors : Rafa Marin-Lopez
>> Gabriel Lopez-Millan
>> Fernando Pereniguez-Garcia
>> Filename : draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>> Pages : 81
>> Date : 2019-07-07
>>
>> Abstract:
>> This document describes how providing IPsec-based flow protection by
>> means of a Software-Defined Network (SDN) controller (aka. Security
>> Controller) and establishes the requirements to support this service.
>> It considers two main well-known scenarios in IPsec: (i) gateway-to-
>> gateway and (ii) host-to-host. The SDN-based service described in
>> this document allows the distribution and monitoring of IPsec
>> information from a Security Controller to one or several flow-based
>> Network Security Function (NSF). The NSFs implement IPsec to protect
>> data traffic between network resources.
>>
>> The document focuses on the NSF Facing Interface by providing models
>> for configuration and state data required to allow the Security
>> Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>> to establish Security Associations with a reduced intervention of the
>> network administrator.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
>> <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/>
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
>> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>
> -------------------------------------------------------
> Rafa Marin-Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es <mailto:r...@um.es>
> -------------------------------------------------------
>
>
>
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
