Hi Tero, I'm sorry some of the previous messages HTML at some point the message got converted to that format. I actually prefer text as well.
It was not my intention to say anything was too late to change, only that the WG has been discussing an IP-TFS solution for 2 years. This reorganization of the document obfuscates that and turns the document into a generic encapsulation document, with IP-TFS as a after-though. If that's the consensus of the WG then that is what we will do of course. I personally feel this is totally unneeded, it makes things harder to understand for someone actually trying to implement a TFS solution which is the chartered goal. Is this the WG consensus, that we should have a generic new ESP encapsulation document? I have only seen Valery ask for these changes so far. I would like to ask for WG consensus before we switch directions like this. Thanks, Chris. > On Feb 11, 2021, at 2:16 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > Christian Hopps writes: > <something about WGLC beeing to late, but I can't really quote it > properly as it was in HTML format and my client could not parse that > html out for quoting> > > WGLC is not too late to do changes, it is quite early in the process, > we still need to go to the IETF LC, and then through IESG etc. If > making these changes now will make document easier to read, that will > most likely make IETF LC and further steps easier, so it might save > some time and effort from us later. > > And about the charter, as long as we do get the TFS solution out of > that is fine for the charter. We are trying to provide solution to the > problem described in the our charter, the charter usually does not try > to dictate what the final solution will be, just describe the problem > that we need to solve. > > Our charter says: > > The demand for Traffic Flow Confidentiality has been > increasing in the user community, but the current method > defined in RFC4303 (adding null padding to each ESP payload) > is very inefficient in its use of network resources. The > working group will develop an alternative TFC solution that > uses network resources more efficiently. > > An example of this is that when we started working on the post quantum > cryptography, we realized we need this auxiliary exchange to solve the > issue, but then we realized that this could also be used for something > else, and it was renamed to intermediate exchange etc. So while > working for one solution we can also generate more generic protocol > that can be used to perhaps solve other problems in the future, even > better. Of course making the protocol more complicated by making it > more general is not necessarely good idea, thus sometimes it is better > to make more restricted protocol just for simplicitys sake. > > But my understanding is that here we do not need any protocol changes, > just reordering of the document to make it more clear that we have two > layers where the first one can be used for other things too, and that > the second part uses that first layer as it building block. > -- > kivi...@iki.fi >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
