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

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

Reply via email to