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

Christian Hopps <chopps@chopps.org> Mon, 24 August 2020 17:08 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A60B3A13F8; Mon, 24 Aug 2020 10:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QmzkFz5MQPaj; Mon, 24 Aug 2020 10:08:49 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB63A1400; Mon, 24 Aug 2020 10:08:07 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7D6EF60981; Mon, 24 Aug 2020 17:08:06 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <D25A15B0-B714-407C-B119-F83B634099D4@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_26AC4FAA-56C3-4C0D-AE98-B9A12CFF49FC"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 24 Aug 2020 13:08:05 -0400
In-Reply-To: <159827985531.30993.17722282912726281276@ietfa.amsl.com>
Cc: Christian Hopps <chopps@chopps.org>, yang-doctors@ietf.org, i2nsf@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, ipsec@ietf.org
To: Martin Björklund <mbj+ietf@4668.se>
References: <159827985531.30993.17722282912726281276@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/VWkDG0riqn4rAr0_OURdIjCA7JI>
Subject: Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2020 17:08:58 -0000

[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