Hi Tero, > Every single option adds complexity, so I do not think we should add > more optional things.
Point compression is not the focus of our draft. Given the opposition it is facing here, I suggest to wait for further replies and if point compression turns out to be objected by the majority on this list, I will not insist on this feature. BTW: In an earlier thread Dan Haskins has already indicated his preference to leave point compression out. > > Not sending the CERT, but replacing it with hash and url offers much > bigger savings, and people are not even doing that. You can not be sure that this option isn't used is some constrained environments. Just a note: the relative saving of point compression is larger when sending hash + URL instead of the CERT. > > Note, that negotiating the use of point compression without retry or > not would waste more bytes then the point compression saves... The KE > payload is in the first packet, which means that to be able to > negotiate it beforehand would require one extra roundtrip. The IKEv2 > headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes > which is already quite big EC key Y part... What I had in mind are constraint environments where using bandwidth saving techniques like point compression can be assumed to be the default. > If I remember right the reason IKEv2 does not use point compression > for the current groups was that there was some IPR. Is that issue > already been cleared? The the patent expires in 2014. http://cr.yp.to/patents/us/6141420.html -- Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
