All, FYI! Note, interesting information on IETF take on PSO.... 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
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.
