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

[Rafa Marin-Lopez <[e-mail]>]

Hi Tom:

Thank you very much for your insight. It is very helpful. Please see our comments/questions inline.

> El 27 oct 2020, a las 13:42, tom petch <[e-mail]> escribió:
> 
> 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

We have realized that we missed to change this, even though we discussed it. We will change it right away in the following way (bold):

case rfc822-address-string {
     leaf rfc822-address-string { 
          type string; 
          description 
              "Specifies the identity as a
               fully-qualified RFC5322 email
               address string. An example is,
               [e-mail]. The string
               MUST NOT contain any
               terminators e.g., NULL, CR,
               etc.)."; 
           reference 
                  "RFC 5322.";
     }
}

Btw, we already used in the past “case rfc822-address-string” and “leaf rfc822-address-string” since this is coming from IKEv2 standard. Do you think we should change that name as well?


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

We have included the following reference:

[IANA-Protocols-Number]
              Internet Assigned Numbers Authority (IANA), "Protocol
              Numbers", January 2020.


> 
> s.2 boiler plate is out of date

What we see is the I-D has the second choice stated in https://www.ietf.org/standards/ids/guidelines/

This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Could you refer what is out of date?
 
> 
> XXXX is standing in for more than one RFC

Yes, XXXX has been used because we do not know the future number assigned to our I-D. 

Also we realized we also included this to refer to crypto-types I-D but this has been solved now in a new version -12 that we are preparing to include your comments. We noticed we can replace the type of rw cert-data?, ca-data*, crl-data? for binary without any problem.

|           |     +--rw cert-data?        binary
|           +--rw private-key?            binary
|           +--rw ca-data*                binary
|           +--rw crl-data?               binary

> 
> 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).

You’re right. Could you point the exact part at RFC 8407 with that example? We would really appreciate it.

On the other hand, would it be enough to include the URL for Transform Type 3 https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7 ?

(Same for Transform Type 1, Transform Type 4)

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

Fixed.

import ietf-i2nsf-ikec {
            prefix nsfikec;
            reference 
                "RFC XXXX: Software-Defined Networking
               (SDN)-based IPsec Flow Protection.";
}

We still use XXXX because we do not know the number assigned to the RFC to be.

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

Fixed. 

If you have any further comments, please let us know so we can include them in -12

Best Regards.
> 
> 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]
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
>> 

-------------------------------------------------------
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]
-------------------------------------------------------