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

Hi Rob:

My apologies but I have just seen this e-mail. We were working on posting last v09 precisely today, assuming this was all clarified and the decision was to change the names as Tom suggested.

Regarding your comment, having "the notifications in the ikeless module as a feature" would not help. Let me explain. The ikeless module needs something inherent to operate, which are the notifications. It is not something optional for the ikeless module to implement.

Hope this helps.

Best Regards.

> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org> escribió:
> 
> Hi Rafa, authors,
>  
> Just to check.
>  
> Has there been any closure on the suggestion from Chris on “notifications in the ikeless module as a feature"?  This would seem to be a fairly cheap & easy compromise.
>  
> Thanks,
> Rob
>  
>  
> From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf Of Lou Berger
> Sent: 27 September 2020 15:26
> To: Christian Hopps <chopps@chopps.org>; Martin Björklund <mbj+ietf@4668.se>
> Cc: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>; i2nsf@ietf.org; Gabriel Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; Rafa Marin-Lopez <rafa@um.es>; yang-doctors@ietf.org
> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
>  
> 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 <mbj+ietf@4668.se <mailto:mbj+ietf@4668.se>> wrote:
>  
> Hi,
> 
> Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org>> wrote:
> 
> 
> 
> 
> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es <mailto:rafa@um.es>> wrote:
> 
> 
> 
> 
> 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?
> 
> 
> 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.
>  
> 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.
> 
> 
> 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.
> 
>  
> -- 
> last-call mailing list
> last-call@ietf.org <mailto:last-call@ietf.org>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>
> 
> 
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org <mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>_______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

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