Looks Good. Sriram
On Tue, Jan 12, 2010 at 5:07 PM, Yaron Sheffer <yar...@checkpoint.com> wrote: > Hi, > > Thanks to the IESG feedback, we have had a long and enlightening discussion > on the list. But we have not reached consensus on either of the two > questions. As a result, Paul and I are proposing the following resolution, > which appears to be acceptable both to the draft's editors and to the IESG > members. Unless there are strong objections from multiple WG participants, we > will ask the editors to rev the draft in the next few days according to this > proposal. > > Motivation: retain deterministic traffic visibility for middleboxes with a > smooth migration path, while ensuring that WESP does not change ESP, and is > not (nor seen as) ESPv4. > > - Return ICV to its former ESP-only definition. > - Maintain the Encrypted bit, as per the latest version of the draft. > - Make the padding field have the minimal possible length, possibly 0. > Eliminate the Padding Length field (the first octet). [Essentially roll back > to version -10]. > - WESPv1 will not accept extensions. Any extensions will need a WESPv2, > including some integrity protection for the new data. > - Clarify the text about Version/HdrLen as proposed in the thread related to > Jari's discuss - so even if we add extensions later, and bump the version > number, HdrLen/TrailerLen will be in the same place, and middleboxes can > still find where the actual packet starts/ends > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
