[Ballot comment]
The security considerations section is weak.  Ideally it would be
better.  However I cannot think of things that need to be added that
would affect what people do in practice.

Review by Elwyn Davies, Gen-ART

Summary: This document is essentially ready for recycling at Proposed
Standard.  There are a small number of nits that need to be addressed,
especially with respect to references and terminology, but it seems in
good shape.

Review: The document appears to be essentially ready as a recycled
Proposed Standard (updating RFC2402).

There are a small number of nits that should be addressed:

Throughout: Should we be using octets instead of bytes?

Section 1 and Informative Refs: The document is self-referential!
[Ken-AH] is {this document}.

Section 1: It would be useful to point out that the document uses the
terminology defined in the Security Architecture.  With this in mind,
one or two terms (especially 'next layer protocol' could be
capitalized to emphasise that they are defined in the Security
Architecture).

Section 2: In the figure: s/Integrity Check Value-ICV (variable)/
                            Integrity Check Value-ICV (variable
                            length)/
Also I found the table a little confusing on first reading.. takes
some time to realise that that the ESN and ICV padding are not
trailers but 'virtual fields' which are not transmitted.  Maybe this
could be emphasised a little earlier.

Section 2.5, para 1: s/anti-reply/anti-replay/

References:
- Arguably, the IKE ref [HC98] is normative
- IKEv2 should be referenced with the same same status as IKE
- The IPv6 Flow Label RFC should be referenced (normative)
- Arguably, the DiffServ [NBBB98] and ECN [RBF01] refs are normative

Appendix A2: It occurred to me when I read about mutable options in
IPv6 Destination Headers that these do not make much sense for
end-to-end Destination Headers and indeed there is a degree of
inconsistency between Section 3.1.1 (where at least some of the
destination headers are said to be immutable) and the Appendix
statement, quoting RFC2460.  I guess Destination Options associated
with routing headers could be mutable.  Some weasel words might be
useful.

Appendix A2: The main body (Section 3.1.1 etc) refer in general to
IPv6 Routing Headers.  The Appendix calls out explicitly Type 0
Routing Headers... however things have moved on and there is the Type
2 Routing Header for Mobile IPv6 now.  In practice, I would have
thought that the same arguments should apply to any routing header
(regarding predictability at the ultimate destination).  I think this
could be safely generalised.

Meta-criticism (General whinge): AH (and ESP) define the length of the
'extension header' in IPv6 packets in 32 bit units instead of the
default 64 bit unit.  The inconsistency in the L part of TLV format of
IPv6 extension headers is a blot on the landscape of IPv6, making it
harder for IPv6 hardware to work fast, and increasing the complexity
of software, as well as making it difficult to skip over headers (see
v6ops Security Overview draft).  Fragmentation headers are also part
of the problem.  It is almost surely too late to do anything about
this, but it should have been picked up in earlier reviews (had they
been being done!)

[Ballot comment]
Reviewed by Elwyn Davies, Gen-ART

Review in document comments; they seem as if they would have made the document better if addressed, but this has already been around the bush once. Not worth holding it for these.

[Ballot comment]
There is a normative reference to the IPv6 specification (presumably
because this document references the IPv6 header fields), but there
is no normative reference to IPv4.  I think that there should be.

[Ballot discuss]
- Is this a doc going to OBSOLETE 2402? If so, then I believe
  we want the abstract to say so (so that it is very clear).
- has citation in abstract
- It says (in abstract):
    Comments should be sent to Stephen Kent (kent@bbn.com).
  Mmm... not to ipsec mailing list?
- missing IPR section
- Strange disclaimer on page 21 (do we do such things?):

    Disclaimer

    The views and specification here are those of the authors and are not
    necessarily those of their employers.  The authors and their
    employers specifically disclaim responsibility for any problems
    arising from correct or incorrect implementation or use of this
    specification.

[Ballot comment]
If mandatory-to-implement algorithms have been moved out of 2402bis into a
separate RFC (per Section 7 and the 2nd paragraph of Section 5), it might be
nice to have a normative reference to that separate RFC in 2402bis.