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
> 

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to