NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 30-Nov-98
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@tis.com
To Subscribe: poised-request@tis.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 will concern itself with extending the set of RFC documents that describe 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 concensus, 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 formalisation and update of RFC1603. The document should additionally include issues like:
- WG editor definition
- WG chair (de)selection
- WG ethics
Proposed 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.
Proposed editor: Jim Galvin
- 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.
Proposed editor: Mike O'Dell
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:
Oct 96 |
|
Submit draft-odell-code-of-conduct-01.txt to IESG for publication as an RFC. |
Oct 96 |
|
Submit Internet-Draft revising RFC1603 |
Oct 96 |
|
Submit Internet-Draft with revisions to standards process |
Oct 96 |
|
Submit Internet-Draft of IETF Charter |
Dec 96 |
|
Submit revised Intenet-Draft of WG Guidelines |
Dec 96 |
|
meet in San Jose |
Dec 96 |
|
Submit revised Internet-Draft of standards process |
Mar 97 |
|
Submit Internet-Draft revision of Nomcom procedures |
Mar 97 |
|
Submit code-of-conduct to IESG for publication as an RFC |
Apr 97 |
|
Meet in Memphis |
May 97 |
|
Submit Internet-Drafts on WG Guidelines, Standards Process, and NOMCOMM to IESG for publication as BCPs |
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 | |
Process for Organization of Internet standards Ongoing (POISSON)
Chair: Erik Huizer (SEC)
Tuesday meeting:
Minutes by Erik Huizer (SEC)
Two issues were discussed at the Tuesday POISSON meeting:
1- IETF distribution list moderation
2- RFC series of publications
ad 1)
Fred Baker proposed a charter for the IETF list to clearly indicate what the purp[ose of the list is for. The proposal also allows for the IETF chair to block threads and/or individuals from the IETF list if their submissions are deemed to be outside of the scope of the charter.
There was consensus in the WG that a charter is needed, and that it needs to contain some wording as to what happens when the charter is violated.
There was no consensus yet on how strict or lightweight the "penatly" structure should be, and as to which IETF officers should be responsible for enforcement.
It was noted that blocking people to send to the IETF list can be circumvented by those people. It was also suggested that blocking of threads might be more productive than blocking individual submissions.
The discussion will be continued on the POISSON mailinglist.
ad 2)
The question is whther there needs to be a separate series from the RFC series for non-IETF related publications. Currently anyone can publish almost anything as informational RFC. This is sometimes used as an end-run around the IETF processes. Non-IETf people depend on the reliability of the RFC series, and do not see the difference between STD RFC's, FYI RFC's, BCP RFC's, IETF Informational RFC's and the rest.
There was no clear consensus that any change from the current situation is needed. Many people in the Wg valued the fact that documents unvetted by IETF can be published as RFC's. Others maintained that something needs to be done to minimise the confusion.
Since there is no consensus, the issue will not be taken up by POISSON.
POISSON Meeting
Thursday 12/10/98
Minutes by Zita Wenzel (ISI)
1. Opening
Mike Roberts, Interim CEO of ICANN, Esther Dyson, Interim Chairman of the Board of ICANN, and Hans Kraijenbrink, member of the Board of ICANN are here.
2. ICANN (Internet Corporation for Assigned Names and Numbers)
Mike Roberts: We want to do the right thing for the Internet even though there are lawyerly aspects now present. We are unchartered and want to learn from our mistakes.
The Supporting Organizations for each of the three functional areas (names, addresses, and protocols) need to be addressed. They are to be composed of open organizations, they should refer policies to the Board, and they should show evidence of fair and equal treatment as stated in the bylaws. To avoid paralysis, Board power is reserved.
One may interact in a variety of ways, e.g., by the committees. All internauts will be heard.
There are rights to reconsideration and for aggrieved parties to be heard as stated in the bylaws. The US government will not pass laws on this; it is up to the community or the US government will take it back.
3. Q & A
Perry Metzer: The original IANA was a protocol number function.
Scott Bradner: We don't want to go begging for bits in our own protocols.
Bob Hinden: Addresses are essential for protocols where we don't go to the registry. We would want a convenient technical place to go.
Mike Roberts: The Board won't move without input from the community. We need provisions for what you describe.
Scott Bradner: For example, not all addresses go to the registries, some are maintained for experimental purposes like multicasting. The IANA handles these addresses directly.
Daniel Karrenberg: The ASO (Address Supporting Organization) specifically excludes those addresses.
Brian Carpenter: In most of Europe +112 works to call in an emergency. We don't want a six-month delay in address assignments due to politics.
Geoff Huston: Two functions - technical assignment and address distribution - are for the public good. Countries have been changing their distribution publicly. We must prioritize the public policy outcome desired.
Mike Roberts: The first problem is with the gTLDs.
Geoff Huston: No, the first problem is with IPv6.
Mike Roberts: The ASO is coming up with policies for IPv6 allocation.
Esther Dyson: There are different conflicting views; we are looking for consensus.
Bernhard Stockman: Avoid delays.
Erik Huizer: The ISI team was perfect. The liaison with the RFC editor was seamless. We now need to codify and write these relationships and functions. The IAB and IESG have started a proposal with bylaws for the PSO (Protocol Supporting Organization).
4. Draft Bylaws
Protocol Supporting Organization for The Internet Corporation for Assigned Names and Numbers
A Draft Proposal
Scott Bradner
sob@harvard.edu
Ground Rules
- discuss proposed PSO details
- discuss IETF involvement in PSO
ICANN SOs
- serve as advisory bodies to the ICANN Board
- nominate directors for the ICANN Board
- develop policy in their areas to present to the ICANN Board
- evaluate other policy proposals
ICANN & IANA
- traditional IANA functions
- IP addresses
- TLD domain names
- configure root name servers
- protocol numbers
- ICANN marching orders
- IP address assignment policy
- TLD policy & assignment
- coordination of assignment of protocol #s
- root servers
ICANN & IANA
- IETF IANA function not part of ICANN agreement with US government
- i.e. protocol numbers and values assignment
- policy for IP address assignment & DNS not part of IETF-related IANA
- IETF (ISOC) will contract with ICANN for IETF IANA functions for continuity
- IAB responsibility to develop contract
US government says "coordination of protocol assignment" not just assignment. We could contract elsewhere. We will have contractual relationships.
IETF as PSO
- Jon's feeling
- IETF is not the only group producing Internet-related standards but IETF should be the major voice at this time
- isolation from ICANN board
- ICANN can & does make requirements on the Sos
- potential threat to IETF independence from a future board
ICANN puts requirements on SOs (openness, etc.). Putting the PSO in place between IETF and ICANN is a safety mechanism.
ICANN Tasks
- ICANN bylaws give functions numbers related statement
- Coordination of the assignment of other Internet technical parameters as needed to maintain universal connectivity on the Internet from US government White Paper
ICANN PSO Description
- "The Protocol Supporting Organization shall be composed of representatives from Internet protocol organizations and others with legitimate interests in these issues, as determined by the Protocol Supporting Organization consistent with Section 2 of this Article and approved by the Board. The Protocol Supporting Organization shall create a Protocol Council to make recommendations regarding the operation, assignment and management of protocol parameters, such as port numbers, enterprise numbers, other technical parameters and related subjects."
PSO Highlights
- very lightweight but real (corporation, association ??) may be based outside the US pso functions providing funding for ICANN (possibly nominal) appointing three ICANN Board Members creating a Protocol Council to advise ICANN
This is a shim organization, yes, but it is real.
PSO Overview
- membership organization
- IETF a member
- board of trustees
- to meet legal requirements
- no pay or reimbursement to board members
- open board meetings at IETF meetings
Purposes of the Organization
- To select nominees for the board of ICANN
- To form a Protocol Council to advise ICANN on matters referred to it by ICANN.
- To provide financial support for ICANN as requested by ICANN.
Limitations on the PSO
- not develop policies to be recommended to ICANN.
- not interfere with contracts between ICANN and individual technical standards or technical specifications development organizations, or any other contracts not with the Corporation itself.
- not develop technical standards, specifications or protocols.
- not operate any Internet infrastructure facility such as an IP address or domain name registry.
The PSO doesn't see policy but contracts specific assignments.
PSO Membership Classes
- Class 1 - technical standards and technical specification development organizations which meet specific criteria
- Class 2 - other standards bodies
- Class 3 - other organizations
- Class 4 - interested individuals
Class 1 Criteria
- Open, international, voluntary technical standard and technical specification development organizations which:
- Develop standards and/or specifications for use over IP networks.
- Can demonstrate active membership in the IP-related standards and/or specification development process of more than 1000 individuals, if individual memberships are used by the organization, or 100 companies, if corporate memberships are used by the organization.
Class 1 Criteria, contd.
- Makes its resulting standards and/or specifications freely available via the Internet.
- Contract all or essentially all of the assignment and management of protocol parameters, such as port numbers, enterprise numbers, and other technical parameters and related subjects for all standards to ICANN.
W3C doesn't make its standards available for free.
Class 1 Criteria, contd.
- International voluntary standards bodies are defined as private sector international organizations that plan, develop, establish, or coordinate voluntary standards.
An organization shall be considered open and international if its standards or specifications development process is open to any person of any nationality on equitable terms. It shall be considered voluntary if it makes no claim to compel use of its standards and specifications.
Membership Class Option
- may not need Class 3 & Class 4 if ICANN open membership can be satisfied by organizations and individuals joining Class 1 and Class 2 members as members of those organizations.
The ASOs are looking at this.
Membership Fees
- All members will pay fees as allocated by the board to cover the costs of the PSO expected to be quite small fees to be determined by the board keep in mind ability to pay
Meetings
- normally only 1 annual meeting open meeting held at an IETF meeting proper notice, agenda, etc
Public Information
- all PSO information is published on public web page except personnel info (if any) including any payments to board and protocol council members
PSO Board
- 3 - 12 members
- elected by class 1 members
- 3 each if less then 5 class 1 members
- 2 each if 5 or 6 class 1 members
- 1 each if > 6 class 1 members
- officers as required by law
Board Duties
- set & direct the collection of fees
- deal with relationship with ICANN
- modify bylaws as required
- pay ICANN fees (if any)
- participate in selection of ICANN board members
PSO ICANN Board Members
- each class 1 member nominates one or more persons for each opening in PSO ICANN board members
- nominees posted on PSO web page for 30 days
- PSO board selects an individual from list of nominees for each opening
- note ICANN requirement for geographical distribution
Protocol Council
- provides advice to ICANN board
- 18 members, 3 year terms
- each class 1 member nominates candidates for open positions
- ensure at least 50 % more candidates than positions (different than in ID)
- petition candidates require 10% of membership
- membership vote to select candidates
Other Standards Groups
- need to work with other IP-centric standards groups - e.g., W3C
- need to work with other standards groups e.g. ITU-T, ETSI
We must demonstrate widespread support for ICANN.
ICANN Request Points
- membership description
- description of policy development process
- open, transparent, fair and non-discriminatory processes
- policies to ensure international and diverse participation
- policies for disclosure of conflicts of interest
- methods for funding the SO and providing funding for ICANN
Discussion
Stillson: Will we be begging for numbers?
Scott Bradner: The contract will specify exact assignment.
Perry Metzer: Is this just an electoral college for ICANN?
Scott Bradner: It also answers protocol questions.
Roberto Gaetano: I don't like the classes of members. We need to reserve seats for other classes. I have no problem with IETF having control, but not for the totality of seats.
Scott Bradner: The bylaws were changed to include others so that there is balance and other standards bodies are included.
John Gilmore: Three points: 1) The PSO is not proposing policies. What about routing and address assignment?
Scott Bradner: Addresses are not under our jurisdiction; they are under RFC 2050 and the ASO. When we're in the minority is this a situation we would be comfortable with? This is a question asked at the ICANN open meeting in Cambridge by Tamar Frankel. This is protection for that.
John Gilmore: 2) Why should class 1 organizations contract with ICANN for clerical function?
Scott Bradner: It is not simply a clerical function. There is an exclusionary clause to keep only standards groups.
John Gilmore: 3) One organization to do this is a bad idea. All members can vote but all candidates are from the IETF. It should be 1% like ISOC, not 10%. One man, one vote.
Keith Moore: Class 1 members justification is artificial and not right. IETF can't back out of this.
Daniel Karrenberg: This is over-engineering the solution. Because discussion at three levels can stall the process (SO, other SOs and the Board). Delete 3 and 4 class members. There will be policy decisions and we may regret it if it is not considered.
Jeff Schiller: I am on the IESG and I am not bought in. Accountability. I am afraid the DNSO (people and reptiles) loud voices will decrease the thoughtful attention to protocols. Microsoft would fit the organization for the PSO. I don't think protocol assignment needs to go to ICANN; it should stay within the IETF. I didn't have time to react to this proposal. I think the IETF should be the PSO.
Scott Bradner: A draft has been out for a long time. This would be a contract with specific assignments.
Kent Crispin: This is a Pollyanna view of the world. The IETF can no longer avoid dealing with reptiles. We can't avoid dealing with governance issues.
John Lynn: I am concerned about serializing dependencies.
Jack Holdenworth: I see this as an immense opportunity. We need the ISO and ITU-T. The ISO is filing documents as Internet Drafts.
Scott Bradner: No fee.
Chris Newman: Here is a suggestion: contract non-controversial registries to ISI and controversial ones to ICANN.
Erik Huizer: Are the SOs separate organizations or part of ICANN?
Mike Roberts: There are no requirements for absolute symmetry among the SOs. Different versions are out there. The general idea is that they are separate.
Straw poll: 24 yes, create PSO; 19 no, IETF is the PSO; many undecided with not enough information.
Conclusion was no consensus. People want to see the contracts to decide.
Poised@tis.com and use the request convention to subscribe.
5. Draft Appointments
Procedures for IETF appointments to the Protocol Supporting Organization
Prepared by Brian Carpenter; presented by Scott Bradner
Appointments Required
- nominate individuals for 3 positions on the PSO Board
- nominate three members of the ICANN Board
- nominate individuals for eighteen positions on the ICANN Protocol Council
PSO Board Members
- proposal for selecting PSO Board members
- IAB Chair
- IETF Chair
- another current member of IESG or IAB selected by consensus of IAB & IESG
- note above are already appointed by IETF nomcom process
- avoid new tasks for nomcom lightweight duty
PSO Board Members, contd.
- different selection if > 4 Class 1 members
- IAB Chair & IETF Chair if 5 or 6 Class 1 members
- IAB Chair if > 6 Class 1 members
ICANN Board Members
- proposal to select nominees for ICANN PSO Board positions
- each year after 1st year
- nomcom selects one nominee
- 3 year term
- first year
- nomcom selects three nominees
- - - 1,2 & 3 year terms
ICANN Board Members, contd.
- subject to recall procedures in RFC 2282
- subject to selection by PSO
- subject to approval by ICANN board
- subject to ICANN geographic restrictions
ICANN Geographic Restrictions
- "no more than one-half (1/2) of the total number of Directors, in the aggregate, elected after nomination by the Supporting Organizations shall be citizens of countries located in any one Geographic Region. As used herein, each of the following shall be a "Geographic Region": Europe; Asia/Australia/Pacific; Latin America/Caribbean Islands; Africa; North America."
Protocol Council
- proposal to select nominees for the PSO Protocol Council the nominees will be selected from the active members of the IESG and IAB by consensus of the IAB and IESG
- note above are already appointed by IETF nomcom process
- avoid new tasks for nomcom
- note - change from ID
Bernard Stockman: This is against the IETF spirit. Use nom-com.
Tony Hain: There is an issue with requiring the SOs to subscribe to the geographical distribution requirement.
Perry Metzer: Complexity kills. Step back and get more input. This won't work.
Fred Baker: This is to ICANN: Add South America to your definition of geographical areas.
Leslie David: Picking from the IAB and IESG is not good (they are overworked already and it is a different task). Use nom-com.
Eric Brunner: What was the institutional experience we gained from the IAHC process?
Erik Huizer: A lot of coordination is needed.
Mark Day: This hard-wires the chairs of IAB and IESG plus geographical distribution.
Esther Dyson: That is an untenable position.
John Klensin: Things are the way they are. Stop worrying about what if things were different. While we wait, others will fill the gap.
Jeff Schiller: Use nom-com.
6. New Charter
Erik Huizer: Is a new charter needed for POISSON. Current charter is done. One issue for new charter is: the copyright RFC text that has been submitted to the list for consensus. 2nd issue: List charters 3rd issue: What is the new relationship between IETF and ICANN? What is the nature of the PSO? Will there be an IANA contract?
Graham Travers: How will the decision be taken?
Erik Huizer: After consensus on the list is reached, it will be presented at the next open plenary.
Procedures for IETF appointments to the Protocol Supporting Organization
Protocol Supporting Organization for The Internet Corporation for Assigned Names and Numbers