Re: [ga] RE: DNSO Constituency Structure

[Eric Dierker <eric@HI-TEK.COM>]

Excuse me but why did not you say they were inappropriate?

A short term TF that only sets the parameters for a WG is
appropriate.

Otherwise they serve only the narrow purposes of the NC
& BS.

(Boy, you got to stand for something or you will fall for
Anything.)

Eric

"Gomes, Chuck" wrote:

> Kent,
>
> I didn't say task forces were inappropriate. I simply do not believe they
> are sufficient at least as far as they have recently been designed.  Correct
> me if I am wrong but I have never seen them produce the following to any
> reasonable degree of completeness: "(3) a
> >   written report and supporting materials (which must include all
> >   substantive submissions to the Supporting Organization
> > relating to the
> >   proposal) that (i) documents the extent of agreement and
> > disagreement
> >   among impacted groups, (ii) documents the outreach process used to
> >   seek to achieve adequate representation of the views of groups that
> >   are likely to be impacted, and (iii) documents the nature and
> >   intensity of reasoned support and opposition to the
> > proposed policy."
>
> Also, the fact remains that the working groups were not given any meaningful
> guidelines with regard to what they should do so the evaluation by the NC
> ended up being more subjective than objective.  To me, that is extremely
> undesirable.  And that tells me that the NC did very little to manage the
> consensus process.
>
> Chuck
>
> > -----Original Message-----
> > From: Kent Crispin [mailto:kent@songbird.com]
> > Sent: Sunday, November 25, 2001 10:48 AM
> > To: [ga]
> > Subject: Re: [ga] RE: DNSO Constituency Structure
> >
> >
> > On Sun, Nov 25, 2001 at 08:54:10AM -0500, Gomes, Chuck wrote:
> > > Patrick,
> > >
> > > I also think Danny did a very good job in discussing
> > consensus in the
> > > message to reference below.  In fact I personally
> > complemented him in this
> > > regard after first reading it.
> > >
> > > But, whereas I do believe that structurally changes could
> > definitely improve
> > > the consensus development process, I do not agree that the
> > problems are
> > > primarily structural versus procedural.  Regardless of what
> > structural
> > > changes are made, if clearly defined processes and
> > procedures are not put
> > > into place, we will find ourselves right back where we are
> > now.  In a global
> > > and hugely diverse environment like the Internet, consensus
> > will always be
> > > hard to reach.  Therefore, if there are not clearly defined
> > policies and
> > > procedures with regard to what should be expected outcomes
> > of the consensus
> > > development efforts, it seems highly unlikely that it will
> > be successful.  I
> > > personally believe that is why many people currently are
> > trying to take
> > > shortcuts with regard to consensus development (e.g., task
> > forces).  They
> > > are easier and take less effort and it's not too hard to
> > convince some
> > > people that they are legitimate, but in reality they are a
> > far cry from what
> > > the bylaws and contracts between ICANN and registries demand.
> >
> > That is, NSI/VSGN will feel free to ignore whatever
> > conclusions may come
> > from any task force of the DNSO.
> >
> > That's very convenient for VSGN, but I don't accept your
> > premise.  Task
> > forces and the like are clearly contemplated in the bylaws:
> >
> >   b) The NC is responsible for the management of the
> > consensus building
> >   process of the DNSO.  It shall adopt such procedures and policies as
> >   it sees fit to carry out that responsibility, including the
> >   designation of such research or drafting committees, working groups
> >   and other bodies of the GA as it determines are appropriate to carry
> >   out the substantive work of the DNSO.
> >
> > And are consistent with the relevant text from the contract:
> >
> >   1.  "Consensus Policies" are those specifications or policies
> >   established based on a consensus among Internet stakeholders
> >   represented in the ICANN process, as demonstrated by (1)
> > action of the
> >   ICANN Board of Directors establishing the specification or
> > policy, (2)
> >   a recommendation, adopted by at least a two-thirds vote of
> > the council
> >   of the ICANN Supporting Organization to which the matter is
> > delegated,
> >   that the specification or policy should be established, and (3) a
> >   written report and supporting materials (which must include all
> >   substantive submissions to the Supporting Organization
> > relating to the
> >   proposal) that (i) documents the extent of agreement and
> > disagreement
> >   among impacted groups, (ii) documents the outreach process used to
> >   seek to achieve adequate representation of the views of groups that
> >   are likely to be impacted, and (iii) documents the nature and
> >   intensity of reasoned support and opposition to the
> > proposed policy.
> >
> > Working groups, such as described in the WG-D report, have simply not
> > worked out as a means of generating substantive work across a broad
> > population -- they inevitably seem to degenerate to a small core of
> > contentious people who drive away all other participants, and then
> > produce a report that has a very narrow base.  (It pains me to say
> > this, because I am a big fan of the IETF model -- I do hope
> > that in the
> > long run, as ICANN becomes more and more mundane, that WGs will be
> > possible.  But it is undeniably true that they have not
> > worked well so
> > far.)
> >
> > Task forces and so on were developed as a means of getting productive
> > work done in a very noisy and contentious environment, and they are
> > making progress.  Surveys and similar instruments, though they have
> > their own faults, are proving to be a much more objective and useful
> > means of gauging community sentiment than are noisy mailing lists.
> >
> > In sum, I think the claims you are making are groundless.  Finding
> > consensus policies is indeed very difficult work, but the processes
> > currently in use meet both the terms of the ICANN bylaws and the terms
> > of the registry contracts, and, though progress is slow, consensus
> > policies, as defined in the bylaws and contracts, are being developed.
> >
> > It would of course be convenient for VSGN to be able to ignore those
> > policies at whim, so I can understand why it would be in
> > their interest
> > to cast the undeniable noise as a "failure of consensus".
> >
> > --
> > Kent Crispin                               "Be good, and you will be
> > kent@songbird.com                           lonesome." -- Mark Twain
> > --
> > This message was passed to you via the ga@dnso.org list.
> > Send mail to majordomo@dnso.org to unsubscribe
> > ("unsubscribe ga" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
> >
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html