On Nov 8, 2012, at 4:24 PM, David McGrew (mcgrew) wrote: > > > On 11/8/12 3:26 AM, "Johannes Merkle" <[email protected]> wrote: > >> 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. > > What's the scenario here? If hash + URL is sent, the certificate still > has to be retrieved. It might not be part of the IKE exchange, but moving > it to HTTP doesn't mean that it doesn't contribute to bytes on the wire > (or over the air, in the case of wireless). >
Since we tend to meet the same people all the time (or communicate with the same parties), usually the hash+URL would lead to retrieving the certificate from a cache, rather than from a remote web server. Of course, if my implementation is running on a "thing", it doesn't have a cache and this argument doesn't apply. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
