Subject: IKEv2: Remaining Issues and Process

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 07 Feb 2003 22:33:24 -0500

This message, and the following four messages to follow are an attempt
by the working group chairs to summarize the current state of the
recently identified open issues in the IPSEC working group, and
outline a path towards coming to closure on them.

These issues are: 

1.  Secure Legacy Authentication
2.  Cipher suites
3.  DHCP vs. Configuration Payload
4.  Revised Identity

In this message, we would also like to address the process of
determining consensus.  According to RFC 2418, it is the working group
chairs which have the duty and responsibility of determining when
rough consensus has been reached.  In some cases, this can be very
easy.  In others, making this determination is less so.  Within the
IETF, consensus is not just about number of people who express support
or opposition to a proposal (to quote Dave Clark, "IETF rejects kings,
presidents, and voting").  As a result, determining consensus requires
human judgment, which is one of the reasons why the IETF has a
carefully thought-through appeals process.

As working group chairs, Barbara and Ted believe that the complexity and
potential contentiousness of different issues may require different
levels of explicitly expressed consensus on the mailing list.  At one
extreme, a spelling correction may not require much more than a note to
document editor, and his agreement that yup, that's a spelling error.
At the other extreme, suppose there is a proposal for a radical change
to an already existing protocol, where deployed implementations already
exist and where there is an expectation that a minor software upgrade is
all that is necessary to deploy an implementation of the revised
protocol.  In that case, more explicit expressions of support may be
required in order to determine that there is consensus for the change.

As working group chairs, Barbara and Ted would prefer that our task of
determining consensus be an easy decision, and not a hard one.  This
is why we have called upon as many people as possible, especially
people who are responsible for implementing these protocols, to make
their opinions on the IPSEC mailing list --- preferably backed up with
technical explanations justifying their preferences.

In the absence of a clear expression of support, we must note that the
working group did choose IKEv2 over JFK, presumably because of a
preference to conserve of the general architecture and structure of
the protocol and its implementations.  Hence, issues which may, in the
judgment of the chairs, cause radical changes to how these protocols
and the policies surrounding them are managed and administered will
require a higher bar in order to prove consensus.

We realize that some people may not agree with this standard, but we
believe it is consistent with the practices of the IETF and with the
preferences of the working group to avoid making fundamental changes
unless they are clearly necessary.  Ultimately, if there is strong
disagreement, settling this issue may require utilization of the IETF
appeals process.

Happily, however, this can be avoided if as many people as possible
express their clear preferences, so that the determination of
consensus is made with ease and without controversy.  For this reason,
Barbara and Ted continue to strongly encourage all IPSEC working group
members to make their opinions regarding the following issues known to
the ipsec mailing list.

In order to meet the challenge set by the Security Area Directors of
finishing working group last call by February 15th, we intend to give
Charlie Kaufman editing directions on Tuesday, February 11th.  Hence,
we encourage people to respond to these issues by close of business on
Monday, February 10th.  Obviously, minor issues can still be raised
and fixed during the last call period, but we need to set a stake in a
ground and make the major fundamental decisions in the next couple of
days.

					Barbara Fraser
					Ted Ts'o
					IPSEC working group chairs

---

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Feb 2003 17:22:15 +0100

In your previous mail you wrote:

   Obviously, minor issues can still be raised and fixed during the
   last call period, but we need to set a stake in a ground and make the
   major fundamental decisions in the next couple of days.
   
=> I don't know if the mobility & co support is a minor issue or not,
but as the NAT traversal is in the WG charter and is currently half
broken, I believe we should improve/fix all the issues relative to
peer address management before the WG last call.

Regards

[email-masked]