rfc2402bis minor concerns

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

I've just reread the draft-ietf-ipsec-rfc2402bis-04.txt document
and I've some minor concerns:

 - in 2.6  Integrity Check Value (ICV):

   This is a variable-length field that contains the Integrity Check
   Value (ICV) for this packet.  The field must be an integral multiple
   of 32 bits (IPv4) or 64 bits (IPv6) in length.

 => the wording is very misleading: one can interpret it as an ICV length
    of 96 bits is illegal for IPv6 (when this is the currently used length
    for IPv4 and IPv6 AH and 3.3.3.2.1  ICV Padding gives this for example).
    IMHO the constraint is for the whole extension, the ICV has only to
    be on a multiple of 32 bits.

 - 3.1.2 Tunnel Mode: this section doesn't suggest the outer header can
   use IPvX when the inner is IPvY with X != Y. IMHO we have only to confirm
   that IPv6 over IPv4 and IPv4 over IPv6 are legal in tunnel mode.
   I notice this because the lack of "crossed" IP versions in tunnel mode
   comes just after the spuirous check of the outer source address in interop
   issues in common implementations...

 - 3.1.2 Tunnel Mode: the legend:
           * = construction of outer IP hdr/extensions and modification
               of inner IP hdr/extensions is discussed below.

   refers to a discussion which is not convincing:

   In tunnel mode, the outer and inner IP header/extensions can be
   inter-related in a variety of ways.  The construction of the outer IP
   header/extensions during the encapsulation process is described in
   the Security Architecture document.

 => I suggest to use the same legend than in ESP-v3:

            * = if present, construction of outer IP hdr/extensions and
                modification of inner IP hdr/extensions is discussed in
                the Security Architecture document.

 - 3.2  Integrity Algorithms: there is a missing closing parenthesis.

Thanks

Francis.Dupont@enst-bretagne.fr