Re: Configuration portion of OPEN ISSUES...

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Feb 25, 2003 at 03:02:40PM -0800, Gregory Lebovitz wrote:
> > 	* Keep configuration payload and allow optional 
> > 		RFC 3456-style configuration
> 
> If I'm reading your options correctly, we (I THINK) had some consensus (or
> at least strong interest) on the list for the last option, and some folks
> are working on text to clarify it. 

I THOUGHT we had some consensus for that as well, but right after
Barbara and I gave Charlie editing directions for ikev2-05, and
several days after I conclusion of the comment period for how to
resolve these issues, a number of implementors, including Tero, Derek,
Tylor Allison, argued against this position.  And others, including
Scott Kelly and Pekka Riikonen, suggested a DHCP-over-IKE.  (Sorry for
not including it in our original list.)  And none of the people in
favor of keeping configuration payload spoke up.

One of the frustrating things about trying to determine consensus in
the IPSEC wg is that the consensus seems to change from week to week,
perhaps (in part) because some wg contributors are not reading this
mailing list regularly.

Another frustration is that some people will suggest an idea, such as
DHCP over IKE, but not necessarily propose specific text to implement
such an idea.

So, I hereby call upon:

1) People who are in favor of DHCP-over-IKE to submit proposed text
that explicit documents their proposal

2) People who are in favor of keeping configuration payload to speak
up.  And more generally, people with any opinion on any of the options
to speak up, listing the tradeoffs to the various options and
explaining why they prefer one option over another.

						- Ted


P.S.  The following very amusing "version" of RFC 2418 Section 6 was
written by Jari Arkko as part of a discussion on the I-D
draft-hardie-wg-stuckees-00.txt.  For the humor impaired, this was a
joke, but in all seriousness, we could really use more "stuckees" in
this working group.  (We're almost done, folks; it just requires one
last hard push to finish the ikev2 document.)

And now, for your reading pleasure...

6.1. PHB (Pointy Haired Boss)

   The PHB is concerned with making forward progress through a
   fair and open process, and has wide discretion in the
   conduct of WG business. The PHB must ensure that a number
   of tasks are performed, either directly or by others
   assigned to the tasks. Unlike their corporate counterparts,
   however, IETF PHBs do not actually have authority to
   command specific persons to perform specific tasks.

6.2. Slave

   Most IETF working groups focus their efforts on a document,
   or set of documents. A working group generally designates a
   person or persons to serve as the Slave or Slaves for a
   particular document. The Slave is responsible for ensuring
   that the contents of the document accurately reflect the
   decisions that have been made by the working group. Until
   very recently, Slaves also had to carry all the water to the
   IETF hotel, dig holes in the ground using their bare hands,
   and edit their documents using nroff.

6.3. Stuckee

   In order to make progress, working groups need to establish
   an understanding of technical alternatives, evaluate the
   feasibility of the proposed solutions in a variety of
   environments, and carefully review their documents.
   Furthermore, consensus is more fun when there are more
   participants than just the PHBs and the Slaves. Stuckees are
   expected to participate in the discussions, perform timely
   reviews of documents, and express their opinions when
   decisions are being made.

   Like others, Stuckees are volunteers. However, Stuckees do
   not get their name in any of the publications.

6.4. Tourist

   Most IETF working group meetings are held in big rooms.
   Experience has shown that the number of Slaves and Stuckees
   rarely exceeds ten for any working group. This would look bad
   for any potential observers trying to gauge the interest
   level of the new technology. In order to solve this problem,
   working groups arrange for a number of designated Tourists to
   participate the meetings. By definition, all other
   participants other than the PHBs, Slaves, Stuckees, and Area
   Dictators are Tourists. It is inappropriate for a Tourist to
   participate in discussions, whether live or on the list.

   Tourists are volunteers as well, but they get free Internet
   access while in the room.

6.5. Area Dictator

   Area Dictators are responsible for ensuring that working
   groups in their area produce coherent, coordinated,
   architecturally consistent and timely output as a
   contribution to the overall results of the
   IETF. Additionally, given that Slaves are often illiterate
   and Stuckees lazy, the Area Dictators have formed the
   Internet Engineers Spelling Group (IESG), which helps the
   working groups to correct the grammar mistakes from their
   documents.

;-)