Hi Tero, Just to clarify, are you indicating Valery's changes should be made? If so then I will update the document so we can continue to make progress.
Thanks, Chris. > On Feb 11, 2021, at 5:52 PM, Christian Hopps <cho...@chopps.org> wrote: > > Signed PGP part > 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
