NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Erik Huizer <Erik.Huizer@sec.nl>
Fred Baker <fred@cisco.com>
General Discussion:poised@tis.com
To Subscribe: poised-request@tis.com
Archive: ftp://ftp.tis.com/pub/ietf/poised/poised.mbox
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 will concern itself with extending the set of RFC documents that describe the IETF process.
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:
· WG and Area procedures; This is to become a BCP document that describes the procedures that the IETF has for WG formation and operation, and for Area Directors. This is an essential formalization and update of RFC1603. The document should additionally include issues like: - WG editor definition - WG chair (de)selection - WG ethicsProposed editors: Scott Bradner and Erik Huizer
· Standards process; The standards process document as produced by Poised95 is not yet complete. The document needs to be updated with specific regard to the standards document structure categorization and publication.
Proposed editor: Scott Bradner
· Nomcom procedures; The Nomcom procedures document as produced by Poised95 may need updating as a result of nomcom experience early 1997. If this is the case, the POISSON WG will take it upon itself to update the document. If not, the POISSON WG will not work on this.
· Code of conduct; based on the Internet-draft: draft-odell-code-of-conduct-00.txt the POISSON WG will produce a code of conduct for the IETF.
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). · ISOC Bylaws and Articles of Incorporation; These need to be published as RFC(s). · The IRTF charter.
POISSON will meet in San Jose and Memphis to try and gauge a rough consensus on these issues and develop guidelines and drafts for the appropriate documents.
Goals and Milestones:
· A New IETF Document Classification
· IETF Working Group Guidelines and Procedures
Minutes of the Process for Organization of Internet StandardS Ong (POISSON) Working Group
· ISOC bylaws documents submitted for RFC publication three weeks ago
· IESG and IETF charter can now be done. IAB charter needs to be redone
· RFC-editor does not seem to keep to the recommended rule that RFCs with numbers ending in 00 cover current standards status. This request is re-issued to the RFC-editor. The RFC-editor argues that this may be too frequent. The Working Group argues that the RFC-editor should then just copy the previous 00 RFC, but at least that will provide a consistent placeholder for people to look for a standards overview.
II. NomCom Consensus Items from List Discussion
· Chair is non-voting liaison to next year's nomcom
· Confirm nomcom volunteers and publish their names
· Nomcom should advise and consult broad IETF base, especially IAB and IESG the nomcom can use a slate of nominees to discuss these with consultants
· 50% rule how to handle imbalance in terms, allow three-year terms gets no consensus yet.
· Co-ADs should/not be coterminous
· Discussion of whether nomcom can 'review' non-terminating IESG members and prolong their terms to three years in order to get the 50% balance
· Discussion of whether this needs to handle kinky specials such as Ipng area. Consensus: no it doesn't need to deal with specials.
· Not mandatory to fix the 50% in any year. This eliminates the problem of the nomcom being forced to install a new candidate for a three-year period.
· How to enlarge the pool of NomCom volunteers?
- Should the list be published? Should web marketing be used?
- Should the qualifications (by attendance of IETFs) be liberalized?
· Changes of community
Simplified and adjusted to other POISSON documents.
Criteria for Working Group creation moved from recording lore to having a formal place in the process. Is this the place for this? Yes. Not 2026.
Suggestions to put in recommendation for less tutorial content in WG/BOF meetings
Some discussion of chair and charter authority now vesting in AD in consultation with Working Group members. May need to make AD's authority more clearly stronger.
III. Requirements for Draft Standard Status
There is a proposal to reduce requirement of two interoperating implementations.
· Is this requirement making it too hard on us?
· This request for dilution is really only for MIBs
· Are we uniformly applying the criteria?
· Should we be standardizing all of these things, e.g. MIBs?
· Should there be different criteria for different 'types' of standards? e.g., MIBs versus routing protocols
· Request to have one of the two implementations be a formal proof not taken as interesting or needed
· Consensus to leave as is this year; the current text should give Ads enough room for maneuvering.
IV. Role of IETF, What are Legitimate Work Items?
See IAB document in message of 17 March. It is concluded that part of this needs to go in IETF charter and part in RFC1603bis.
· See draft-ietf-poisson-ietfdoc-01.txt
· Not meant to define what is *the* protocol (e.g., SNMPv1, v2)
· All but the trademark protection is provided by current process
· Proposal also provides clustering for easier finding bundled documents
· Are we willing to ask ISOC to protect the standard trademark? Yes, if we think this is the right thing to do.
· Possibly need to separate informational documents which have peer consensus from random drivel that comes out because we publish anything as RFC.
· Consensus to further explore this path, especially protection
· No support for killing the name 'RFC'