Re: Draft Poisson minutes[Divisiveness concerns for PSO]

[Jeff Williams <jwkckid1@ix.netcom.com>]

Karoline and all,

  As we are seeing with the DNSO with more and more frequency,
the idea of having classes or "Constituency's" in a membership structure
are very divisive and lead down a very slippery political slope that is
both non-productive in their existence and a form of gerrymandering
than leads to some level of exclusion of the Stakeholder community
as outlined in the NTIA's White Paper.

  Therefore as suggested during many of the discussions and
considered more viable, I would suggest a flat membership
model verses a Class Model for the PSO.  Otherwise the same
mistakes made by ICANN on the DNSO shall be repeated and
therefore propagated with questionable results....

Karoline Scott wrote:

> As the "unknown woman" referred to in the minutes below, please note the
> following correction in the minutes about my comments.
>
> I agreed with opening up the membership in the Class 1 category as was done
> to some degree in the last version of the Bylaws, to standards development
> organizations other than the IETF, such as ITU-T and W3C.  Further to that I
> said that reducing the number of membership classes from 4 to 3 would be
> good, where the third category would be for other organizations, such as
> companies and other interested individuals, to participate in the membership
> of the PSO.  I did not say "I agree that the membership classes should be
> reduced from four to two."  I was, and still am, concerned with the
> exclusivity of the two classes as presently defined and want to see a more
> balanced proposal to move forward on.
>
> Other than that point, you captured my main comments.
>
> Karoline Scott
> Nortel Networks
>
> -----Original Message-----
> From: Erik.Huizer [mailto:Erik.Huizer@sec.nl]
> Sent: March 30, 1999 7:48 AM
> To: poised@lists.tislabs.com
> Subject: Draft Poisson minutes
>
> IETF/Minneapolis
> POISSON Meeting
> 17 March 1999
>
>         Erik Huizer, Chair
>         Zita Wenzel, Recorder
>
> 1.      Opening
>
> 2.      RFC Series
>
> Revisions to the RFC Editor web site make it easier to use.  A searchable
> database is available.  Marshall Rose and Carl Malamud started a project
> where
> they converted RFCs to XML as source rather than ASCII.  A common tool would
> make life easier, but not Word.  RFCs need to be easier to produce.  Would
> be
> nice to have a format that supports tables and graphs.  IETF is not trying
> to
> sell RFCs, but maintain an archive.  Good reason to stick with ASCII is for
> developing countries.  Scott Bradner said that Jon Postel said that
> everything
> should be self-contained (therefore not HTML) so links would not be stale.
> Don't use proprietary formats.  Need to move on from ASCII; publish in more
> than one format.  No consensus.  Is this purely a technical specification?
> Yes.  Consensus on Marshall publishing his draft as an informational RFC and
> individual members of the WG encouraged to comment.
>
> 3.      Copyright
>
> Copyright statement is embedded in standard process RFC.  Scott Bradner: the
> reason for the copyright is to ensure RFC's availability; limited use.  See
> RFC
> 2026.  To apply to all contributions?  When does this apply?  Are derivative
> rights permitted?  Three options.  Issue: documents submitted to the working
> group containing a prohibition on the creation of derived works.
> Motivation:
> protection against other-party takeover of submitters' drafts.  In essence,
> lack of trust in the integrity of other participants.  Problem:  even
> informational-track material may be destined for incorporation in another
> document rather than being kept in its original form.  Resolution:  advice
> that
> prohibition against creation of derived works is acceptable only for
> non-standards-track documents which are strictly for the information of the
> Internet community and not intended to be incorporated into working group
> documents.  Documents, for example, submitted to other organizations such as
> ISO should not be modified later.  ISIS case could see both options one and
> two.  Suggestion to ask the lawyers for a statement to justify the copyright
> statement and to reduce confusion.
>
> 4.      IETF protocol parameter registration
>
> Brian Carpenter:  Everything is still working and done by the same people in
> the same location (former IANA).  Job list created.  US Government said,
> "...coordinate the assignment of technical protocol parameters."  Esther
> Dyson
> clarified that it is not ICANN policy to do parameter assignments.  After
> policy discussions, we will finalize the job list between IAB and
> ICANN/IANA.
>
> 5.      ICANN and PSO
>
> Scott Bradner:  ICANN grew out of the Green Paper and White Paper and its
> charter is be the top of the pyramid for domain names and IP addresses,
> responsible for root name servers, and to "coordinate the assignment of
> protocol parameters."  Structure is Board, supporting organizations and
> committees, and miscellaneous ICANN committees.  ICANN is the facilitator of
> rule making, not actual assigning of parameters.  Domain Name Supporting
> Organization, Address Supporting Organization, and Protocol Supporting
> Organization: propose and review policies related to names, addresses, and
> standards organizations. Board consists of 9 at-large directors and 3 from
> each
> SO with geographical distribution.
>
> Remark: Respond to WIPO RFC3, which is input to ICANN's processes re:
> trademarks (www.wipo.int).
>
> Is there a need for a PSO?  What is the role of the PSO?  Pro: structured
> way
> to import technical clues into ICANN, protocol council gets to review
> protocol-related policy proposals, PSO nominated Board members vote on
> policy
> proposals from elsewhere, forum to resolve assignment disputes between
> standards organizations.  Cons: ICANN can ask when it needs advice,
> standards
> organizations are different than addresses or names (addresses and names get
> some authority from ICANN; not needed for standards organization), unknown
> impact on standards organization's autonomy.  For example, standards
> organizations need to review for content.
>
> Should a PSO be a committee of ICANN (like the DNSO proposal)?  Pro: It's
> what
> the Board seems to like, no confusing separate organization, liability
> issues
> are clearer, it is cheaper, may be easier for some standards organizations
> to
> deal with.  Con: unknown impact on standards organization's autonomy, not in
> control of own processes (may be ameliorated by MoU instead of membership or
> appointing representatives).
>
> How many classes/constituencies?  Proposal:  two classes: 1) open,
> international, voluntary technical standard and technical specification
> development organization which: develop IP standards, is greater than a
> minimum
> size, produces significant deployment of standards, whose standards are
> available for free or  a small processing fee, 2) other standards
> organizations.  Rationale behind this (change from last time when four were
> presented) is that the PSO should be composed of "practitioners of the art."
>
> Can participate through the standards organizations or through the at-large
> members.  Anyone can come to IETF; many companies can join W3C.
>
> Esther Dyson:  Similar to IETF, the Board has different opinions but
> operates
> through consensus.  DNSO process: Board will ratify what comes up that isn't
> crazy.  More than one proposal was presented and Board combined them.  Would
> like to see the same process used.  General assembly and constituencies are
> used; would  IETF map to one or the other?  Send three people, and policy
> recommendations to the ICANN Board are the two things the PSO needs to do.
> The
> PSO would involve more than talking to ICANN Board, they would also be
> talking
> to other SOs.  May 24-27 is next Board meeting in Berlin.  If the proposal
> can
> be posted a month before, then the Board can consider it at this meeting.
> The
> WIPO paper will be discussed in Berlin.  The ASO will probably be presented
> in
> Santiago, Chile August 24-26.
>
> Mike Roberts:  People need to understand the government process was
> bureaucratic, but it has been trimmed back.  The SOs are a device for
> intelligent advice to be present at the table for discussions.  Bylaws got
> top
> heavy due to latecomers with paranoia.  Want to stay as lightweight as
> possible
> while satisfying openness and fairness.  CEO gets the people to get the job
> done, also gets advice.  For example, accreditation guidelines moved from
> the
> Board to actual documents and people are working on submissions.  Will ICANN
> take advice?  Yes, IANA has technical advisors.  Also position for CTO to be
> recruited.
>
> Hans Kraijenbrink:  From principles derived at the Singapore meeting for the
> DNSO:
>
>                             ICANN Board
>
> At-large                  DNSO         ASO          PSO
>                                                  |
> protocol council members                       Council
> representatives from                             |
> standards committees                       General Assembly
>                                                   IETF
>
> John Klensin:  Are there alternatives to the PSO while preserving the
> objectives?  I support this Board and ICANN.  IETF doesn't vote.  Proposal:
> drop the PSO and replace it with ex-officio, non-voting seats on the Board.
> Work by persuasion.  This is very lightweight.
>
> Brian Carpenter:  This issue was discussed within the IAB last night.  IETF
> "cares about the health of the Internet."  We want ICANN to succeed.  We
> want a
> lightweight organization.  There is no need for symmetry among the
> Supporting
> Organizations.
>
> Keith Moore:  Standards organizations cannot be subservient to ICANN.  This
> argues for representatives on the Board.  ICANN's scope should stay narrow
> both
> now and in the future.
>
> Dave Crocker:  This is not about Internet governance.  We need to provide
> technical input.  The protocol parameter assignment is IETF's business.  Who
> we
> decide to subcontract with is our business.  We want ICANN to succeed.  This
> is
> not policy, so there is no need for dispute resolution.
>
> Daniel Karrenberg:  I like Klensin's approach.  I agree there should not be
> dispute resolution for standards bodies.  I support ICANN.  I want to be
> careful that these comments are not seen as weakening ICANN.
>
> Robert Shaw (via email):  Dispute resolution is not needed between standards
> bodies.
>
> Roberto Gaetano:  Do we need a PSO?  No.  Klensin's approach is the right
> one.
> We need to stay lightweight.  The Supporting Organizations have to be a part
> of
> ICANN.  IETF should be the leading organization for the PSO.
>
> Jeff Schiller:  Klensin's proposal is supported.  Protocols are inherently
> different from names and addresses.  Names and addresses are limited and
> users
> need them.  For example, PGP.
>
> Unknown woman:  I support IETF as a major player and I support the idea of a
> PSO.  I agree that the membership classes should be reduced from four to
> two.
> Don't preclude other organizations.
>
> Leslie Daigle:  Dispute resolution for standards organizations.  ICANN
> should
> not be in the business of  development of standards, but arbitration between
> standards bodies.
>
> Hans Kraijenbrink:  There should be a council.  What I presented is a
> proposal
> that was discussed in Singapore as principles for the DNSO that would leave
> IETF intact, but allow it to provide input via the PSO.
>
> Siegfrid Langmeer:  I don't see the PSO as an independent or different
> organization.  It is the same as the DNSO.  It is not special.
>
> Bradner responds:  We are different, not special.  We are not enabled by
> ICANN
> the way names and addresses are.
>
> John Klensin:  Dispute resolution among voluntary, independent standards
> bodies
> is not easy or possible.  What Jon Postel did was to send the two parties
> away
> and ask them to come to an agreement among themselves.  Organizations must
> agree to this arbitration.  When ANSI intervenes, if there is no agreement
> there is no standard.  Between the ISO and the ITU?  No result.  I would
> welcome arbitration at a CTO level, but not at an intermediate level.
>
> Erik Huizer:  Straw polls:
>
> 1.      No PSO?  IETF delivers expertise via another method.  No consensus.
> 2.      If there is a PSO, does IETF need to be a part of it?  Yes,
> consensus.
> 3.      If there is a PSO, should it be lightweight.  Not asked because no
> one
> presented a different viewpoint.
> 4.      Should the PSO be part of ICANN?  Consensus was that people did not
> have
> enough information to decide.
>
> Erik Huizer:  My summary is 1) to support ICANN, 2) to keep the IETF
> independent, and 3) to provide technical input to ICANN.  What is the best
> means to provide this input?
>
> Scott Bradner:  Let's propose a concrete skeleton and discuss it on the
> POISED
> list.
>
> Erik Huizer:  And let's try to get consensus by the deadline for the Berlin
> Board meeting which is approximately April 20.

Regards,

--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208