All, Some of this may be of some interest to some of you. Most especially the PSO info. Regards, -- Jeffrey A. Williams CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
Here's the new (and final I hope) version of the minutes for the POISSON meeting. Since a lot of people started to correct whatb they said during the meeting (according to the draft minutes), I simply deletedthe discussion part, as the discussion results are summarised in consensus. ErikIETF/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. Format should be self-contained (therefore not HTML), so links would not be stale, and conformant in a verifiable way. 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. After these presentations there was a discussion. Where some sort of consensus seemed to emerge, so the Chair took some 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.
