Re: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
Martin Björklund <mbj+ietf@4668.se> Tue, 22 September 2020 12:19 UTC
Return-Path: <mbj+ietf@4668.se>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D974E3A1663; Tue, 22 Sep 2020 05:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.121
X-Spam-Level:
X-Spam-Status: No, score=-0.121 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, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=JxvOWSM7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EsDquv+d
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 u8e2BGpdZQ4v; Tue, 22 Sep 2020 05:19:58 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D78F3A1662; Tue, 22 Sep 2020 05:19:58 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CFE37893; Tue, 22 Sep 2020 08:19:56 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 22 Sep 2020 08:19:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= 2pBjClI7ilvUkThLZNF0QMNToS2Tdht0FWuqgGbZXRM=; b=JxvOWSM717HSEe28 TA84s4NlEM2D34ww4m8q89sa0TvXeHAtq3Zpjrnwgepwl1wl6D1oHy6dbWkAGiQ7 UdpJbRO0GvgQ7EkAGn924X/rtp+jdgE9k66PIkrP9gD8OEorgavlKlYobSrDGEzg nCj1QFEgx+J+5cwylG4asqOE4dQxmjQ6lPEWBw/Vh8nzZU6o8MGVIlj73x/f5S6O piY/KI29FYQVWKOhwnAa4WZWo+GTkZZ/JXoH03uQbBJN8itk1nWEDYjwGTwPVEoC Q8LIdaXSwLH8hM3xleqa53jdjbp599yoeV6+U7Swe+8PO1S+3IydH++gurbMAvAK w6XWsg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=2pBjClI7ilvUkThLZNF0QMNToS2Tdht0FWuqgGbZX RM=; b=EsDquv+dOkOwvfXSZMkHcObZay53tT3wopothEUiF0fPqKxhT5c0rRG/J mhc1l22kUN2bQUlReujiaaCckhIoko3tw2K4TEXR2oemNEMEOuGNwH9t9gsZLpcR gEf9FaUenL5GghC3dWg/629GKvz12OM3X1iQrZI/FU03XPuCx0wIdNA5lQDYcByn sC0KBh1Fw7PoIZ8PGi6AJuXeHyOCS3YwxaVcwyYpb4m42x9lST2tStwOLhL9kMLl u2BcYeiYy+kaJpdv//UI5mmvLxyB50sOENVdeHvNIeNfCN8HMSvPrKYraWJMihrP QWE14s5Y0SoE/ScjcRslMU4J9/mYg==
X-ME-Sender: <xms:6-tpX4uINhMAeWbz5Axt1pliRQPUgt056qDI14PvPChKZs_Fkwc4-A> <xme:6-tpX1ch_97PlvZ2qTJlcbHgNsAQZGMtRHn4Fa4RB4qwgrJPVAr--D0B5CJmcuSk0 aCAejjztTrsK2V3Ah8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeggdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeduheekrddujeegrdegrdeggeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:6-tpXzy0KVBfcimkbMnLvYM0mbZ6TKjjTgoK9PykP8gxo-CgamqQAw> <xmx:6-tpX7MR4w15FKDdEqz0Js6VGhnkr0PJSqSbihQKjDnrB1CJATjZRw> <xmx:6-tpX48f3bKhQViRz3jIOQD1PJZGNnLzVlqdMLU3Z2WSvahg-uO3Cw> <xmx:7OtpX4wmU_hKvZDWcF1m6iNBd8wku6PoTIVOrfpuRmevABFP4Fd1bA>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id BA9D6306467E; Tue, 22 Sep 2020 08:19:54 -0400 (EDT)
Date: Tue, 22 Sep 2020 14:19:53 +0200
Message-Id: <20200922.141953.1142814413326145014.id@4668.se>
To: rwilton@cisco.com
Cc: chopps@chopps.org, gabilm@um.es, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, i2nsf@ietf.org, ipsec@ietf.org, last-call@ietf.org, yang-doctors@ietf.org, mbj+ietf@4668.se
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <MN2PR11MB43668FA513A764EA0514790BB53B0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <D25A15B0-B714-407C-B119-F83B634099D4@chopps.org> <MN2PR11MB43668FA513A764EA0514790BB53B0@MN2PR11MB4366.namprd11.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/9bwsrA9V9d8Kf2E4ZQjmdjXdD4E>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 12:20:00 -0000
Hi, Sorry I missed this question. I think it probably can be solved; but see below. "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote: > 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. Are we talking about /ipsec-ikeless/spd and /ipsec-ikeless/sad? If these are moved to another module, ipsec-ikeless becomes empty (if also the related notifs are moved). Why do you want to move them? It is b/c they are under "ipsec-ikeless"? If so, perhaps a simpler solution is to use another (more generic) name for the module and top-level container. If they are moved to ietf-ipsec-common, an implementation that implements ietf-ipsec-ike can still import ietf-ipsec-common, but choose to not implement it (it will show up as an 'import-only-module' in yang library). /martin > > 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 >
- [yang-doctors] Yangdoctors last call review of dr… Martin Björklund via Datatracker
- Re: [yang-doctors] Yangdoctors last call review o… Christian Hopps
- Re: [yang-doctors] Yangdoctors last call review o… Gabriel Lopez
- Re: [yang-doctors] Yangdoctors last call review o… Rob Wilton (rwilton)
- Re: [yang-doctors] Yangdoctors last call review o… Martin Björklund
- Re: [yang-doctors] Yangdoctors last call review o… Rafa Marin-Lopez
- Re: [yang-doctors] Yangdoctors last call review o… Christian Hopps
- Re: [yang-doctors] Yangdoctors last call review o… Martin Björklund
- Re: [yang-doctors] Yangdoctors last call review o… Rob Wilton (rwilton)
- Re: [yang-doctors] [Last-Call] Yangdoctors last c… tom petch
- Re: [yang-doctors] [I2nsf] Yangdoctors last call … Rafa Marin-Lopez
- Re: [yang-doctors] [I2nsf] Yangdoctors last call … Rob Wilton (rwilton)
- Re: [yang-doctors] [Last-Call] [I2nsf] Yangdoctor… tom petch
- Re: [yang-doctors] [I2nsf] Yangdoctors last call … Christian Hopps
- Re: [yang-doctors] [I2nsf] Yangdoctors last call … Martin Björklund
- Re: [yang-doctors] [Last-Call] [I2nsf] Yangdoctor… Christian Hopps
- Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Ya… Lou Berger
- Re: [yang-doctors] [Last-Call] [I2nsf] Yangdoctor… Rafa Marin-Lopez
- Re: [yang-doctors] [Last-Call] [I2nsf] Yangdoctor… tom petch
- Re: [yang-doctors] [Last-Call] [I2nsf] Yangdoctor… Rafa Marin-Lopez
- Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Ya… Rob Wilton (rwilton)
- Re: [yang-doctors] [I2nsf] [IPsec] [Last-Call] Ya… Rafa Marin-Lopez
- Re: [yang-doctors] [IPsec] [I2nsf] [Last-Call] Ya… Christian Hopps
- Re: [yang-doctors] [I2nsf] [IPsec] [Last-Call] Ya… Rafa Marin-Lopez
- Re: [yang-doctors] [IPsec] [I2nsf] [Last-Call] Ya… Christian Hopps
- Re: [yang-doctors] [IPsec] [I2nsf] [Last-Call] Ya… Rafa Marin-Lopez
- Re: [yang-doctors] [IPsec] [I2nsf] [Last-Call] Ya… Christian Hopps