IPsec Configuration Policy Information Model
draft-ietf-ipsp-config-policy-model-06

The most glaring nit -- and one that will likely cause some pushback
from the IESG -- is that the references need to be split into normative
and non-normative.

Other nits are the presence of bibliographic citations and some
unexpanded acronyms in the abstract.

There are some non-ASCII characters in at least the PIB document, and
maybe the others.

On a more substantive note -- has the PIB been compiled?  Is the policy
modem supposed to be machine-readable?  If so, has it been compiled?
There's a new policy that suggests putting a short copyright notice into
MIBs, so that a portion can be legally extracted from the RFC and
compiled into a product.  Should the same be done here?  If so, contact
Bert Wijnen  for the exact wording and location.

The kilobyte counters are 32 bits.  This seems odd to me; I suspect
that they should be 64 bits.  We're changing ESP to support a longer
packet counter, and to a first approximation the packets in a bulk data
flow will be about 1K bytes.  I note that a number of MIBs are being
revised to use 64-bit counters -- was that decision a conscious choice
by the WG?

I'm unhappy about the Security Considerations.  The policy model
document just says "see the policy architeture document".  But that
document doesn't exist, so far as I know, and it's not in your charter.
I'm not thrilled that the PIB document says "use a secure transport",
when that isn't defined very well by RFC 2748, but that may be
something the IESG has to sort out.  I suspect that you should add some
text specifically citing the TLS option mentioned in 2748.  I'd
probably have said "MUST" for transport integrity checking...  A more
serious issue in that document is that there's too much boilerplate and
too little specific analysis.  You say that "confidential information"
may be revealed.  Which elements are the most sensitive that way? 
You're transporting information about a security protocol; should, say,
key lengths be protected?  The standard I've been using when evaluating
MIB documents is that the authors understand the details better than
others will; they should do the analysis for the sensitivity level. 
(ipSecProposalPrid strikes me as less sensitive than, say, an X.509
cert, given the criteria you outline.)

Do you want to include AES in the ESP transforms?