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