RE: Configuration portion of OPEN ISSUES...

["Darren Dukes" <ddukes@cisco.com>]

I'll speak up with my preference for the Configuration Payload and
DHCPINFORM.  Pros/cons to come after the CP to dhcp/radius/ldap doc is done.

Darren

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o
> Sent: Wednesday, February 26, 2003 10:47 AM
> To: Gregory Lebovitz
> Cc: ipsec@lists.tislabs.com; byfraser@cisco.com
> Subject: Re: Configuration portion of OPEN ISSUES...
>
>
> 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.
>
> ;-)
>