Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
draft-kuegler-ipsecme-pace-ikev2-10

Section 5.1 states:

   The input password string SHOULD be processed according to the rules
   of the [RFC4013] profile of [RFC3454].

Why or when would an implementation violate the SHOULD? That is, why is this not a MUST? Also, please be aware there there is work underway to obsolete RFC 3454 and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting that you change the text to something like "use RFC 4013 or equivalent". However, when your experiment is done and you put this on the standards track, you'll probably be asked to update the internationalization to use saslprepbis (if the PRECIS WG finishes before your experiment does!).

- I found the overall description of PACE hard to follow, it'd be
better if you gave the MODP method for mapping s in the overview so
that someone who just knows standard D-H can see why this is a ZKPP.

- "free of patents" is not possible, and not really appropriate as a
claim in an RFC

- section 5.1 could badly do with some examples if that's possible.
I'd expect interop problems in any case, but more without that. Those
might be shared with the other scheme drafts.

- [I-D.kivinen-ipsecme-secure-password-framework] is now an RFC

- s2, point 1: don't just say that a value encrypted with the
password (ENONCE) is sent to the responder, since that'd in general
be vulnerable to off-line dictionary attacks. Maybe say that ENONCE
is ok to send because it is specially constructed so as not to expose
anything about the password.

- "MUST be presisted to stable memory" might be too onerous, I'd say
a SHOULD would be better there in case someone has to use an existing
DB of shared secrets.

- The LongTermSecret scheme seems to be independent of PACE so I
wondered why its here and not in a document of its own.

- 4.1 seems to call for a table of mappings from authenticated
ciphers to the unauthenticated equivalents, otherwise interop is not
likely. I think you need to provide those mappings (or at least some)
and ideally ask IANA to create a registry for others (it'd be needed
if this got onto the standards track later).