Elliptic Curve Cryptography (ECC) in OpenPGP
RFC 6637

Some very minor comments [UPDATE: adequately addressed in -12]:

Section 2:
   Any implementation MAY adhere to the format and methods specified
   in this document, in which case such an implementation is called a
   compliant application.

That seems a bit of a silly use of 2119 language.  I think what you really mean is this:
   Any implementation that adheres to the format and methods specified
   in this document is called a compliant application.

The sentence after that seems silly as well: the normative language here only applies to applications that want it to apply to them.  We don't lock people up if they don't comply with our specs.  It's a small point, and I completely don't mind if you ignore me here, but I suggest removing the sentence.

Please also consider the (very recent) comments from the
secdir review. [1]

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03228.html

My previous comments are below but from a quick glance 
seem to be addressed in -12.

Two substantive comments and a bunch of nits, but this is
good stuff.

#1 The write up talks about running code which is great. Did the
implementers of both take a look at this version of the document?
I don't recall any last-minute changes but no harm checking.

#2 I was left wondering about pkcs#1.5 and bleichenbacher's TLS attack
and other side-channel attacks, e.g. based on timing or power. Those
are not mentioned here, but are not things about which every coder
would know. Is there a good document covering such side-channels
against PGP, and/or ECC that could be added to section 13? (I'd bet
there is, doesn't need to be an RFC.) I think that'd be a good
addition.  If there's no good document at least some mention of side
channels as a security consideration would be good.

Nits:

- 1st para of section 5 reads as if the ECDH variant here is not
interoperable with 6090, is that the case or not? If not (as I hope)
then fixing that would be good.

- the 2119 language at the end of section 6 is odd, better to say you
MUST NOT use another format if there's any doubt that any recipient
doesn't support the new format.

- Does the 2119 lanaguage in section 7 mean that implementations MUST
support all of sha-256, sha-384 and sha-512? I've no problem with that
but making it clear would be better for interop.  Section 12 sort of
says otherwise but its a little confusing.  Maybe add a forward
reference to section 12 from 7? (Is the section 13 forward reference
there correct?)

- start of p7 s/respecfully/respectively/ nice typo:-) same typo
elsewhere as well

- the pesudocode on p7 would be better as a figure so it can be
referenced.

- "the" is missing in various places, I skipped over a bunch until it
got to me;-) that was in section 10: s/applying KDF/applying the KDF/ 

- section 11 could confuse a coder as to whether the truncated form or
usual encoding of the OIDs is used in the protocol. Making that
clearer would be good, e.g., by saying that the non-truncated form is
never used in this protocol (but would be found in e.g., x.509 certs
for keys concerned).

- The reference to TripleDES in section 13 can I guess be deleted and
probably refers to earlier text that's no longer present.