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

From: Gabriel Lopez <[email-masked]>
Date: Thu, 17 Sep 2020 16:45:43 +0200

Hi Martin.

Thank you for the review and sorry for the late response.

> El 24 ago 2020, a las 16:37, Martin Björklund via Datatracker <[email-masked]> escribió:
> 
> 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>

mmm, we already applied the pyang command as you suggest, anyway, we will apply it again for the next version.

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

You are right. We are reviewing the text.

Best regards, Gabi.
> /martin

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 22 Sep 2020 11:56:32 +0000

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 <[email-masked]> On Behalf Of Christian
> Hopps
> Sent: 24 August 2020 18:08
> To: Martin Björklund <[email-masked]>
> Cc: [email-masked]; draft-ietf-i2nsf-sdn-ipsec-flow-
> [email-masked]; [email-masked]; [email-masked]; yang-
> [email-masked]
> 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
> <[email-masked]> wrote:
> >
> > _______________________________________________
> > yang-doctors mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 22 Sep 2020 15:05:16 +0200

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) <[email-masked]> escribió:
> 
> Hi draft authors, Chris,
> 

-------------------------------------------------------
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: [email-masked]
-------------------------------------------------------

---

From: Christian Hopps <[email-masked]>
Date: Tue, 22 Sep 2020 09:27:15 -0400

> On Sep 22, 2020, at 8:19 AM, Martin Björklund <[email-masked]> wrote:
> 
> Hi,
> 
> Sorry I missed this question.
> 
> I think it probably can be solved; but see below.
> 
> 
> "Rob Wilton (rwilton)" <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi draft authors, 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
>> 
>> 
> 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).

It will still contain the notification, which is used for managing ikeless ipsec in the SDN controller case.

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

Yes, b/c IPsec always has an SA database (both ike or ikeless). The reason, according to the authors, it was not put in common and was only included in ikeless was b/c the authors felt that for SDNs the SDN controller didn't care about the SA database since IKE was managing it. That doesn't mean it doesn't exist, just that their use case didn't care, and didn't want to force people to implement the YANG for it if they only supported the IKE module for SDN use.

I don't see why the want to not implement the SA database YANG for SDN+IKE couldn't be handled with a feature (or some other YANG mechanism) instead and then have a more correct model organization

The problem is that this common ipsec module (and the ikeless and ike even) are easily augmented and usable by IPsec in general if the SA and policy database were moved to common and out of ikeless. The only other way to re-use it would be to augment a duplicate SA database under the IKE module, but there is only a single SA database on a server, so now we have 2 SA databases in YANG (under ikeless and ike namespaces) to represent the same SA database. It seems wrong to go this route since the change I was suggesting seems pretty trivial.

In my case we have an ipsec extension in development along with a YANG module (https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00) that want's to augment the SA database (for operational state like packet counters among other things), but of course we want this to be for IKE and IKE-less -- in particular IKE is the vastly common use case for IPsec.

Thanks,
Chris.

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

---

From: Martin Björklund <[email-masked]>
Date: Tue, 22 Sep 2020 14:19:53 +0200 (CEST)

Hi,

/martin

---

From: Martin Björklund <[email-masked]>
Date: Tue, 22 Sep 2020 15:47:55 +0200 (CEST)

Christian Hopps <[email-masked]> wrote:
> It will still contain the notification, which is used for managing
> ikeless ipsec in the SDN controller case.

Ok.

> Yes, b/c IPsec always has an SA database (both ike or ikeless). The
> reason, according to the authors, it was not put in common and was
> only included in ikeless was b/c the authors felt that for SDNs the
> SDN controller didn't care about the SA database since IKE was
> managing it. That doesn't mean it doesn't exist, just that their use
> case didn't care, and didn't want to force people to implement the
> YANG for it if they only supported the IKE module for SDN use.

Then I agree w/ you that moving them to common and adding a feature
would work.  If they don't want to implement them just don't implement
the feature.

/martin

> I don't see why the want to not implement the SA database YANG for
> SDN+IKE couldn't be handled with a feature (or some other YANG
> mechanism) instead and then have a more correct model organization
> 
> The problem is that this common ipsec module (and the ikeless and ike
> even) are easily augmented and usable by IPsec in general if the SA
> and policy database were moved to common and out of ikeless. The only
> other way to re-use it would be to augment a duplicate SA database
> under the IKE module, but there is only a single SA database on a
> server, so now we have 2 SA databases in YANG (under ikeless and ike
> namespaces) to represent the same SA database. It seems wrong to go
> this route since the change I was suggesting seems pretty trivial.
> 
> In my case we have an ipsec extension in development along with a YANG
> module (https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00)
> that want's to augment the SA database (for operational state like
> packet counters among other things), but of course we want this to be
> for IKE and IKE-less -- in particular IKE is the vastly common use
> case for IPsec.
> 
> Thanks,
> Chris.
> 
> >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 22 Sep 2020 15:38:45 +0000

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?

Thanks,
Rob

From: Rafa Marin-Lopez <[email-masked]>
Sent: 22 September 2020 14:05
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Rafa Marin-Lopez <[email-masked]>; Christian Hopps <[email-masked]>; Gabriel Lopez <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Martin Björklund <[email-masked]>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Dear Rob:

We hope this is fine.

Best regards.

El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> escribió:

Hi draft authors, Chris,

Regards,
Rob

-----Original Message-----
From: yang-doctors <[email-masked]<mailto:[email-masked]>> On Behalf Of Christian
Hopps
Sent: 24 August 2020 18:08
To: Martin Björklund <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-i2nsf-sdn-ipsec-flow-
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; yang-
[email-masked]<mailto:[email-masked]>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-
i2nsf-sdn-ipsec-flow-protection-08

[adding in ipsec@]

Hi,

Thanks,
Chris.

On Aug 24, 2020, at 10:37 AM, Martin Björklund via Datatracker
<[email-masked]<mailto:[email-masked]>> wrote:

Comments:

/martin

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>
-------------------------------------------------------

---

From: tom petch <[email-masked]>
Date: Tue, 22 Sep 2020 17:22:18 +0100

On 22/09/2020 16:38, Rob Wilton (rwilton) wrote:
> 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 <[email-masked]> Sent: 22 September 2020 14:05 To:
> Rob Wilton (rwilton) <[email-masked]> Cc: Rafa Marin-Lopez
> <[email-masked]>; Christian Hopps <[email-masked]>; Gabriel Lopez
> <[email-masked]>;
> [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Martin Björklund <[email-masked]> 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)
> <[email-masked]<mailto:[email-masked]>> escribió:
>
> Hi draft authors, Chris,
>
> with a must statement, or groupings could be used to copy parts of
> the ipsec structure into an sdn specific ipsec tree structure.
>
> Regards, Rob
> -----Original Message----- From: yang-doctors
> <[email-masked]<mailto:[email-masked]>>
> On Behalf Of Christian Hopps Sent: 24 August 2020 18:08 To: Martin
> Björklund <[email-masked]<mailto:[email-masked]>> Cc:
> [email-masked]<mailto:[email-masked]>;
> draft-ietf-i2nsf-sdn-ipsec-flow-
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; yang-
> [email-masked]<mailto:[email-masked]> Subject: Re: [yang-doctors]
> Yangdoctors last call review of draft-ietf-
> 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.
>
> 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.
>
>
>
>
> Reviewer: Martin Björklund Review result: Ready with Nits
>
> 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 [email-masked]<mailto:[email-masked]>
> ------------------------------------------------------- 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:
> [email-masked]<mailto:[email-masked]>
ob

As you

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 23 Sep 2020 11:29:06 +0200

Hi Rob, (Chris):

Thank you very much for your answers. Please see our comments inline. 

> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) <rwilton=[email-masked]> escribió:
> 
> Hi Rafa,
>  

Correct, especially at this point of time. We have been discussing this I-D for a long time. There was a consensus in the WG. I2NSF WG chairs can comment about this. In our opinion, the changes that need to be applied are major changes from what it was approved in the WG. However, this is coming in the “last minute” and we feel this is not merely moving a few lines from here to there. We need to understand the impact of this. Therefore, it is not so trivial as it may seem. See below. 

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

In the context of our I-D, if we move SAD structure to ipsec-common, what we are meaning is that IPsec SA configuration data (setting values to the SAD structure) are common to the IKE case and the IKE-less cases, which are not. It is confusing. Moreover, the usage of feature means that, after all, this “common” is not “common” to both cases IKE case and IKE-less. Again, it seems confusing. In the IKE case, the SDN/I2NSF controller does not configure the SAD at all but the IKE implementation in the NSF. In our opinion, in order to properly add this IPsec SA operational state to the IKE case we should include operational data about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, we have certain operational data (ro) in the SAD structure in the IKE-less case. If only those are moved to the common part should be ok but we think it does not solve the problem. 

Therefore it is not only an implementation aspect.

As you may observe, our discussion is taking into account there is an I2NSF Controller and we have two cases IKE case and IKE-less case, that have been discussed in the WG. The YANG model in the I-D has tried to reflect this discussion. It was never the intention to provide a general YANG model for IPsec. 

Best Regards.

> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]>> escribió:
>  
> Hi draft authors, Chris,
> 
> From: yang-doctors <[email-masked] <mailto:[email-masked]>> On Behalf Of Christian
> Hopps
> To: Martin Björklund <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; draft-ietf-i2nsf-sdn-ipsec-flow-
> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; yang-
> [email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
>  
>  
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>
> I2nsf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 23 Sep 2020 10:24:18 +0000

Hi Rafa,

Thanks for replying with the extra background information.

It seems like renaming the modules, as you propose for the -09 version, is the pragmatic path forward here.

Regards,
Rob

From: Rafa Marin-Lopez <[email-masked]>
Sent: 23 September 2020 10:29
To: Rob Wilton (rwilton) <[email-masked]>; Christian Hopps <[email-masked]>
Cc: Rafa Marin-Lopez <[email-masked]>; [email-masked]; Gabriel Lopez <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Martin Björklund <[email-masked]>; [email-masked]
Subject: Re: [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Hi Rob, (Chris):

El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>> escribió:

Hi Rafa,

Best Regards.

Thanks,
Rob

From: Rafa Marin-Lopez <[email-masked]<mailto:[email-masked]>>
Sent: 22 September 2020 14:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: Rafa Marin-Lopez <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Gabriel Lopez <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Martin Björklund <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Dear Rob:

We hope this is fine.

Best regards.

Hi draft authors, Chris,

Regards,
Rob

-----Original Message-----

[adding in ipsec@]

Hi,

Thanks,
Chris.

Comments:

/martin

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: tom petch <[email-masked]>
Date: Wed, 23 Sep 2020 11:45:43 +0100

> It seems like renaming the modules, as you propose for the -09 version, is the pragmatic path forward here.

And the namespace and the YANG prefix IMHO.  Having ike as a prrefix for 
a module which is not the 'ike' module I see as a source of confusion. 
If this is nsf specific, then I would suggest nsfike although nsfikeless 
then seems a bit long.

Tom Petch

---

From: Christian Hopps <[email-masked]>
Date: Wed, 23 Sep 2020 06:56:09 -0400

> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[email-masked]> wrote:
> 
>> 
>> 
> In the context of our I-D, if we move SAD structure to ipsec-common, what we are meaning is that IPsec SA configuration data (setting values to the SAD structure) are common to the IKE case and the IKE-less cases, which are not. It is confusing.

Something defined in a common module but marked as a feature does not imply that that feature has to be implemented by an importing module. This is not confusing to YANG implementers or users I think. If we are just talking about document flow here, then a sentence saying "the SAD feature is not required to implement IKE functionality" is quite enough to clear that up I think.

Thanks,
Chris.

> Moreover, the usage of feature means that, after all, this “common” is not “common” to both cases IKE case and IKE-less. Again, it seems confusing. In the IKE case, the SDN/I2NSF controller does not configure the SAD at all but the IKE implementation in the NSF. In our opinion, in order to properly add this IPsec SA operational state to the IKE case we should include operational data about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, we have certain operational data (ro) in the SAD structure in the IKE-less case. If only those are moved to the common part should be ok but we think it does not solve the problem.
>

---

From: Martin Björklund <[email-masked]>
Date: Wed, 23 Sep 2020 12:58:26 +0200 (CEST)

Hi,

Christian Hopps <[email-masked]> wrote:
> >> 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?
> > 
> > 
> > In the context of our I-D, if we move SAD structure to ipsec-common,
> > what we are meaning is that IPsec SA configuration data (setting
> > values to the SAD structure) are common to the IKE case and the
> > IKE-less cases, which are not. It is confusing.
> 
> Something defined in a common module but marked as a feature does not
> imply that that feature has to be implemented by an importing
> module. This is not confusing to YANG implementers or users I
> think. If we are just talking about document flow here, then a
> sentence saying "the SAD feature is not required to implement IKE
> functionality" is quite enough to clear that up I think.

Another alternative could be to move these containers to another
(new) module.

/martin

> 
> Thanks,
> Chris.
> 
> > Moreover, the usage of feature means that, after all, this “common” is
> > not “common” to both cases IKE case and IKE-less. Again, it seems
> > confusing. In the IKE case, the SDN/I2NSF controller does not
> > configure the SAD at all but the IKE implementation in the NSF. In our
> > opinion, in order to properly add this IPsec SA operational state to
> > the IKE case we should include operational data about the IPsec SAs
> > (config false) to the ietf-ipsec-ike. Alternatively, we have certain
> > operational data (ro) in the SAD structure in the IKE-less case. If
> > only those are moved to the common part should be ok but we think it
> > does not solve the problem.
> > 
>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 23 Sep 2020 07:20:26 -0400

> On Sep 23, 2020, at 6:58 AM, Martin Björklund <[email-masked]> wrote:
> 
> Hi,
> 
> Christian Hopps <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 

It may also be enough to mark the notifications in the ikeless module as a feature I suppose. That is the actual thing I think non-SDN implementations would want to omit. The module name "ikeless" is not great in this case, but perhaps workable.

This is a sub-optimal compromise b/c all IPsec have SA databases even ones running IKE -- i.e., SA databases are common whether exposed in YANG or not -- but if it can move it forward perhaps good enough.

I'm definitely concerned about IETF process and real world usability here. These modules are basically workable for ipsec I think, they could be used by operators today. If we restart the entire process to redo this work for the more generic IPsec case it will probably be years before they are finished and in the field. This new work can be started, but why not have something usable in the meantime?

Thanks,
Chris.

> --
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Lou Berger <[email-masked]>
Date: Sun, 27 Sep 2020 10:26:11 -0400

> This is a sub-optimal compromise b/c all IPsec have SA databases even 
> ones running IKE -- i.e., SA databases are common whether exposed in 
> YANG or not -- but if it can move it forward perhaps good enough.
>
Speaking as an interested party, I hope that some compromise / good 
enough solution is followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps wrote:
>
>
>> On Sep 23, 2020, at 6:58 AM, Martin Björklund <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>>
>>>>>
> It may also be enough to mark the notifications in the ikeless module 
> as a feature I suppose. That is the actual thing I think non-SDN 
> implementations would want to omit. The module name "ikeless" is not 
> great in this case, but perhaps workable.
>
> This is a sub-optimal compromise b/c all IPsec have SA databases even 
> ones running IKE -- i.e., SA databases are common whether exposed in 
> YANG or not -- but if it can move it forward perhaps good enough.
>
> I'm definitely concerned about IETF process and real world usability 
> here. These modules are basically workable for ipsec I think, they 
> could be used by operators today. If we restart the entire process to 
> redo this work for the more generic IPsec case it will probably be 
> years before they are finished and in the field. This new work can be 
> started, but why not have something usable in the meantime?
>
> Thanks,
> Chris.
>
>>
>>
>> /martin
>>
>>
>>
>>>
>>> Thanks,
>>> Chris.
>>>
>> https://www.ietf.org/mailman/listinfo/last-call
>
>
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Mon, 28 Sep 2020 11:01:28 +0200

Hi Rob, Tom:

Renaming the modules sounds reasonable. With regard to have a different prefix, it is also ok. Perhaps the easiest way is to solve this is the following: instead of using -sdn- we could include -i2nsf- so we would have: ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This would mean that this is in the context of i2nsf wg.

What do you think?

> El 23 sept 2020, a las 12:45, tom petch <[email-masked] <mailto:[email-masked]>> escribió:
> 
> And the namespace and the YANG prefix IMHO.  Having ike as a prrefix for a module which is not the 'ike' module I see as a source of confusion. If this is nsf specific, then I would suggest nsfike although nsfikeless then seems a bit long.
> 
> Tom Petch
> 
>> Regards,
>> Rob
>> 
>> 
>> From: Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>>
>> To: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]>>; Christian Hopps <[email-masked] <mailto:[email-masked]>>
>> Cc: Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Gabriel Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Martin Björklund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) <rwilton=[email-masked] <mailto:rwilton=[email-masked]><mailto:rwilton=[email-masked] <mailto:rwilton=[email-masked]>>> escribió:
>> 
>> Hi Rafa,
>> 
>> From: Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> To: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> Cc: Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Christian Hopps <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Gabriel Lopez <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; Martin Björklund <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> escribió:
>> 
>> Hi draft authors, Chris,
>> 
>> From: yang-doctors <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> On Behalf Of Christian
>> Hopps
>> To: Martin Björklund <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> Cc: [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; draft-ietf-i2nsf-sdn-ipsec-flow-
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; yang-
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>

---

From: tom petch <[email-masked]>
Date: Mon, 28 Sep 2020 10:33:42 +0100

> Renaming the modules sounds reasonable. With regard to have a different prefix, it is also ok. Perhaps the easiest way is to solve this is the following: instead of using -sdn- we could include -i2…

Ok with -ike and -ikeless but I would not use ietf-i2nsf-common the 
reason being that there is an awful lot in common across the different 
i2nsf I-D that with hindsight would have made an excellent common i2nsf 
module and may be will in future if these modules get revised.
Other WG have created 'common' or 'types' modules, with more of the 
latter and then abbreviated that to 't' or 'c' so perhaps 
ietf-i2nsf-iket, or -ikec.
Prefix ahould be short so something like nsfike, nsfikeless (longer than 
I would like - nsfiken?) and nsfiket, or nsfikec.

Tom Petch

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 29 Sep 2020 18:14:41 +0200

Hi Tom:

Please see our comments inline:

> El 28 sept 2020, a las 11:33, tom petch <[email-masked]> escribió:
> 
> Ok with -ike and -ikeless

Great.

> but I would not use ietf-i2nsf-common the reason being that there is an awful lot in common across the different i2nsf I-D that with hindsight would have made an excellent common i2nsf module and may be will in future if these modules get revised.

We agree.
> Other WG have created 'common' or 'types' modules, with more of the latter and then abbreviated that to 't' or 'c' so perhaps ietf-i2nsf-iket, or -ikec.

Ok about ietf-i2nsf-ikec.

> Prefix ahould be short so something like nsfike, nsfikeless (longer than I would like - nsfiken?) and nsfiket, or nsfikec.

For the prefix to the common module 

prefix "nsfikec";

For the prefix to the ietf-i2nsf-ike, nsfike seems to refer to IKE case , which is good.

prefix "nsfike”; 

For the prefix to the ietf-i2nsf-ikeless, nsfikeless (a shorter one could be nsfikels but we do not know if that is acceptable) has a clear meaning and it is coherent with the rest of the names. I think we can live with a few letters more.  

Is this acceptable?

Best Regards.

---

From: tom petch <[email-masked]>
Date: Wed, 30 Sep 2020 17:31:09 +0100

> For the prefix to the ietf-i2nsf-ikeless, nsfikeless (a shorter one could be nsfikels but we do not know if that is acceptable) has a clear meaning and it is coherent with the rest of the names. I…

Yes, although I think that a shorter prefix for ikeless might be better. 
  YANG Guidelines does not give a figure but I mentally think going over 
six can be problematic.  There aren't any instances in the module at 
present but it is when you need to refer to an object (e.g. in a 
constraint, notification, augment) and the absolute form of reference is 
needed or recommended and the object is several layers down.  I see six 
layers in ikeless so a ten character prefix would add 60 characters of 
red tape, a six character on 36 characters.  Currently you do not have 
such references.  (I have been looking at CCAMP lately and they go 17 
layers down - fortunately the prefix are mostly two or three character 
but even so, it does make the YANG harder to follow for me; the path for 
a YANG augment or a when can spread over seven lines).

Tom Petch