Cryptographic Suites for IPsec
RFC 4308

draft-ietf-ipsec-ui-suites was reviewed by John Loughney, Gen-ART.
He pointed out that this document does NOT define an IANA registry for suite names, and that it's extremely unclear how (or if) suite names should be "registered" in the future.
Given the amount of "reservation" of the strings "VPN-A" and "VPN-B" the document tries to do, that's odd.
Complete review entered as a document comment.

I would suggest expanding the UI acronym on first use in draft-ietf-ipsec-ui-suites.

The comment below on MUST- and SHOULD- was discussed further with Paul
Hoffman, and my comment has been addressed; being left in the record for
completeness.

In algorithms, MUST- and SHOULD- are defined but not used.  I can see the need for completeness
with SHOULD+, but given the unwieldy nature of these terms, it's a bit unfortunate.
Could these be defined when needed, after some experience with whether 
SHOULD+ helps?

I believe it would be useful the suites document to suggest a name for
the IANA registry.

NITS:
In UI suites, section 2:

This section lists optional, non-mandatory suites that be presented to

-->may be presented?

In UI suites, Section 2.2

This suite is what many people expect the commonly-used corporate VPN
security that will be used within a few years of the time this document
is being written.

-->This suite is what many people expect the commonly-used coporate VPN
security profile wil be within a few years of the time of this document's
publication?

In draft-ietf-ipsec-ikev2-algorithms-04.txt

The scope of this document could be a bit clearer, i.e, that the
transforms are about IKE, and not IPsec.

Rewording suggestion. Change:

> The Internet Key Exchange protocol provides for the negotiation of
> cryptographic algorithms between both end points of a cryptographic
> association. Different implementations of IPSec and IKE may provide
> different algorithms. However the IETF desires that all implementations
> should have some way to interoperate. This requires that some set of
> algorithms be specified as "mandatory to implement."

To something like:

The Internet Key Exchange protocol provides for the negotiation of
cryptographic algorithms between both end points of a cryptographic
association. Different implementations of IPSec and IKE may provide
different algorithms. However the IETF desires that all
implementations should have some way to interoperate. In particular,
this requires that IKE define a set of mandatory-to-implement
algorithms, since IKE itself uses such algorithms as part of its own
negotiations. This requires that some set of algorithms be specified
as "mandatory to implement" for IKE.


> Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to
> negotiate which algorithms should be used in any even association.

what does "in any even association" mean?

> is necessary to specify a set of mandatory to implement algorithms to

mandatory-to-implement (multiple places)

> available. This document defines the current set of mandatory to
> implement algorithms for use of IKEv2 as well as specifying algorithms
> that should be implemented because they made be promoted to mandatory
> at some future time.

what does it mean "for use of"? to allow IKEv2 itself to negotiate
phase II? Suggested reword:

This document defines the current set of algorithms that are mandatory
to implement as part of IKEv2, as well as algorithms that should be
implemented because they may be promoted to mandatory at some future
time.


> There are several MODP groups that are defined for use in IKEv2. They

expand/define MODP?