Document: draft-groves-sakke-00
Reviewer: Richard Barnes
Review Date: 04 Jan 2010
IETF LC End Date: 18 Jan 2010
IESG Telechat date: (if known)

Summary: It's not clear to me why this draft is necessary, given that there is
already a published specification for the algorithm.  Putting that aside, the
draft is not ready for publication.  

Major issues:

-- When I read this document, it's not clear to me what I would need to do to
integrate this into a protocol.  In particular, it would be helpful to have a
list of parameters according to:
(a) Which ones are constant for the whole algorithm
(b) Which ones are expected to be set out of band for a given implementation
(c) Which ones must be negotiated in the protocol
For example, the algorithm makes use of a hash function and an elliptic curve,
but it's not clear how the communicating parties agree on what hash function
or curves to use.

-- From a security perspective, the choice of a single static curve makes me
uncomfortable.  This is not typical of other EC-based algorithms.  For
example, RFC 4754, RFC 5091, and ECDSA (ANSI X9.62) all allow choices of
curves, even if that choice is restricted to an enumerated set or a class.

-- If this document is extending RFC 5091, then it should formally extend it
(as in, with a line at the top), and explain in more detail its relation to
RFC 5091.

Minor issues:

-- The notation lg(x) for logarithms is not defined.  Suggest adding to the
Notation section.

-- The normative references [MIKEY-SAKKE], [P1363], [P1363a] should be made
informative.

-- The informative references [S-K], [SK-KEM] should be made normative

-- I have not checked whether the algorithm in this draft is the same as that
described in references [S-K] [SK-KEM]

Nits/editorial comments:

-- Section 2.2 seems to have additional spaces at the beginning of each line.