Re: [I2nsf] [Last-Call] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

[tom petch <[e-mail]>]

I think that the IESG will find a number of problems with this I-D.

YANG module references RFC822 which is several years out of date

YANG module references IANA Protocol Numbers which is not in the I-D 
references

s.2 boiler plate is out of date

XXXX is standing in for more than one RFC

but the show stopper that makes a proper review of this too costly is 
the references.  Those to IANA of which there are several I want to 
pursue.  The I-D reference is to IKEv2 parameters. Sadly, this is a 
three tier structure and noone agrees on what to call the third tier so 
I will call it tier3 here.  Top level is Group, as per RFC8126, second 
level is Registry.  The I-D reference is to the Group only which is fine 
if the actual reference then specifies the Registry and Tier3 but they 
never do, usually just Tier3 e.g. Transform Type 3 which makes for a lot 
of work for the reader, too much for this one.  You have to go hunting 
in all the second level Registry until you can find a match for the 
Tier3 identifier. And there are no URL.  If you want an example that I 
find easy to use, go look at RFC8407 (as usual).

The reference for import of i2nsf-ikec gives a YANG module name; this 
needs to be the name of the RFC to be

The example IPv6 address in the YANG module has :0:0: which is usually 
just ::

And I have some way to go still.

Tom Petch

On 22/10/2020 18:39, Rafa Marin-Lopez wrote:
> Dear all:
>
> After receiving a suggestion to make things clearer in the feature ikeless-notification description, we have just uploaded a new version -11 with a minor change to add the following text:
>
> feature ikeless-notification {
>              description
>                  "This feature indicates that the server supports
>                  generating notifications in the ikeless module.
>
>                  To ensure broader applicability of this module,
>                  the notifications are marked as a feature.
>                  For the implementation of ikeless case,
>                  the NSF is expected to implement this
>                  feature.";
>          }
>
> Best Regards.
>
>> Inicio del mensaje reenviado:
>>
>> De: [e-mail]
>> Asunto: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>> Fecha: 22 de octubre de 2020, 15:32:50 CEST
>> Para: "Fernando Pereniguez-Garcia" <[e-mail]>, "Rafael Lopez" <[e-mail]>, "Gabriel Lopez-Millan" <[e-mail]>, "Rafa Marin-Lopez" <[e-mail]>
>>
>>
>> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>> has been successfully submitted by Rafa Marin-Lopez and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-i2nsf-sdn-ipsec-flow-protection
>> Revision:	11
>> Title:		Software-Defined Networking (SDN)-based IPsec Flow Protection
>> Document date:	2020-10-22
>> Group:		i2nsf
>> Pages:		92
>> URL:            https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>
>> Abstract:
>>    This document describes how to provide IPsec-based flow protection
>>    (integrity and confidentiality) by means of an Interface to Network
>>    Security Function (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 Security Associations (SAs)
>>    from a I2NSF Controller to one or several flow-based Network Security
>>    Functions (NSFs) that rely on IPsec to protect data traffic.
>>
>>    The document focuses on the I2NSF NSF-facing interface by providing
>>    YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
>>    and IKEv2.  This allows IPsec SA establishment with minimal
>>    intervention by the network administrator.  It does not define any
>>    new protocol.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>>
>
> -------------------------------------------------------
> Rafa Marin-Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
>
>
>
>
>
>
>