NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 05-Mar-99
Chair(s):
Erik Huizer <Erik.Huizer@sec.nl>
General Area Director(s):
Fred Baker <fred@cisco.com>
General Area Advisor:
Fred Baker <fred@cisco.com>
Mailing Lists:
General Discussion:poised@lists.tislabs.com
To Subscribe: poised-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/poised/poised.yymm
Description of Working Group:
The POISED working group in 1993-1994 established the basis of the IETF process in its current form. Poised95 established a base set of documents to describe the essentials of the IETF process. POISSON is concerned with documenting issues relevant to the IETF process.
The name POISSON:
The tricky part of describing the IETF process, certainly in the fast changing world of the Internet, is that when you describe the process in too much detail, the IETF loses its flexibility, when you describe to little it becomes unmanageable. This is therefore a slippery subject, hence the name POISSON, which is French for fish. The French word also serves to indicate the international aspect of the WG.
Furthermore the IETF operates by consensus, which sometimes seems to have a POISSON distribution.
The POISSON WG will work on the following items in 1999:
- Review of copyright issues as described in RFC2026, that describes the Internet standards proces.
- Drafting of an agreement for registration and assignment of protocol parameters as performed by the IANA.
The WG will focus on the operational and technical aspects of the contract. The IETF lawyer will be asked to add the necessary legal phrases.
- Discuss the relationship between IETF and ICANN. Should the IETF be participating in ICANN at all? If so, as part of the ICANN PSO? Under which conditions?
An RFC detailing the position will be published if the WG decides that the IETF should not be part of the ICANN PSO. RFC on proposed ICANN PSO bylaws will be produced if the WG consensus is in favor of joining the PSO. Furthermore, in the latter case an RFC will be produced that describes how ICANN PSO officers (on behalf of the IETF) are to be selected.
- Discuss an update of the Nominations Committee document RFC-2282, if and when the current NomCom has suggestions for changes.
Furthermore, the POISSON WG will review documents that are related to the IETF standards process (but that will not be produced by the POISSON WG itself) when available. Such documents may include:
- IETF Charter; This needs to be written by the IETF chair. It is essentially a short mission statement like document that contains references to other Poised documents for further details.
- IESG Charter; This document will be written by the IESG.
- IAB Charter; The IAB needs to revise its charter (RFC1601).
- Proposals related to standards publishing.
Last but not least, Poisson will serve as a generic platform where the IAB and IESG can discuss policy questions if there is the need for consensus polling.
Goals and Milestones:
Mar 99 |
|
Submit Internet-Draft of second version of proposed IANA contract |
Mar 99 |
|
Submit Internet-Draft of second version of proposed IANA contract |
Mar 99 |
|
Second version of drafts for ICANN PSO bylaws and IETF PSO officer selection, or first draft describing why IETF should not be involved with ICANN |
Mar 99 |
|
Second version of drafts for ICANN PSO bylaws and IETF PSO officer selection, or first draft describing why IETF should not be involved with ICANN |
Mar 99 |
|
Submit Internet-Draft for IETF mailing list blocking |
Mar 99 |
|
Submit Internet-Draft for IETF mailing list blocking |
Mar 99 |
|
Present ICANN related issues at IETF plenary |
Mar 99 |
|
Present ICANN related issues at IETF plenary |
Jun 99 |
|
Submit final version of all drafts |
Jun 99 |
|
Submit final version of all drafts |
Jul 99 |
|
Submit Internet-Drafts to IESG for publication as RFCs. |
Jul 99 |
|
Submit Internet-Drafts to IESG for publication as RFCs. |
Internet-Drafts:
· Bylaws for a Protocol Support Organization
· Procedures for IETF appointments to the Protocol Supporting Organization
Request For Comments:
RFC |
Status |
Title |
RFC2282 |
IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees | |
RFC2418 |
IETF Working Group Guidelines and Procedures | |
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. 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.
None received.