> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez <r...@um.es> 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) >> <rwilton=40cisco....@dmarc.ietf.org >> <mailto:rwilton=40cisco....@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-boun...@ietf.org >> <mailto:yang-doctors-boun...@ietf.org>> On Behalf Of Lou Berger >> Sent: 27 September 2020 15:26 >> To: Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>>; Martin >> Björklund <mbj+i...@4668.se <mailto:mbj+i...@4668.se>> >> Cc: Robert Wilton <rwilton=40cisco....@dmarc.ietf.org >> <mailto:rwilton=40cisco....@dmarc.ietf.org>>; i2...@ietf.org >> <mailto:i2...@ietf.org>; Gabriel Lopez <gab...@um.es <mailto:gab...@um.es>>; >> draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org >> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org>; >> ipsec@ietf.org <mailto:ipsec@ietf.org>; last-c...@ietf.org >> <mailto:last-c...@ietf.org>; Rafa Marin-Lopez <r...@um.es >> <mailto:r...@um.es>>; yang-doct...@ietf.org <mailto:yang-doct...@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+i...@4668.se >> <mailto:mbj+i...@4668.se>> wrote: >> >> Hi, >> >> Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>> wrote: >> >> >> >> >> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <r...@um.es >> <mailto:r...@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-c...@ietf.org <mailto:last-c...@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 >> i2...@ietf.org <mailto:i2...@ietf.org> >> 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: r...@um.es <mailto:r...@um.es> > ------------------------------------------------------- > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
