On 22/09/2020 16:38, Rob Wilton (rwilton) wrote:
Hi Rafa,
Thanks for getting back to me.
Yes, changing the name of the module is an okay, if not ideal,
resolution. But I appreciate that you also want to be done with this
work.
But I would like to check: My understanding is that the changes that
Chris is proposing are pretty small. I.e. move the SA structure
under ipsec-common, and put it under a YANG feature. Are you sure
that it is impractical to accommodate this change which would allow a
single ipsec module to be shared and extended via YANG
augmentations?
Rob
As you say, the changes look feasible and IMHO will pay for themselves
long term.
But another point to consider is the prefix or prefixes. Note that the
current I-D has ike and ikeless which could cause much confusion
depending on what this I-D ends up containing.
There are a number of related i2nsf modules and a number of different
unrelated prefix. I have encouraged authors to use nsf... for prefix
and would encourage that even more strongly if the only change here is
to the module name. As you know, imports of an IETF module by an IETF
module have to use the prefix defined in the module.
Tom Petch
Thanks, Rob
From: Rafa Marin-Lopez <rafa@xxxxx> Sent: 22 September 2020 14:05 To:
Rob Wilton (rwilton) <rwilton@xxxxxxxxx> Cc: Rafa Marin-Lopez
<rafa@xxxxx>; Christian Hopps <chopps@xxxxxxxxxx>; Gabriel Lopez
<gabilm@xxxxx>;
draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@xxxxxxxx;
i2nsf@xxxxxxxx; ipsec@xxxxxxxx; last-call@xxxxxxxx;
yang-doctors@xxxxxxxx; Martin Björklund <mbj+ietf@xxxxxxx> Subject:
Re: [yang-doctors] Yangdoctors last call review of
draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
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@xxxxxxxxx<mailto:rwilton@xxxxxxxxx>> 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@xxxxxxxx<mailto:yang-doctors-bounces@xxxxxxxx>>
On Behalf Of Christian Hopps Sent: 24 August 2020 18:08 To: Martin
Björklund <mbj+ietf@xxxxxxx<mailto:mbj+ietf@xxxxxxx>> Cc:
i2nsf@xxxxxxxx<mailto:i2nsf@xxxxxxxx>;
draft-ietf-i2nsf-sdn-ipsec-flow-
protection.all@xxxxxxxx<mailto:protection.all@xxxxxxxx>;
ipsec@xxxxxxxx<mailto:ipsec@xxxxxxxx>;
last-call@xxxxxxxx<mailto:last-call@xxxxxxxx>; yang-
doctors@xxxxxxxx<mailto:doctors@xxxxxxxx> 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@xxxxxxxx<mailto:noreply@xxxxxxxx>> 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@xxxxxxxx<mailto:yang-doctors@xxxxxxxx>
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@xxxxx<mailto:rafa@xxxxx>
-------------------------------------------------------
ob
As you
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
