Re: [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Rafa Marin-Lopez <rafa@um.es> Tue, 22 September 2020 13:05 UTC

Return-Path: <rafa@um.es>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B173A0D7C; Tue, 22 Sep 2020 06:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu7-PQ9H65KI; Tue, 22 Sep 2020 06:05:35 -0700 (PDT)
Received: from mx01.puc.rediris.es (outbound4mad.lav.puc.rediris.es [130.206.19.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDDD3A0D7B; Tue, 22 Sep 2020 06:05:34 -0700 (PDT)
Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by mx01.puc.rediris.es with ESMTP id 08MD5NOX021011-08MD5NOY021011; Tue, 22 Sep 2020 15:05:23 +0200
Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 0BDD4218A3; Tue, 22 Sep 2020 15:05:23 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon43.um.es
Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n5is1bVaCk7k; Tue, 22 Sep 2020 15:05:22 +0200 (CEST)
Received: from [192.168.1.36] (198.red-2-138-84.dynamicip.rima-tde.net [2.138.84.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id E9FBB2102E; Tue, 22 Sep 2020 15:05:16 +0200 (CEST)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2A7A8BA-328F-4742-9A5A-56DD587147A9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Tue, 22 Sep 2020 15:05:16 +0200
In-Reply-To: <MN2PR11MB43668FA513A764EA0514790BB53B0@MN2PR11MB4366.namprd11.prod.outlook.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, Christian Hopps <chopps@chopps.org>, Gabriel Lopez <gabilm@um.es>, "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" <draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "ipsec@ietf.org" <ipsec@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, Martin Björklund <mbj+ietf@4668.se>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <D25A15B0-B714-407C-B119-F83B634099D4@chopps.org> <MN2PR11MB43668FA513A764EA0514790BB53B0@MN2PR11MB4366.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-FEAS-SPF: spf-result=pass, ip=155.54.212.170, helo=xenon43.um.es, mailFrom=rafa@um.es
Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.170 as permitted sender) smtp.mailfrom=rafa@um.es
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=DIFlZ5nqnXOdMGFtzaLEziUWDbhibgsJ1NTkKeIJZOc=; b=2LejQjJ4k9V59P1XV3XPTghaoUNfLxkVVvYH2m/VKyCYrFKrVi2q5k1xqmSFJfckLYyilZ6Et996 FnihOum9Ec5GA3PByDXVrGzrdndDkFVEiYi8aO07Sl0Pb69iy3DYnueyJwy29PkVTUnOZ7MeI+en K3AlJ3lr2QDWxDRWxEVj67dkXmqs7qgc4i4xlqHhdpV78rxSoDJ5uS+MgiSPTrXn12EUQy1wAPqd 41I0476ti9VQfr8dlvv5rGORmnj0/kLyxEh4obzTbWs4NAzHBr7LHMrLlURXaFExO+7vvibFvzMn 1zq6oXCap/gl5hoUs3J6szCLD8X27dFaFuNlwQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/A4p38_46iAQ_c6Jo_bWa0xymWEo>
Subject: Re: [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 13:05:37 -0000

Dear Rob:

Apologies for our delayed answer. We are now working in the revision to submit v09 by compiling all the comments.

As you mentioned, we want to avoid any further delay. As we mentioned to Chris in the past (i2nsf mailing list), we do not have any problem to include some additional text (e.g. “-sdn-" in the module names). Therefore, Rob, we agree with your point of view about this.

In summary, we are working in the next revision v09, and our idea to address Chris’ comments was to include -sdn- to the module names.

We hope this is fine.

Best regards.

> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) <rwilton@cisco.com> escribió:
> 
> Hi draft authors, Chris,
> 
> Can we also please try and close on this issue raised by Chris.
> 
> Chris, I don’t think that there is any great way to solve this issue using YANG features, but presumably the constraint could be enforced with a must statement, or groupings could be used to copy parts of the ipsec structure into an sdn specific ipsec tree structure.
> 
> I understand that there isn't any great desire to delay these drafts by trying to generalize the ipsec YANG model contained within it.  However, I think that means that the modules should have "-sdn-" in their names to indicate that they are intended specifically for the SDN use case, and should not be confused with the more generic ipsec YANG modules that have been proposed.
> 
> Regards,
> Rob
> 
> 
>> -----Original Message-----
>> From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf Of Christian
>> Hopps
>> Sent: 24 August 2020 18:08
>> To: Martin Björklund <mbj+ietf@4668.se>
>> Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow-
>> protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-
>> doctors@ietf.org
>> Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-
>> i2nsf-sdn-ipsec-flow-protection-08
>> 
>> [adding in ipsec@]
>> 
>> Hi,
>> 
>> This draft was discussed in ipsecme at the last IETF, and there was a
>> desire to look closer at a couple changes that would make these models
>> usable by ipsec generally rather than only for SDNs. Otherwise we will end
>> up with 2 models that look very similar and duplicate almost all the
>> functionality. This was going to be done during the next yang doctor
>> review, but it looks like that happened in the meantime (ships in the
>> night).
>> 
>> At minimum the module names should include "-sdn-" if no other changes are
>> made to indicate that they are only for sdn use; however, this is not the
>> optimal solution.
>> 
>> A better solution would be to move the containers currently under ikeless
>> (for SA and Policy databases) under ipsec-common.
>> 
>> The feedback I received from the authors was that the SDN controllers
>> didn't care about the actual SAs and policies when using IKE so they
>> didn't want to require someone implementing ike+common modules to have to
>> support them.
>> 
>> The YANG question I suppose is, is there an easy way to move these
>> containers from ipsec-ikeless to ipsec-common, but still allow for them to
>> be empty and/or unimplemented for the SDN IKE use case? If they were made
>> features, is there a proper YANG way to indicate that if the ikeless
>> module is present then those features must also be supported thus matching
>> the functionality as defined by the current draft?
>> 
>> Thanks,
>> Chris.
>> 
>> 
>> 
>>> On Aug 24, 2020, at 10:37 AM, Martin Björklund via Datatracker
>> <noreply@ietf.org> wrote:
>>> 
>>> Reviewer: Martin Björklund
>>> Review result: Ready with Nits
>>> 
>>> I did an early YANG Doctor's review of this draft.  Most of my
>>> comments then have been addressed in this version.
>>> 
>>> Comments:
>>> 
>>> o  As I wrote in my early review, the RFC editor enforces a common
>>>  format of YANG modules, so it is better to adhere to this format
>>>  before sending the draft to the RFC editor.  Use
>>> 
>>>    pyang -f yang --yang-line-length 69 <FILE>
>>> 
>>>  to get a consistent look-and-feel for your module.
>>> 
>>>  (You will have to manually re-flow description statements after
>>>  this.)
>>> 
>>> 
>>> o  There are some leafs that are optional in the model, but w/o a
>>>  default value and w/o an explanation of what happens if that leaf
>>>  is not set.  You should find those and either make them mandatory,
>>>  add a default value, or explain what it means when it isn't set.
>>>  As an example,
>>>  /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret
>>>  is optional.  I suspect that this leaf needs to be mandatory.
>>>  Another example is the leaf espencap.
>>> 
>>> 
>>> /martin
>>> 
>>> 
>>> _______________________________________________
>>> yang-doctors mailing list
>>> yang-doctors@ietf.org
>>> https://www.ietf.org/mailman/listinfo/yang-doctors
> 

-------------------------------------------------------
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: rafa@um.es
-------------------------------------------------------