some comments on draft-ietf-ipsec-arch-sec-04.txt

[Bill Sommerfeld <[e-mail]>]

All of these comments are relatively minor and (I think) in the class
of editorial changes....

page 11:

   The scope of the
   authentication offered by ESP is narrower than for AH, i.e., the IP
   header(s) "below" the ESP header is not protected.

I would replace "below" with "outside"; I found the use of "below"
confusing and potentially ambiguous (as packet layouts are usually
drawn with the lower-layer protocols above the upper-layer headers..)

page 15:

   (In a host IPsec implementation making use of a socket interface,
   the SPD may not need to be consulted on a per packet basis, but the
   effect is still the same.)

I think it would be clearer/more appropriate to say that policies may
be cached outside the SPD proper on a per-connection/per-flow/
per-whatever basis to speed packet processing.  Given that we're
specifying the nature of administrative interfaces, it perhaps seems
appropriate to specifying whether or not any policy caches need to be
coherent -- in other words, whether changes to the SPD need to be
immediately reflected in cached policy or if it's ok for such changes
to be deferred...
 
page 18:
	Note that in the case of receipt of a packet with an
        ESP header, e.g., at an encapsulating security gateway or BITW
        implementation, the transport layer protocol, source/destination
        ports, and UserID (if present) may be opaque.

It would be useful to include a definition of what "opaque" means in
this context.  I assume from context that it means that it is
unavailable to the policy code..

page 18..19:
        Destination IP Address (IPv4 or IPv6): this may be a single IP
        address (unicast, broadcast, or multicast group), a range of
        addresses, or a wildcard (mask) address.

(essentially similar text also applies to source addresses)

wording nit: instead of just a mask, presumably an "address+mask" or
"address+prefix length" is meant here.  

Is a fully general mask+match facility needed, or is a simpler
address+prefix-length a la CIDR all that's needed?

Also, it would appear to not be meaningful to specify an IPv6 source
address and an IPv4 destination address (or vice versa).

page 19:
        Note that the
        Transport Protocol may not be available in the case of receipt
        of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
        be supported.

What's the difference between specifying a Transport Protocol of `ESP'
vs. a Transport Protocol of `OPAQUE'?  If there is one, it should be
specified here..

					- Bill