> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez <[email protected]> wrote: > > 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.
That does not seem like enough justification for not having the module be usable in such a broader fashion. It is obvious to anyone implementing this for your use case that the notifications must be implemented. If you feel that it is not obvious for some reason a simple sentence can make that clear. Although I would think that sentence might start with the word "Obviously, ..." :) Thanks, Chris. > > Hope this helps. > > Best Regards. > >> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) >> <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> On Behalf Of Lou Berger >> Sent: 27 September 2020 15:26 >> To: Christian Hopps <[email protected] <mailto:[email protected]>>; Martin >> Björklund <[email protected] <mailto:[email protected]>> >> Cc: Robert Wilton <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]>; Gabriel Lopez <[email protected] <mailto:[email protected]>>; >> [email protected] >> <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]>; Rafa Marin-Lopez <[email protected] >> <mailto:[email protected]>>; [email protected] <mailto:[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> >> Christian Hopps <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> >> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/last-call >> <https://www.ietf.org/mailman/listinfo/last-call> >> >> >> >> _______________________________________________ >> IPsec mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec>_______________________________________________ >> I2nsf mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2nsf >> <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: [email protected] <mailto:[email protected]> > ------------------------------------------------------- > > > > > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
