Internet-Drafts@ietf.org writes:
> 	Title           : Wrapped ESP for Traffic Visibility
> 	Author(s)       : K. Grewal, et al.
> 	Filename        : draft-ietf-ipsecme-traffic-visibility-08.txt
> 	Pages           : 15
> 	Date            : 2009-09-01

Found out one more nit in the WESP draft. It now says:

    Flags, 8 bits: The bits are defined LSB first, so bit 0 would be
    the least significant bit of the flags octet.

and then defines flags from MSB first without specifying bit numbers
and those bit numbers based on the picture are 5-7. This is bit
confusing. So I propose that you add the explicit bit numbers to the
descriptions i.e. add "bits 6-7" to version and "bit 5" to
description.

On the other hand your picture is using MSB order, i.e. bit number 0
is the most significant bit, and flags is bits 24-31, so it would make
sense to define bits inside the flags also in MSB order, i.e. change
the text to:
----------------------------------------------------------------------
   Flags, 8 bits: The bits are defined MSB first, so bit 0 would be 
   the most significant bit of the flags octet. 

       2 bits (bits 0-1): Version (V). MUST be sent as 0 and checked
   by the receiver. If the version is different than an expected
   version number (e.g. negotiated via the control channel), then the
   packet must be dropped by the receiver. Future modifications to the
   WESP header may require a new version number. Intermediate nodes
   dealing with unknown versions are not necessarily able to parse the
   packet correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).

       1 bit (bit 2): Encrypted Payload (E). Setting the Encrypted
   Payload bit to 1 indicates that the WESP (and therefore ESP)
   payload is protected with encryption. If this bit is set to 0, then
   the payload is using ESP-NULL cipher. Setting or clearing this bit
   also impacts the value in the WESP Next Header field, as described
   above. The recipient MUST ensure consistency of this flag with the
   negotiated policy and MUST drop the incoming packet otherwise.

       5 bits (bits 3-7): Flags, reserved for future use. The flags
   MUST be sent as 0, and ignored by the receiver. Future documents
   defining any of these flags MUST NOT affect the distinction between
   encrypted and unencrypted packets. Intermediate nodes dealing with
   unknown flags are not necessarily able to parse the packet
   correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).
----------------------------------------------------------------------

I am actually not sure if we have properly defined bit order for IETF
use. In pictures we use MSB bit first numbering, but in some other
places we have used LSB bit numbering (like RFC4306 uses for its
flags).

If you want to keep LSB bit ordering inside the flags then text would
be:

----------------------------------------------------------------------
   Flags, 8 bits: The bits are defined LSB first, so bit 0 would be 
   the least significant bit of the flags octet. 

       2 bits (bits 6-7): Version (V). MUST be sent as 0 and checked
   by the receiver. If the version is different than an expected
   version number (e.g. negotiated via the control channel), then the
   packet must be dropped by the receiver. Future modifications to the
   WESP header may require a new version number. Intermediate nodes
   dealing with unknown versions are not necessarily able to parse the
   packet correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).

       1 bit (bit 5): Encrypted Payload (E). Setting the Encrypted
   Payload bit to 1 indicates that the WESP (and therefore ESP)
   payload is protected with encryption. If this bit is set to 0, then
   the payload is using ESP-NULL cipher. Setting or clearing this bit
   also impacts the value in the WESP Next Header field, as described
   above. The recipient MUST ensure consistency of this flag with the
   negotiated policy and MUST drop the incoming packet otherwise.

       5 bits (bits 0-4): Flags, reserved for future use. The flags
   MUST be sent as 0, and ignored by the receiver. Future documents
   defining any of these flags MUST NOT affect the distinction between
   encrypted and unencrypted packets. Intermediate nodes dealing with
   unknown flags are not necessarily able to parse the packet
   correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).
-- 
kivinen@iki.fi