RE: Configuration portion of OPEN ISSUES...

["Stephane Beaulieu" <stephane@cisco.com>]

>
> 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.

Sometimes, the same question gets asked over and over and over.... and it
gets tiring of restating your opinions over and over and over...  Not a
personal dig here Ted, just a fact of life in the IETF.

Some of us had agreed that a good path forward would be to keep the
configuration payload for initial very basic configuration (IP, WINS, DNS,
DHCP-SERVER-IP).  This would satisfy a VERY LARGE number of existing
deployments (100% that I've seen so far, though I'm not naive enough to
think that it won't change ;).  It would also allow you to use a RADIUS or
LDAP server in the back-end (rather than DHCP). *IF* other DHCP specific
information is required, a remote Client MAY send a DHCP packet (via a valid
IPsec SA) directly to the DHCP server to get the rest of the configuration.

I *thought* this was the agreement, but somewhere along the way, this
changed to

> > 	* Keep configuration payload and allow optional
> > 		RFC 3456-style configuration

Nobody wants to do this because this basically says you need to support both
CP and RFC3456.

Where it should have said

*Keep configuration payload and allow optional unicast DHCP configuration
after phase 1 is complete.

I *think* everyone can live with this.  Some have expressed a desire for
other solutions (DHCP in IKE for example), but I have not heard anyone say
that the above solution is not acceptable.

>
> 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.
>
> ;-)
>